Data Science Automation (DSA) designed a system for one of our customers that pivoted a custom head to a precise position on a frequent basis. The entire system had 600 sec to accomplish one task. The DSA pivoter was part of a larger system.
We used a stepper motor with encoder feedback, and leveraged NI’s SoftMotion toolkit on a cRIO platform. To reach the customer’s desired rate of operation we estimated our part of the system would take about 300 msec, and out-of-the box values for the SoftMotion’s parameters pretty much got the job done.
However, when the customer arrived to take back the functioning system, he looked at the operation and felt it wasn’t smooth enough. As It turned out, their part of the system used a larger portion of the allotted time than we’d accounted for, so we had to cut our move times by more than a factor of four! Applying some physics to the decision of what parameters to use solved most of the problem and achieved about a factor of three improvement. As a final step, we may need to rewrite some of the SoftMotion software to squeeze every bit of performance we want out of the motor.
So how do you decide what parameters to use to drive your motor? The computer recognizes that motors operate in units of steps, but we often had to translate that into either rotations-per-minute (RPM) or rotations-per-second (RPS) because that’s what the motor’s specification sheets used. The motor driver had microstepping capability, and we used a setting of 1,600 steps per revolution. So that’s one parameter down.
The peak motor speed was straightforward, but there were competing specs. Our motor’s torque vs speed chart went as high as 40 RPS, but our encoder reader’s particular configuration could only handle 508 RPM, which equates to less than 10 RPS. At 1,600 steps per revolution, we used 16,000 steps/second, and it worked well. In fact, we pushed it up experimentally until we heard it starting to grind, which indicated that our encoder reader wasn’t keeping up with the encoder pulses. That happened around 24,000 steps/second. The motor driver is capable of driving 3,000 RPM, so one way we may improve the system in the future is to replace the reader with a faster one. Note that the units in the different spec sheets varied, so we had to pay close attention to them.
The next parameter is acceleration. There are a couple equations I remember from physics (despite my PhD). One of them is F=m * a, or: Force = Mass x Acceleration and the other is turning motion has an analogous equation: Torque = [Moment of Inertia] x [Angular acceleration].
When looking for that last quantity, I needed the proper torque and moments of inertia. Torque came from the torque vs speed chart of my motor, which it’s not a single value. It’s about 80 inch-ounces at low speeds and drops to about 20 inch-ounces at high speeds. (Oh, boy, more unit conversions! And this time it’s metric and English!) I chose 20 inch-ounces as a safe value and multiplied by .00706 to convert it into Newton-meters.
The head piece we were spinning was designed in Solidworks, so it could spit out the moment of inertia about the spinning axis as 2.5 * 10^-5 kg m^2. The result was that this motor could spin up this head at about 5,000 radians/sec^2. (Remember radians? 2 Pi radians per revolution and all that? They help keep the equations simple, but you must remember you’re working with them because technically, they’re dimensionless!) Working radians into steps gave me 1.3 million steps/sec/sec as an appropriate acceleration rate. This was over 4x higher than the value we’d been using before. Since we weren’t going all that far (max rotation was half a turn, so 800 steps), the motor was spending all of its time accelerating and decelerating, and often never reached full speed; increasing acceleration by 4x changed that balance significantly.
Finally, what about the jerk? You may not remember jerk. It’s the official physics term for the rate of change of acceleration, and it’s yet another parameter to set in SoftMotion applications. We weren’t concerned about jerking our motor head, so we wanted it high. But how high is too high? We tried using the Infinity constant that LabView provides, but the routine threw an error. So, after thinking about it we decided in order to reach our desired acceleration in a time short on the time scales we’re looking at, 1 millisecond seemed appropriate.
To get to 1.2 million steps/sec^2 in one millisecond requires a jerk of 1.2 billion (in units of steps/sec^3). It’s kind of intimidating to enter that large of a parameter into a motor driver, but that was the right solution.
With our new parameters we got almost as far as the customer wanted. The time we took was 80-120 milliseconds, and about 35-60 msec of that was actual motor motion, as evident by the pulses going into the motor driver. Our code took some time to decide where to send the motor, but there was still a 25-50 msec delay after the motor’s finished before SoftMotion decided that the motor had arrived at its desired location. To achieve final improvement results, we hope to find a SoftMotion parameter specifying how picky it is about the final position, or how long it must stay there until it’s satisfied in order to cut down that final delay. Failing that, we may need to re-write the SoftMotion control routines in FPGA code to truly tailor them to our needs. After all, our motor has spare torque at low speeds, so we should be able to accelerate more quickly there, and parameters to control that don’t seem to be available in SoftMotion.