Stuffing the AC motor back into the Kenmore Model 158 crash test dummy sewing machine, tightening the belts, powering it from the bench supply, and recording speed vs. voltage produces this interesting graph:
The blue curve comes from the unloaded motor sitting bare on the bench. The red curve represents a more useful situation, with the motor driving the sewing machine’s main shaft, moving the needle carrier, spinning the bobbin housing, rotating a bunch of cams, and shoving the cranks. I expect the load would be higher while it’s actually punching thread into fabric / zigzagging / whatever, but probably less than a factor of two.
The sewing machine’s top speed is around 8500 rpm, useful only for bobbin loading. Feeding that speed into the linear fit equation and turning the crank backwards says the motor would run from (wait for it) 99.5 V. The motor’s rating is 110 to 120 VAC, so it’s within 10%; that’s ignoring the whole AC vs. DC discussion and my relatively imprecise measurements.
The motor draws about 300 mA unloaded and 500 mA loaded; those values remain essentially constant at all speeds. The loaded current increases by about 10% over the speed range, likely due to increasing mechanical load / windage losses inside the sewing machine.
The locked rotor current is 880 mA at 40 and 45 V, rising to 1 A at 50 V.
The bench supply has an adjustable current limit that steps in 30 mA increments. Starting with the supply in constant voltage mode, reducing the current by 30 mA from the free running value brings the motor to a gradual stop. As with all motors, the output torque comes from the winding current, but in a (series-wound) universal motor the same current energizes both the rotor and the stator windings: there’s a square-law positive feedback loop ending in a high current stall or a low current runaway.
The usual triac speed control will not be useful in this situation, because it will generate an unacceptable level of audible noise.
Closing the feedback loop through the operator’s foot on the pedal works surprisingly well, due to the relatively slow motor response. Duplicating that with, oh, say, an Arduino might require a bit more than just a PID loop.