Chief Delphi - Inverting the direction of a Motor

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Inverting the direction of a Motor (http://www.chiefdelphi.com/forums/showthread.php?t=65771)

Re: Inverting the direction of a Motor

Quote:

Originally Posted by Tom Bottiglieri (Post 717119)

Quote:

Originally Posted by Alan Anderson (Post 717094)

True, but that's not the desired function.

How is it not?

You gave an alternative that yields the same value as 255-x. However, 255-x is not the desired function. The correct way to invert a motor value is to subtract it from 254.

Re: Inverting the direction of a Motor

Quote:

Originally Posted by willson.thomas (Post 716919)

I know this has probably been answered several times elsewhere in the forums, but I can't for the life of me find where.

I am trying to reverse a motor in software. I have two motors connected to a single axle and want to reverse one of them. I want to use the y axis of joystick no. 2.

I realize that the same thing could be accomplished by reversing the + and - wires on one of the motors but IMHO it is better to do this in the code.

Tom,

You've received many answers to your question regarding how to reverse the motor in software, but in this case, I'd highly suggest that you implement a mechanical solution so that a software bug can't possibly cause the two motors to run in different directions, or even at different speeds.

I would suggest using a single PWM output from the controller to control both of these motors. You can use a PWM "Y" cable to take a single PWM output from the robot controller to two separate victors. There were some of these cables in the kit of parts. Additional ones can be ordered from many different vendors. (See "CABLE-PWM-Y-2PK" at http://ifirobotics.com/accessories.shtml for an expensive source for these cables.) Since your motors are currently turning in opposite directions when given the same PWM value, you'll need to reverse the motor leads on one of the motors.

The advantage of using the single "Y" cable to two victors is that it is not possible for a software bug to cause the motors to go in different directions or to run at different requested speeds. In the long run, the extra mechanical effort to eliminate potential future problems caused by the software will be time very well spent.

Best Regards,
--ken

Re: Inverting the direction of a Motor

Quote:

Originally Posted by Mark McLeod (Post 717173)

Any 255 set in the user code is converted by the Master to a 254 before it goes anywhere. So using 255 doesn't cause any harm, but it really becomes a 254 as soon as you hand it off via Putdata().

You'll never see an OI value of 255 arrive at your user code, no matter how hard you try. :)

Off topic, but...

I was told that this was a historical limit on the master/slave processor serial bus interplay because xFF was used in the serial transmission sequence to signal the start & ending of a transmitted frame. With the use of INT0 to signal the start of frame transmission on the newer controllers I wonder if there is some other technical reason for continuing to do this (not allowing xFF in the transmitted data frames)?

Re: Inverting the direction of a Motor

Quote:

Originally Posted by Ken Streeter (Post 717610)

The advantage of using the single "Y" cable to two victors is that it is not possible for a software bug to cause the motors to go in different directions or to run at different requested speeds.

There's software in the Victors. It's possible for them to be miscalibrated so that the same PWM signal from the Robot Controller causes different outputs to the motors. If you don't want to explicitly calibrate two Victors controlling motors on the same gearbox, it would be a good idea to at least force the factory default calibration on them both.

Re: Inverting the direction of a Motor

Not on the master/slave communication, but on the radio packet traffic between the OI/RC. A double 255/255 flags the beginning of the radio packet data.

Quote:

Originally Posted by dcbrown (Post 717625)

I was told that this was a historical limit on the master/slave processor serial bus interplay because xFF was used in the serial transmission sequence to signal the start & ending of a transmitted frame. With the use of INT0 to signal the start of frame transmission on the newer controllers I wonder if there is some other technical reason for continuing to do this (not allowing xFF in the transmitted data frames)?