Kenmore 158: Acceleration and Deceleration

Plotting the motor RPM every 500 ms while increasing the nominal current by 50 mA per step from 550 mA:

Motor RPM vs Current Steps – Accelerating

And then downward from 950 mA:

Motor RPM vs Current Steps – Decelerating

No, the steps aren’t the same size going down as they are going up. The nominal current setting is open-loop = constant DAC values: the actual current for a given DAC value varies as the transistors heat up.

The motor starts running at 3700 RPM with 550 mA and stops well under 1000 RPM with 400 mA. Obviously, starting slowly and smoothly will require finesse: a swift kick of maybe 600 mA to get it turning, then immediately drop to 400-ish mA for slow stitching. Those currents must be the actual motor current, not the nominal DAC values, so the motor sees the proper current regardless of the transistor temperature.

The sewing machine requires four samples = two seconds to stabilize at each new speed on the way up, so the mechanical time constant is 2/3 second. Trying to stabilize the speed with a loop running much faster than that will certainly cause oscillation.

There is absolutely no deceleration control authority: reducing the current allows freewheeling as the machinery slows down to match the current. The undershoot after each step on the way down lasts 2.5 s, then there’s a persistent oscillation with a period of 3 s.

Forcing the firmware to run slowly enough to match the hardware should pose an interesting challenge… you don’t want to lock up the UI while the motor stabilizes!

1. #1 by hexley on 2014-11-17 - 14:01

“a swift kick of maybe 600 mA to get it turning, then immediately drop to 400-ish mA for slow stitching. ”

That may be learned behavior on the part of the operator when the old carbon pile control is in use — give the pedal a bit of Welly to get things going, then back off quickly to get the desired stitching speed. So if the goal is to emulate the feel of the old resistive control, then maybe the firmware does not need to do the swift kick, as the operator will be doing it anyway. This is just supposition, but if you could probably get Mary to do a test run or two for observation.

BTW, if the control loop is only active when the timer interrupt says it is time to take a sample and compute a new output — say, every few hundred milliseconds — then why the concern about bogging down the UI?

One more random thought — if the motor windings were shorted together, would that act as a brake? And if so, would there be any call for that kind of Emergency Stop? Probably this would have surfaced on past machines over the decades if it were actually useful, but then your uP-based electronic drive does make a lot of things possible that might not have made sense with simpler controls.

• #2 by Ed on 2014-11-18 - 08:48

maybe the firmware does not need to do the swift kick, as the operator will be doing it anyway

The reason I got into this whole mess was the lack of low speed control with the old carbon rheostat: Mary hated having the thing start with a burst of speed. What she (and, therefore, I) want is a direct relation between pedal position and speed, so that the motor starts at a low and very predictable speed.

I’m hoping that the 11:1 stepdown will allow one or two motor revolutions at high current, then a few more while the current drops to whatever will sustain the commanded speed. That remains to be demonstrated…

why the concern about bogging down the UI?

Well, if I did the obvious Arduino thing with huge `delay()` sections, it wouldn’t work. So some state machines lie in my future: low-budget multitasking in full effect.

if the motor windings were shorted together, would that act as a brake?

I think not, because (without magnets) the torque depends on the square of the winding current: it would decelerate, but at a rapidly decreasing rate as the current dropped off. I should gimmick up something with a DPDT relay to slap a short across the motor and find out, though.