Hi, we have a broken drive motor. It emitted a high pitched noise (more prominent than the sound when the joystick is nonzero) after we mistakenly had one of the drive motors reversed and tried driving on the ground. It currently does not emit any noise or work at all, regardless of port. Has anyone faced a similar issue and managed to find a fix? Its a similar issue to (https://vexforum.com/index.php//36773-v5-motor-problems/0)
As soon as we ran the offending program (at the same timestamp, according to the event log), we got a “Motor over temp level 4 on port 11” error. Port 11 is the one with the broken motor
Level 4 over temp error is highest level, the power inside the motor would have been cut off completely and the motor would not have moved. Why this happened I don’t know, either the motor was stalled for some length of time or some internal component broke or stopped the motor from moving.
Did the motor ever recover when it cooled down ?
The motor no longer seems to move, despite this the motor still lights up red and whenever you send power there is a high pitched noise.
We had a motor that died in exactly the same manner. It was brand new, and had only been used to flip an arm a few times before it died. Same sound, same message in the log. It never came back to life.
Yup, two teams I’m good friends with and I have all blown out motors in exactly the same way. When they get to temp level 4, they blow out permanently and irreversibly. I wonder why the firmware doesn’t keep them from moving once they get to level 3.
Yep, we also lost a motor this past weekend in an identical way…was not under any particular strain when it failed, so I would be surprised if the temp ever actually reached level 4. Same error, and red light still lights but no power delivered to motor. I’ve only got a very few spares for my teams , can’t afford this to be more than a one-off…Help us VEX!
level 4 is 70 degC, that’s been determined to be safe, level 3 is 65 degC.
It sounds like something is failing in the motor and causing both overheating and eventual motor failure.
Maybe weird movement and strain caused a short somewhere, resulting in a much higher temp. than would normally be caused by the amount of stress on the motors.
I have seen a couple of dead motors recently. I cannot tell for sure if they were making high pitch noise - it was too noisy at the competition and my diagnostic tools were limited to a screwdriver and 9v battery…
The common behavior was that both motors were recognized by the brain and neither were rotating when commanded. One came off the drive train and another from the flywheel (from different robots). The drivetrain motor could be turned by hand and brain could recognize updated counts. Flywheel motor was seized. I didn’t know at that time that log could contain motor diagnostics, so I didn’t look for that.
Upon disassembly all internal gears seem to be fine. I could turn flywheel motor (actual internal motor) shaft directly by hand, but I could feel high mechanical resistance in one spot per each turn, indicating most likely some internal damage to the motor’s rotor. We didn’t take internal motor apart, because team was going to send it back for replacement.
The drivetrain’s internal motor could be easily turned in either direction by hand. However, when I connected 9v battery directly to the internal motor terminals it would run in one direction much faster than in the other. My guess is that its H-Bridge got some asymmetric damage.
Do you know where exactly the temperature is being measured. Is it motor casing, external sensor, or an integrated H-Bridge sensor?
Could it be that it is good at reading steady / slow temperature changes, but would not be able to detect fast increases due to shock loads, until it is too late?
Also, when firmware makes decision to shutdown, does it look at only temperature, or the current and voltage readings are taken into consideration as well?
The sensor is not ideally located, it’s on the pcb, not on the motor casing.
H-Bridge has its own internal over temperature detection IIRC.
quite possibly.
motor firmware current reduction is only based on temperature. We initially go to 1/2 current, then 1/4, then 1/8 and finally disable completely.
1 Like
That’s unfortunate. Protection system needs to react faster than any damage can occur, otherwise it just offers false sense of security.
That’s good, but I would treat that with a big asterisk.
Back in high school, I was trying to build a big-â– â– â– audio amplifier and got an expensive pair of output stage transistors. They were matched Darlington pair with built in thermal protection.
Unfortunately, they survived less than 5 min of testing after I turned the amplifier on for the first time. One of our family friends who was an electric engineer explained to me that “thermal protection” is not a magik thing and is only going to protect devices when used properly.
Instead of the proper heat sinks that match thermal output of the transistors, I used two chunks of aluminum that looked “big enough” to me, and instead of fresh thermal paste, I just used old thermal pads, that I pulled from some random power supply. Clearly, I had no idea what I was doing…
He told me that you always have to read the fine print in the datasheet that describes the range of operating parameters where thermal or over-current protection is guaranteed to work.
I had a happy ending to my story - he gave me similar but less powerful pair of transistors already attached to the proper heat-sinks and my amplifier worked for many years.
Current and voltage seem to be the fastest parameters to tell you about any load changes. In conjunction with slower reading of the rotation counter you could, probably, detect sudden changes faster than H-Bridge will die.
I would assume that using same math you have in SmartMotorLibrary you could predict instantaneous value of dissipated power both in the motor and in the H-Bridge.
Measuring air temperature inside the outer motor shell seems like the least useful feedback mechanism, because its averaging time must be the same order of magnitude as the 1:45 match. By the time it tells you that motor is about to overheat, it will already be all over.
70 degC at the sensor may mean that a number of seconds ago it may have been 200 degC somewhere else for a short period of time, before it slowly spread out and propagated to the sensor.
I was not involved with the hardware design, but my understanding is that it’s primarily designed to provide similar protection to the old PTC in the 393 motors.
The firmware has knowledge of current and voltage, we limit current to a predetermined maximum which is lower than the theoretical stall current of the motor. A motor that is operating normally can be stalled for a couple of minutes before temperature rises and we start to reduce current. I’ve not heard of any issues when operated like this and my own testing hasn’t shown any problems in doing this other than having to wait for quite some time before the motor cools and it can be run at full power again.
If vex support can intercept these failed parts when they are returned, we can do more investigation (perhaps it’s been done already, I haven’t specifically asked hardware guys about that) and figure out what happened.
I understand the intention, but PTC was doing literally realtime analog integration of the current and could do a swift guaranteed shutdown thanks to its positive feedback loop.
On the other hand, digital protection done in firmware is subject of anything that can go wrong with a computer system. Analog to digital conversion of the current takes some time, then CPU processing interrupt or locked in communication loop can add further delay. Finally, the firmware could crash or freeze for some time, waiting for watchdog timer to restart it and forgetting accumulated integrated value for the current. This could delay issuing current reduction command even more.
I understand that when there are no anomalies everything will work very fast and reduce power in time. But what if motor’s CPU is subject to the same resets and freezes that cause V5 brain to whitescreen?
Does it ever record motor’s CPU reset events to any log or eeprom?
What will happen with the current if CPU freezes hard while PWM output is in the high state?
Is watchdog timer set to short enough interval to react faster than any damage can occur to H-Bridge?
That puzzles me too. I understand that if motor experiences brush failure and seizes with zero resistance then H-Bridge is pretty much toast, unless its integrated thermal and over-current protection is really good.
What I don’t understand is the mechanics of how H-Bridge or other part of the control system could fail while the internal DC motor seems to run just fine and the CPU could still count position and send it back to V5 brain (like with one of the motors that I was writing about few posts above).
That would be great.
This happens to me as well, and the USC vex team has had 4 blow out
Well here we are again… Tournament tomorrow and another motor dies with the same symptoms… Temp level 4 and high pitched squeal. Any ideas?