Built a prototype High hanging robot (to get acquainted with ROBOTC) that tries to do it all. Has 38 inch reach with a dual bobcat type linear slides. It has a plunger and a pincher which allow it to quickly pick up and deposit tubes and also take a few tubes off a goal if need be. Uses 4 big motors (2 wire) on the lifter , 2 servos, and only 2 direct drive motors. Might add two motors and increase speed. It can do the lift in about 6 seconds after the grip is established.
SMOKED CORTEX
Arrrrrgh! @#%$^&* Fried the new cortex today. Did nothing unusual. The robot was working fine and possibly some loose battery conections caused the failure under heavy current load. The processor still works ok, the discretes are working…but all the pwm drives are toast. I think the big motor current transients were too much for it. This may be a design problem since I’ve never smoked a Vex processor before. Will talk to Vex support and see what can be done to repair.
Am I the first?
Update: 6/30 BEWARE!!!
Talked with Vex support and there is a problem with ROBOTC beta 2.16 that can cause excessive currents to blow the PWMs due to a pass through on startup. So download the next ROBOTC beta version to fix the problem. Vex will RMA and fix CORTEX under warranty(whew). Thanks guys.
Did it smoke when it burned?
Do you remember if you were reversing directions quickly?
Can you post the RobotC firmware release number, etc?
I heard an unsubstantiated rumor of a previously smoked cortex that was attributed to a “shoot-through” on the H bridge.
A fix would require a new RobotC firmware with a different tradeoff setting on the shoot-through avoidance time delay,
of performance vs robustness,
which is why I ask about all the versions of RobotC stuff you are using.
Yes… using Beta 2.16 ROBOTC is probably the culprit . See my update to original post.
Didn’t see smoke, but the smell of burnt chips sure caught my attention.
I typically drive the big motors in pairs and only one pair at a time. One pair uses the two wire (1,10) ports and the other pair uses ports 4 and 5 to allow maximum current. In my initial software design, two were at zero command while two were working. I changed the software to add a current bias instead of a zero command since the slides were not being held in place with the motors off. This was on the order of 10 pwm counts. This added to the steady state current load and might have heated the chips up.
I suspect the problem occurred with an interrupt in the battery power which caused a controller reset while the motors were under heavy load. Possibly the pass through problem reared its ugly head then. Don’t really recall the sequence of events. I think port 1 and 10 burnt first but drive (3 wire) motors still worked. Then shortly after all pwms blew. Also noticed that the servos were chattering when the port 4,5 big motor pair were commanded in one direction… indicating a possible rail voltage draw down. This phenomenon was present for a while prior to failure.
[FONT=Verdana]You can potentially burn out the H-bridges on motor ports 1 and 10 with version 2.16 of ROBOTC. This only occurs if you have a user program that explicitly sets these motor ports to a non-zero power level.[/FONT][FONT=Verdana]These problems are resolved in the ROBOTC release posted today (6/30/10).[/FONT]
[FONT=Verdana]Detailed Technical Explanation[/FONT]
[FONT=Verdana]Recall that motor ports 1 and 10 have integrated H-Bridge electronics in the VEX Cortex. These motors have only a 2-wire connection to the VEX Controller; the only current VEX motor with this functionality is the VEX Explorer motors.[/FONT]
[FONT=Verdana]There are four internal I/O lines that control a single H-bridge. Two on each side of the motor. These lines control whether that side of the motor receives “+” or “-” battery voltage (or neither). If both “+” and “-” I/O lines are set on one side of the motor then you get an internal short circuit of the two battery terminals. The MOSFETs (transistors) in the H-bridge overheat and can burn out (“smoke”) when this occurs before the internal overload (resettable fuse) kicks in. The firmware should have interlocks to prevent this from occurring.[/FONT]
[FONT=Verdana]The Master CPU has the capability to override the user program (i.e. Slave CPU) control of motors; this is intended for disabling motors. For motors 1 and 10, it achieves this by forcing the battery “-” to a “disconnected” state. The Master has the ability to set the battery “-” H-bridge gates to one of three states: “always connected”, “always disconnected”, or use the settings from the Slave CPU. It should only use the last two states.[/FONT]
[FONT=Verdana]The fault is a combination of two firmware bugs that occur on startup of the VEX Cortex.[/FONT]
[FONT=Verdana]1. [/FONT][FONT=Verdana]On initial power up, the Master CPU holds the USER/Slave CPU (i.e. the one used by ROBOTC) in reset until it is ready to start communicating with the slave.[/FONT]
[FONT=Verdana]2. [/FONT][FONT=Verdana]Once ROBOTC firmware (i.e. the Slave CPU) establishes communications with the Master CPU, it starts executing the User program code.[/FONT]
[FONT=Verdana]The two firmware bugs are:[/FONT]
[FONT=Verdana]1. [/FONT][FONT=Verdana]ROBOTC firmware should not start executing user program immediately upon synchronizing communications with the Master CPU. It should wait for a additional message from the Master indicating “valid data”. [/FONT]
[FONT=Verdana]2. [/FONT][FONT=Verdana]The Master CPU should be holding the H-bridges in a “disabled” state until it sets the “valid data” bit. Instead, it has the battery “-” connected on the H-bridge.[/FONT]
[FONT=Verdana]The ROBOTC version posted today fixes the problem described above.[/FONT]
No… Software should NEVER EVER be able to potentially destroy hardware, how is this possible?
Precautions like these should be embedded in the device, I would argue that even a fudged hex file running random code should not be able to do this.
Furthermore, lose the idea that ports 1 and 10 are not currently being used…
You are wrong, the two wire heavy strength motors are out (and have been for some time now).
lots of people buy or bought the new Cortex just for these ports. Almost all regular teams will be using the high strength motors this season.
What about the college teams? We BETA tested this package. While I fully understand what the phrase “beta testing” means, people are quick to forget that we competed. Flaws in software and hardware crippled some of the teams who traveled to the world championship. College teams are fine with beta testing hardware but we need it sooner. We cannot recieve brand new beta hardware eight weeks before worlds, we need it six months in advance. Preferably without the self destruct feature.
With this said, I can’t necessarily fault RobotC, I still support them as the best software package for Vex.
We had this problem with our cortex, we thought it was smoked but it turned out that one of the motors had overheater or something and was short circuiting *** the motor ports, when we unplugged the motor it worked fine. This has happened to us twice, it might be worth a shot
Your “never ever” is an important design goal and constraint for educational robotics systems like Vex. Many of these self-destruct-avoidance features are implemented in the supervisor processor firmware, so the user-loaded software can’t break them. Firmware usually counts as “embeded” in the device “Vex Cortex with RobotC or EasyC”. The H-bridge is not built into the CPU-chip itself.
Software (including Firmware) is such a useful concept, even the CPU-chip is designed as software (VHDL or Verilog). The problem with full HW control is that you can’t change your mind later based on new demands gained from experience from new uses.
On the other hand, after re-reading D.Swan’s post, it looks like there is a HW tradeoff involved in the relative current capacities of the [MOSFET in the H bridge] vs [the short-circuit current protection mechanism]. There are many factors including cost, size, availability, performance, flexibility, and reliability for these types of tradeoffs. Its fun and educational to second-guess, but practically speaking, its more useful to just figure out what are the limitations of the existing system.