We are using an encoder to monitor the speed of our flywheel and zero in on which RPM’s are going to work best for certain shots. We are using LabView to do this.
I have a numerical input on the Front Panel where we can enter a desired RPM and in the Block Diagram we’re comparing the rate given by our encoder. If the rate is below our desired RPM, we entered “1” in for the motor output. If the rate is above our desired RPM, we entered “0.1” in for the motor output.
My concern is for the large gap between these numbers. Will it damage the motor or motor controller if it fluctuates rapidly between 100% output and 10% output?
This is our first time testing like this, so if you have any other helpful advice, it would be appreciated!
It will only harm the CIM if it begins to overheat. If the CIM is not going to a gear box and is direct drive, this set up will be fine. The only time it harms the CIM is when there is an intense load on the motor and it begins to heat up. I.E the load of an entire robot.
I wouldn’t imagine so, as we’ve run drivetrain CIMs in similar situations, going from no power to near 100 nearly instantaneously. The motors and their controllers are probably designed to handle such instant acceleration and deceleration. I don’t see how this is different from any other FRC application.
How well this works depends on which speed controller you’re using. The very original Talon (not SR or SRX) speed controllers used locked antiphase modulation, which basically reverses polarity during the off-time part of the PWM cycle. Which means a large change in speed from 1 to 0.1 would result in some pretty heavy braking while the 0.1 speed was active. Which would make for less than ideal speed control until you tweaked the 0.1 value near the value you’d run the motor at constantly to get the correct speed.
Most every other motor controller (that I have detailed information on) uses synchronous rectification. Which puts the motor into a slower braking mode during the off part of the cycle.
Learning to tune a PID loop is a super relevant skill so i would highly recommend it.
If the PID vi’s aren’t available:
I would dump the rpm value onto the top input of a “greater?” function then the boolean output of that into a “select”.
On the select i would put the integer “3” on the top “t” terminal and “1” on the bottom “f” terminal. Run the output of the select into the “f” terminal of another select.
then wire a constant integer of “2” to the second select “t” terminal. The Boolean input for the second select is the boolean output of an “in range and coerce” function.
The input “x” value for the “in range” function shares the same constant that is connected to the bottom input on the “greater?” function, which not surprisingly, is your desired shooter speed. The upper and lower limits you’ll have to tinker with to get the desired response.
Ok so out of the select we now have 3 different states 1; if the shooter is below speed 2; if the shooter is at speed and 3 if the shooter is above speed.
Create a case structure. Case 1 being below rpm case 2 being in range of rpm and case 3 being above rpm.
also drop a feedback node above the case structure. put the case structure in “2” create a “double” constant on the bottom of the feedback node (comment it as “initial speed”). Wire the left side of the feedback node backwards and through a second “in range and coerce” function this time the limits are probably 0 and 1
The coerced(x) output goes entirely through case 2 with no change and back to the right side of the feedback node. Create a “double” constant on the left side of the case structure and comment it as rate of change. I would expect this value to be something like 0.05 or something. In case 1 you add the rate of change value to the value coming out to the coerced function then back to the terminal headed to the feedback loop in case 3 you subtract then send it to the feedback node.
The double that is coming out of the case structure and going to the feedback node gets split off and wired into your motor set output.vi
I would put all of this (except the encoder and the motor set) in one big case structure controlled by a push button from the joystick specifically in the “true” case. In the false case just put a 0 constant in the case and wire it to the motor set vi. this way you can actually shut off your shooter.
Man that is a lot more writing than i thought… I guess I got a little carried away. I’ll try to get Labview installed this weekend check out the PID library and get one running. I can post some screenshots when I get there.