At our last competition, we had an issue with our motor controllers burning out. We have used the same motors and controllers all season with no problems, and the robot seemed to be working fine when we were testing it the morning of the competition. However, while I was testing the robot before our first match of the day, I noticed that one of our drive motors was not functioning. We did some tests, and, after realizing the problem was the motor controller, we replaced it. It seemed to be working, but in autonomous, the new motor controller started smoking and the motor was dead for the rest of the match. We replaced the motor controller again, but as soon as we tried the wheel, the controller started smoking and the plastic casing began to melt. We didn’t want to burn out any more motor controllers, so we disconnected the wheel and ran on a 3 motor drive until elimination rounds. A team suggested that it might be the motor itself that was causing the problems, so we replaced it and the burned out motor controller with a new one, and everything seemed to be working fine. However, in our very next match, a different motor controller, one that had been working the entire day began to smoke, and the motor died. This is our third year of competing in the vex competition, and we have never had any problems like this, so it seems strange that it would happen twice in a single day. Has anyone else experienced these problems, and does anyone know what might be causing it?
Thanks in advance,
Eric
Could it possibly be a bad cortex? Do you have an extra?
Are you using a power expander?
If the output of the motor controller is shorted this could theoretically happen, most likely a wiring problem, are any wires pinched? Do you have any 2 wire extensions that were not replaced when the MC29 and motor were replaced? The PTC in the cortex (or power expander) should have prevented this, is there any other information you can give us?
Thanks for the speedy responses!
We are not using any power expanders or wire extensions; the motor goes through a motor controller, then directly into the cortex. There do not seemed to be any pinched wires. We thought this might be a cortex problem, but switching motors seemed to fix the issue. We are reasonably certain that the problem lies in the motors, but we are more concerned by what is causing it and how we can prevent this in the future.
Eric
The motor controller contains MOSFETs that are rated at 8A (for the N channel) and 6.9A (for the P channel) for continuous current operation. They can withstand more than this for short periods of time, the graphs for the P channel MOSFET imply perhaps 15A for 1 second.
A 393 motor when stalled draws 4.8A of current, however, the PTC in the motor should trip with this current in under 2 seconds. The cortex has a PTC rated at 4A, double this current to 8A and the PTC trips in about 5 seconds. I have not tested a cortex PTC above this rating but at 15A it’s probably in the 1-2 second range.
So what am I trying to say with all these numbers, well to damage the MC29 you really have to short the output somehow and allow a high current to flow. The problem is that the cortex PTC should be able to protect for this condition although at these high currents the time for the MC29 to be damaged and the cortex PTC to trip seem to be similar.
I guess the first two MC29s could both have been damaged by the motor if it was shorted internally and its PTC non functional, an analysis of the motor could prove this, do you still have the motor?
Why you had a second failure the same day is a mystery. Were these 393 or 269 motors? Where in California are you, if you are in the LA area I would be happy to help you diagnose this.
As you diagnose this, maybe include the possibility that the battery voltage is possibly too high along with too high slew rates in autonomous.
With a newly charged battery at say 8.5 v, the maximum current will be on the order of 5.6 amps instead of 4.8 for the 393.
Recall that I blew a controller the other day when testing your Smart Motor Library PTC monitor. It happened when I put a newly charged battery into the robot. Not sure what the battery voltage was when I installed it.
If you are blowing controllers in autonomous… I believe that you can put a 100% step per iteration in autonomous where in manual, the slew rate is limited by the driver response time. You might try to slew rate limit or just command rate limit the autonomous command to say 20 cmd counts per 20 ms update.
Also, perhaps if you were going max speed in autonomous and then initiated a turn that reversed a motor you could see more than the max current which then gets close to over currenting the FETS. Particularly the P channel.
Who knows, maybe there is a batch of controllers that have weak components.
The MOSFETs should be able to handle the current transients, they are rated for up to 50A but only for very short periods of time. However, after thinking about this some more, if the controller is shorted then I think it will probably fry straight away, the cortex PTC is going to be too slow to protect it. From the AO4818B datasheet;
[ATTACH]6977[/ATTACH]
In normal operation VDS will be small, the FET has a 20mΩ resistance, the motor is something like 1.5Ω so VDS is perhaps 0.1V. If the MC29 is shorted then VDS is perhaps 0.3V, it’s going to depend on other resistances in the circuit but for the sake of argument lets assume they all add up to 0.5Ω. 7.2/0.5*0.02 = 0.288V. current would be 7.2/0.5 = 14.4A. From the graph above follow the 0.3V line up and with 14A the FET will overheat after somewhat less than 1 second. This is a bit outside of my area so perhaps my math is wrong here, any thoughts Chris?
We tested the motor on a brand new battery charged with a smart charger. We have never had problems with batteries in 3 seasons of competitions, and our B and C teams were running the same batteries without any problems. I don’t believe the problem lies in the autonomous program, because the controllers were blowing out immediately even in manual control. In addition, our B team, which was using a near identical robot and program experienced no issues. Could a damaged cortex be the problem, or did we just get unlucky with two motors in the same day?
Thanks,
Eric
Which motor did you test? What was the result?
I doubt it’s the code, vamfun is correct in that using slew rate control will reduce the transient current but most teams do not do this and I don’t hear about that many damaged MC29’s.
I still think the MC29 was shorted somehow, either damaged wiring or a damaged motor, perhaps a gear broke inside the motor and managed to land on the circuit board. Do you still have the motor that was removed at competition ? Have you opened it up to see if anything is broken inside? Do you have the damaged MC29s? Have you opened them up to see which component was damaged?
Just for interest, here is a photo showing the inside of an MC29.
[ATTACH]6981[/ATTACH]
One side of the PCB has the dual MOSFETs which form the H-Bridge circuit. The other has a PIC micro-controller that converts the RC style pwm into the motor control pwm which drives the H-Bridge.
I think you are right about a short causing the problem. Teams should suspect the two wire connections between the motor and the controller when a controller smokes. I can see this as being a real hazard for burning out the Cortex FET’s.
https://vexforum.com/attachment.php?attachmentid=6982&stc=1&d=1355346339
I decided to open up my fried M29. You can see the burnt FET’s but it seems that the wires had frayed that connect the motor. Several strands of bare copper wire had broken loose from the main bundle and most likely shorted the FET’s. Not sure if you can see it with my iphone 5 picture but I am 90% sure that was the cause. Upon closer inspection, it appears that the stripped wire was a bit too long and protrouded excessively from the solder joint. There is a lot more bare wire showing compared to the wires shown in the M29 picture you posted earlier in this thread. This might be a quality contol issure or a design problem or possibly the insulation was pulled away from the joint after it was soldered (again a grommet problem).
https://vexforum.com/attachment.php?attachmentid=6988&stc=1&d=1355351154
Here is a picture of a frayed 393 motor wire which had a missing grommet. This is another likely place for a short.
So I think the two-wire rubber grommets which break off on almost all our motors and some of the M29 need to be rethought by Vex. They are not providing adequate strain relief with normal competition wear. When the grommets dissappear, then the wires are sure to eventually wear through the insolation and short the controllers.
Edit added another picture of 393.
On closer inspection, there seemed to be a pinch on the motor’s wire just after it entered the motor. Although there were no visible frayed wires as in Vamfum’s picture, the pinch must have been the location of the short. New motors seem to have fixed the problem, but we’ll have to see when we do more intensive practicing later. Thanks for everyone’s help,
Eric
That’s a well abused motor, never seen one like that before. It’s not a great strain relief but I don’t think they are that bad, not really designed to support the wire if pulled at an angle or really hard but just to protect the wire going through the housing.
[ATTACH]6989[/ATTACH]