Poor 'zero' of 2 Wire Motors Community Thread

This is in response to https://vexforum.com/t/answered-poor-zero-on-two-wire-motors/18605/1

From prior experience, I believe that the issue is not the motors themselves, but the master firmware or the ROBOTC firmware. When I upgraded from 2.30 to 2.31, and upgraded the firmware on the Cortex accordingly, I found that this issue appeared.

Thus:
-Try and provide a bug report so ROBOTC can fix it in an upcoming version?
-If this solution is required sooner rather than later, adjust the ‘zero’ of the motor to be a value that actually zeroes the motor?
-Regardless of this issue being present or not, your code should be able to compensate for this type of problem anyway, due to the endless number of variables that are ever-changing, ie friction, battery level, heat levels, etc.

We also experienced the same results when we upgraded to RobotC vs 2.31. We could feel the bias on both sides of the drive the moment VEXnet connected. When I tried testing the cortex on a chassi with just wheels & the 393 motors, one wheel actually turned very very slowly the moment VEXnet connected even if the debug window displayed 0 power. Notified RobotC but have not gotten a response yet. My mentor then connected an oscilloscope & measured a pulse when it was supposed to be 0. See my post at this link. Perhaps you could also post your findings on RobotC’s forum. Would like this issue to be resolved before World’s. Thanks.

Duplicating my post from the RobotC forum:

A 393 motor will not plug into Cortex motor port 2 without a #29 Motor Controller, which is where the 3wire to 2wire H-bridge conversion is done. Try swapping MotorControllers, as the fault may be there.

This is a generic trim issue. It is a great opportunity to learn about per-port trimming and how to create an programming infrastructure to implement it. If you do that, it will be a great Robotic Notebook entry and impress the judges, as well as any industry recruiters.
In the real world, things like LED lightbulbs and LED signage need per port trimming to create equal brightness across a variation of LEDs.

Before this starts to catch on, a “dongle” is an identification device, usually used to provide password-type security. The model 29 motor speed controller is a motor speed controller, or “motor controller” if you wish. Let’s not use “dongle,” OK? It’s not the correct term.

When the 393 motors were plugged into ports 2 to 9(3 wire ports), a motor controller was attached to them. As I said this bias does not occur when you use RobotC vs 2.3 but does when you use vs 2.31.

Imagine your 8 motor (2-wires) robot sitting on the field waiting for a match to start, all the while each motor turned on and stalled. It’s no wonder that batteries are draining so fast.

To check if you are having this problem, plug 2-wire motors into ports 2-9 with no wheel attached and verify that they do slowly rotate in autonomous mode (with no motor commands issued or motor[portx]=0 (x=2-9).

A work around may be to set these motors to a slight negative value in the pre-auto section of the template and to subtract same value for all motor commands using ports 2-9 and 2-wire motors.

You can also attached an un-gounded o-scope to the 2-wires going to the motor and observe a 20-50us pulse - there should be none if motor command is zero.