Vex Motor Brake Mode

I figured I’d revive this thread now that we have some new programming options.

Basically, the vex product page used to say the following:

Unfortunately, neither RobotC nor EasyC allow us to actually take advantage of this mode. Is there any possibility of this happening in PROS or ConVEX? Or does the master processor control this and thus require an update by IFI?

For motors 2 through 9, the 3 wire motors, there’s nothing we can do that I’m aware of. For motors 1 and 10, the internal H-Bridge motors, it would be possible to control the motors so as to brake them.

In my simple explanation of the h_bridge in this post, turning on FETs A and C, or B and D would short the motor and allow breaking.

Testing the motor control is one of the tricker areas of the firmware, get it wrong and damage to the cortex can occur. I did the original development of another STM32 eval card from Olimex, it allowed me to make mistakes without worrying about damage.

I have no short term plans to look into this, my Saturdays are now busy as school has started and the team has started meeting again, however, there may be a good reason to use this during hanging to lock motors at the end of the match. The master processor has control of one side of the H-Bridge in addition to the user processor, I need to figure out which of high side or low side breaking will work.

I should add that use of breaking can stress the FETS, there needs to be a little more research into allowable FET current and temperature before trying this out.

Thanks for the info! I completely understand that there are no immediate plans for this I’ve just been curious about the mode since I first read about it.

Wouldn’t disabling the robot still end the brake mode though?

You can brake by shorting either high side or low side FETS.

The master processor (as I understand, never actually tested) only is able to disable one side. I may be completely wrong on this, just something I heard somewhere, I will test at some point.

Oh gotcha now I see what you were saying in the first post.

Thanks for the great explanation!

In addition to what jpearman said, I took a look using PROS and was able to trigger “braking” action on motor ports 1 and 10. However, the motor is still not that difficult to turn (the motor’s internal breaker resistance may be playing a role). While it does stop moving much quicker than just coasting, mechanisms with any significant load will continue to move. Any attempts to lock arms or hanging mechanisms into place when the motor is in braking mode will almost certainly fail with disastrous consequences.

If you want to test how well braking would work on your mechanism, grab a piece of conductive material (a clean piece of VEX steel will work), unplug the motor, and touch both pins to that material. The motor will now resist motion (as the terminals are shorted together), but may or may not “lock” into place as hoped.

If PROS were to implement this feature, the resulting asymmetry between ports is likely to confuse some teams. When combined with the potential bugs that this may introduce, it means that PROS is unlikely to support braking on ports 1 and 10 in the near future. If VEX sheds some light into how to enable braking on the current master code (or releases a new master code which supports this feature), we will re-consider braking mode for PROS at that time.

If you do implement the feature in PROS, we would be interested in using it and would not be confused by the difference in ports.

Just throwing that out there.

I agree with this. If you’re concerned about confusion then the simplest way to do this would be to have the following two functions:


Then those get overridden when one calls the motor set function.

I agree that the motor will not lock but there might be just additional resistance that, depending on the gearing, it may be just enough to stop an arm (or whatever) back driving.