Wait, what? The motors don’t go at a different speed until power 89?
Is the amount of stall torque different as well?
Tabor is saying the speed from 85-127 increases very marginally, while the probability of stalling is much higher. The motor changes speed from1-85, but at about that point there is little increase.
*The motor changes speed from 20-85
Is it 85 - 127 or 90 - 127 where the speed stays basically the same?
Read this historical and historic post. Notice the graphs.
https://vexforum.com/t/24cs-motor-control-value-remapping/23959/1
What @LegoMindstormsmaniac found was that a power setting of 85 to 127, the actual delivered power does not increase much at all.
From just below the second presentation of the graph, in paragraph 9:
Because of @LegoMindstormsmaniac’s work, (which others have verified and reproduced periodically) we know you shouldn’t expect to see much if any change from 85 or so up to 127. We often round this to 90, just because it’s an easier number to work with.
Ah, I see. Thank you for the clarification!
So I understand what you’re saying, however I’m wondering is there an advantage to using the value 90 instead of 127 in your code? If 90 and 127 are the same speed anyways, does it matter what value you use as long as it’s between 90 and 127 if you want your robot to go full speed? I have heard someone on the forum say that competitive robots usually don’t go above 100 during competition play, and I’m wondering why it matters, if 100 or 90 or 127 is used, if they’re all the same speed?
I guess if you use 100 instead of 127, it takes longer for the motor to overload since it’s receiving less power, but it comes at the cost of less torque (only a little bit though, like 1 in-lb loss)?
I am not sure it actually gets less torque. People have been saying that here over and over without any evidence to back it up.
If the motor receives less power, then it produces less torque.
Do you have proof it receives less power?
I did a test a while back of the motor controller output on ports 2-9. Measured on an oscilloscope.
The signal being given to the motor has no change from ~85 to 127. This means the power, speed and torque are probably completely unchanged across that range.
*caveats
- Only tested every 5 power
- Tested with tiny resistor instead of motor to remove back EMF, it is possible higher load on the motor controller produces unexpected effects.*
The only reason I have found to run 90 instead of 127 is that it heats the ptc less.
If you’re going to be in an engineering field, you should base decisions on facts and evidence.
There are at least two separate places in this thread that disprove your assertion that using 90 instead of 127 will heat the PTC device less.
It was really good of @tabor473 to provide a graph from his recent data-taking on this issue. If you don’t understand it, I’m sure he is more than willing to explain it.
If you disbelieve it, or think it doesn’t apply to your situation, you should be prepared to back up that thesis with data.
Yes, that is an important caveat to this discussion. There will be difference in how motor would behave under the load vs being run idle (where the only mechanical load is the friction in their internal components).
See this thread: https://vexforum.com/t/cortex-motor-speed-testing/21687/1
Also, using resistor instead of the motor, removes not only back EMF but also the ability of the motor to store additional energy in the inductive component of it windings.
There must be multiple causes for the control-value-vs-resulting-speed curve not being linear but, I believe, a lot of non-lineriarity comes from the interaction between the power capacitor inside the MC29 (C7 in the image below) and the motor’s inductive component.
https://vexforum.com/t/what-is-the-h-bridge-in-the-motor-controller/29999/1
When there is little or no external load, the supplied energy only needs to go toward overcoming internal motor resistance and friction, which is not much. So, when H-Bridge connects C7 cap to the motor windings it takes very little time to transfer energy from one (cap) to another (windings). Then when H-Bridge disconnects, C7 recharges from Cortex’s battery at a leisurely pace, while energy stored in the motor’s inductive components is being converted into mechanical energy. (Leaving out extra complexities due to triple winding of the brushed DC motor).
I wish I had equipment to test this while varying the value of C7 and/or dynamic load on the motor. NbN would have been a good year to do this test, with everybody having flywheel geartrains with varying degrees of friction as the mechanical load.
The more external load you put on the motor the flatter the curve should become. And it will reach max speed not around 90 but much higher. (Edit: see post below)
If I recall correctly, when we were tuning Flywheel PID for NbN robot, the output speed was changing all the way to the power level ~115 with our setup.
Resistive load or not, it’s all the MCU in MC29 that decides. The waveforms @jpearman measured show that even though the Cortex PWM output is quite linear all the way to 127 (with 2.14ms PWM pulse width), the MC29 takes anything over 1.92ms as “full steam” and the output timing of the H-bridge (even though still not kept open 100% of the time) doesn’t change anymore. I could try to verify this by measuring at the gates of the H-bridge FETs to remove all the doubt, but the consequence is, MC29 totally isolates the motor from the information whether the input PWM was over 1.92ms and how much.
Which port? I am not discounting your observation, but there are several possible explanations that aren’t contradicting the “84 is the information barrier for MC29” claim.
I was able to dig up some data from NbN season, and turned out my memory is not that good. 
We had 3 motor flywheel - two motors connected to ports 1 and 10 and remaining one to MC29. The following table was constructed when only two of the motors were running and the third was serving as the passive load along with the flywheel. Our target RPM for full court shots was 180 (out of max 240 for turbo motors). The test was done with slightly discharged battery but at constant voltage.
Column B is the target RPM, column C is power required to achieve that RPM when motors are connected to ports 2 and 9, and column D corresponds to motors on ports 1 and 10. Column F is the ratio between power levels on different ports.
Turned out the motor control value vs output speed were pretty flat under the load:
I looked into our source code and “learned” that we were scaling power level going to MC29 at 1/1.45 of the power level going to ports 1 and 10.