I am the (extremely) green head student programmer for 1646. I have very little practical experience programming in C, and I would appreciate any help anyone can provide.
::Long Intake of Breath::
Now for the question. We have recently installed a globe motor onto our robot and I need to know how to program it. I would greatly appreciate any advice or links provided by more experienced programmers.First you need to wire the globe motor to a speed controller, then connect a PWM wire from the speed controller to one of the PWM output on the robot controller… to controller the motor from your program you set the PWM output to a certain value…
Assuming you connected the speed controller to PWM output 1
pwm01 = 0; // Full backward
pwm01 = 127; // Neutral (motor doesnt move)
pwm01 = 255; // Full foward
If you connect it to another output just change the pwm number (pwm01, pwm02, pwm03, etc…)
You can choose any value between 0 and 255 to move the motor at different speeds and directions…
You can also map it to a joystick…
pwm01 = p1_y;
This is set the motor speed to the value of the y axis on port 1
Hope that enough to get you started… 
Thanks a lot. This should be very helpful.
A word of correction - the full forward value should be 254, not 255. This is because the control system uses two values of 255 to mark the beginning of a radio packet, so if you assign 255 to a PWM output variable it will wreak havoc with the radio communications.
On my team we have set PWM outputs to 255 and there were no known problems that occured because of it. It may be because PWM 1 to PWM 10 all have some other byte that is sent before it and none of them were ever valued at 0xFF, or maybe it is automatically adjusted in the Putdata function.
I am relatively new at this, so I’m not really sure what if what I am talking about here is entirely correct.
All the responses here so far have been generally applicable to any of the motors in the FRC kit of parts. Do you still have a question that relates specifically to the Globe motor?
I set motors to 255 all the time and have had no problem with it…
We do not use 255 for a pwm output since it may cause an issue.
Also be aware that there is a dead band of ~ 4 pwm counts around the neutral (pwmXX=127) position. Thus 123-131 tend not to move the motor.
Also, The speed of the motor going full forward may (probably will) differ from full speed reverse.
I just do this:
...
if ((pwm01 > 127) && (pwm01 < 251)) pwm01+=4;
else if ((pwm01 < 127) && (pwm01 > 3)) pwm01-=4;
...
-Q
Um… wouldn’t that cause pwm01 to overflow at values near 254? (and underflow at values near 0?)
Yeah it does, i was originally only referring to taking out the deadband. I just edited my post and added the limit code in.
-Q
To respond to the original question; the type of motor is not incredibly important as long as it runs on a PWM signal. What you need to do is set your PWMs as shown in the first response and assuming you are using the FRC robot controller and default MP labs code it will convert that data into a usable signal for any standard PWM motor.
We’ve generally avoided getting the pwms too close to 255. We just put in some code that says something like:
if(p1_y >= 250)
pwm01 = 250
this has worked well for us in the past, as if the pwm output exeeds 255, then it will loop back onto itself and tear up your motors. A pwm output of 256 is essentially 0.
If I’m wrong, please correct me.
You’re correct that if pwm01 gets set to a number greater than 255 it will wrap around to zero and you’ll suddenly go from full forward to full reverse.
A note on using a pwm value of 255.
The reason to avoid using the value 255 is that sequential 255’s in a transmission packet is the standard indication of the beginning of a packet, so if pwm03 and pwm04 (which are side-by-side in the transmission packet) were both transmitted as 255 the packet handler would think pwm05 was really the start of a transmission packet and the OI would be handed really bogus data.
Those of you allowing 255 are protected from the adverse effects, because the Master code takes all your carefully set values of 255 and changes them to 254 anyway. You can test this by setting the pwm values to 255 in your code, then using the Dashboard to see what values actually arrives at the OI.
Please note that the motors here run on Direct Current. They are NOT “PWM” Motors. We use a PWM signal to control a Motor Speed Controller (such as a Victor) which varies the DC current* to the motor, making it move at different speeds and such.
However, the point that the motor type is not particularly important is absolutely correct.
*Technically speaking, it is a pulsating signal at a relatively high frequency, so high that the motor reacts to the current as it would react to a variable DC signal.
In the TxData struct, all PWM values are defined as type ‘unsigned char’ - or one byte. Assigning a value greater than 255 will cause unpredictable processor operation unless you are VERY lucky.
Most programmers are used to C/C++/C#/C.NET which traps all your errors… such as overflow. In the processor, it does exactly what you tell it to do. All defining some thing as a uchar does is tell the linker to offset the next thing in memory by 1 byte. Sooooo if you write a number bigger than a byte, you will interfere with the next bit down the line in processor memory. This would in effect change the value of the next variable.
-Q
Matt something you may want to try sometime to understand better the premise on which PWM motor control works is examining the output of a Victor or other H-Bridge Drive’s output.
If you have access to an oscilloscope, hook the probe end to M+ and the alligator clip to M-, and set your oscilloscope to trigger on a rising edge. Then use a joystick to vary the ‘power level’ (duty cycle percentage) to the motor. As the speed of the motor changes, watch what the ratio of up and down time on the pulse train does.
If you have any questions i’ll be happy to answer them.
-Q