The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Tag: Sewing

Fabric arts and machines

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!

2014-11-17

Kenmore 158: Current Sensor Calibration

The first task: produce an equation that converts raw ADC values into actual motor current. This is not quite the same as the DC calibration, because the motor current is neither clean nor stable.

Step the output current setpoint in 50 mA increments from 450 mA to 1100 mA and remain at each setpoint for 10 seconds while dumping measurements every 500 ms. The ADC count comes from the sampling / sorting / selection process that attempts to pick out either the not really flat top of the current-limited waveform or the peak of the non-limited sine wave.

Convert the raw data dump into a spreadsheet to get a block like this for each current setpoint:

Motor RPM	Shaft RPM	Setpoint mA	DAC count	ADC count	Noisy mA	Comp mA
Setpoint: 600	DACvalue: 2372
3797	334	600	2372	266	724	540
4465	399	600	2372	263	715	532
4734	416	600	2372	265	721	538
4834	438	600	2372	263	715	532
4829	433	600	2372	264	718	535
4857	438	600	2372	264	718	535
4900	438	600	2372	265	721	538
4859	436	600	2372	266	724	540
4887	445	600	2372	265	721	538
4926	446	600	2372	263	715	532
4884	438	600	2372	265	721	538
4890	442	600	2372	264	718	535
4913	440	600	2372	264	718	535
4866	436	600	2372	263	715	532
4895	434	600	2372	264	718	535
4890	442	600	2372	266	724	540
4884	438	600	2372	266	724	540
4913	442	600	2372	265	721	538
4913	441	600	2372	266	724	540
4878	436	600	2372	264	718	535
				265

The lone number on the bottom row is the computed average of the ADC counts for the block, which I did in the spreadsheet rather than in the firmware.

During each ten second interval, set the scope voltage cursor to the eyeballed “correct” value of the motor current waveform, as measured on the Tek current probe. There’s no way to automate this, because only the human eyeball can pick out the, ah, true current measurement amid all the clutter:

Calibrate - Hall amp - Tek 200 mA-div — Calibrate – Hall amp – Tek 200 mA-div

For each current setpoint value, create a line with the manually measured true voltage from the scope trace, the calculated true current (using the Tek probe’s front panel scale), along with the DAC setpoint and the average ADC values extracted from each block of that giant data dump:

Setpoint mA	Scope mV	Actual mA	DAC count	ADC count
450	21.80	436	2205	197
500	25.94	519	2261	225
550	29.06	581	2316	245
600	31.56	631	2372	265
650	34.38	688	2427	285
700	36.88	738	2483	304
750	39.69	794	2538	324
800	42.19	844	2594	340
850	45.00	900	2649	350
900	47.50	950	2705	361
850	46.86	937	2649	356
800	43.75	875	2594	348
750	41.25	825	2538	335
700	39.06	781	2483	318
650	36.56	731	2427	302
600	34.38	688	2372	285
550	32.50	650	2316	270
500	30.31	606	2261	253
450	27.81	556	2205	237
400	25.63	513	2150	220

Plot each actual motor current against the corresponding average ADC value:

The linear fit breaks down toward 1 A, because measuring the actual peak of a noisy sine wave doesn’t work well, but the values aren’t all that far off.

Given an ADC value, that equation converts it directly into the actual motor current as estimated by the human eyeball, taking into account all the measurement weirdness. The Hall sensor produces a voltage that’s linearly related to the current, so the reasonable linearity of the data says that the sampling / sorting / selection process actually produces pretty nearly the correct result across the entire operating current range.

Note that the equation doesn’t depend on the DAC output calibration; the ADC and Tek probe simply measure whatever current happens to pass through the motor for that DAC value. The current through the ET227 transistor doesn’t seem to change over the ten seconds required to take the manual measurement, so it’s all good.

2014-11-14

Kenmore 158: Current & Shaft Speeds vs. Motor RPM

Now that the Arduino can set the current limiter, then measure the motor RPM, shaft RPM, and actual motor current, I can make plots like this:

Shaft speed and motor current vs RPM

The data comes from a routine that increments the setpoint current by 50 mA every five seconds, bouncing off 250 mA on the low end and 1 A on the high end, and writes the values to the serial port every half second. The actual current need not match the setpoint current, because it’s running open loop, and I haven’t done much in the way of calibration, so these represent interesting trends rather than dependable data points.

The eyeballometric slope down the middle of that blue smear comes out spot on 0.90, making the belt reduction 11.1 in good agreement with the results of those pulses.

The motor starts turning at 650 mA and will continue running down to maybe 500 mA, but with essentially zero low-end torque.

The horizontal range of green dots at each current setting shows that, as expected, the setpoint current has only a vague relation to the resulting motor speed: setting 800 mA will produce a speed between 5500 RPM and 9000 RPM, for sure. The actual motor current resulting from a given DAC output depends on the various transistor gains, all of which depend on temperature, which depends on how long the firmware has been running the motor at which speeds. Plenty of variation to go around.

The red points show that the actual motor current, as measured by the Hall effect sensor, generally lies below the green setpoint values, so better calibration is in order. Temperature effects turn accurate open-loop calibration into a fool’s errand, but we can do better than what you see there.

However, those red points do cluster much better, particularly between 6000 and 9000 RPM. You still can’t depend on the correlation, though, because the motor runs with a constant load here. In real life, the load will vary and so will the current required to maintain a given speed.

The green setpoints diverge from the red measurements at the high end, because the current limiter stops having much of an effect when the motor runs flat-out and sets its own current. After all, the original carbon-disk rheostat connected the line voltage directly across the motor, at which point the motor’s 100 W rating comes into play and limits the current to a nice sine wave with 1 A peaks.

All in all, it looks pretty good…

2014-11-13
Kenmore 158: Bubble Sorted Motor Current Sampling
Because the ET227 transistor acts as a current limiter, the motor current waveform has flat tops at the level set by the DAC voltage. However, the current depends strongly on the temperature of all those transistor junctions, with some commutation noise mixed in for good measure, so the firmware must measure the actual current to know what’s going on out there.

Here’s one way to pull that off:

Motor current – ADC sample timing

The upper waveform shows the motor current sporting flat tops at 650 mA.

The lower waveform marks the current measurement routine, with samples taken just before the falling edge of the first nine pulses. The (manually tweaked) delay between the samples forces them to span one complete cycle of the waveform, but they’re not synchronized to the power line. Remember that the motor runs from a full wave rectifier, so each “cycle” in that waveform is half of a normal power line cycle.

Given an array containing those nine samples, the routine must return the maximum value of the waveform, ignoring the little glitch at the start of the flat top and taking into consideration that the waveform won’t have a flat top (or much of a glitch) when the current “limit” exceeds the maximum motor current.

After a bit of fumbling around with the scope and software, the routine goes like this:
- Collect samples during one current cycle
- Sort in descending order
- Ignore highest sample
- Return average of next two highest samples
Given that the array has only nine samples, I used a quick-and-dirty bubble sort. The runt pulse at the end of the series in the bottom waveform brackets the sort routine, so it’s not a real time killer.

Seeing as how this is one of the very few occasions I’ve had to sort anything, I wheeled out the classic XOR method of exchanging the entries. Go ahead, time XOR against swapping through a temporary variable; it surely doesn’t make any difference at all on an 8-bit microcontroller.

The sampling code, with all the tracing stuff commented out:
```
//------------------
// Sample current along AC waveform to find maximum value
//	this is blocking, so don't call it every time around the main loop!

#define NUM_I_SAMPLES	9

unsigned int SampleCurrent(byte PinNum) {
	
unsigned int Samples[NUM_I_SAMPLES];
unsigned int AvgSample;
byte i,j;
	
//	digitalWrite(PIN_SYNC,HIGH);
	for (i=0; i < NUM_I_SAMPLES; i++) {				// collect samples
//		digitalWrite(PIN_SYNC,HIGH);
		Samples[i] = ReadAI(PinNum);
//		digitalWrite(PIN_SYNC,LOW);
		delayMicroseconds(640);
	}
//	digitalWrite(PIN_SYNC,LOW);
	
//	digitalWrite(PIN_SYNC,HIGH);							// mark start of sorting
	for (i=0; i < (NUM_I_SAMPLES - 1); i++)
		for (j=0 ; j < (NUM_I_SAMPLES - 1 - i); j++)
			if (Samples[j] < Samples[j+1]) {
				Samples[j] ^= Samples[j+1];					// swap entries!
				Samples[j+1] ^= Samples[j];
				Samples[j] ^= Samples[j+1];
			}
//	digitalWrite(PIN_SYNC,LOW);								// mark end of sorting
	
//	printf("Samples: ");
//	for (i=0; i < NUM_I_SAMPLES; i++)
//		printf("%5d,",Samples[i]);
	
	AvgSample = (Samples[1] + Samples[2])/2;				// discard highest sample
//	printf(" [%5d]\r\n",AvgSample);
	
	return AvgSample;

}
```
2014-11-11
Kenmore 158: Motor RPM Sensor Deglitching
The setscrew in the motor pulley lies directly in the path of the photosensor:

TCTR5000 Motor RPM Sensor – side view

Which produces a glitch in the rising edge of the digital output as the pulley rotates from the dark to the light section:

Motor Sensor – Rising Edge Glitch

The RPM signal goes to Arduino pin D2, where each falling edge triggers an interrupt handler:
```
const byte PIN_MOTOR_REV = 2;		// DI - IRQ 0 (must be D2)

... snippage...

void setup() {
... snippage ...

    pinMode(PIN_MOTOR_REV,INPUT_PULLUP);
    attachInterrupt((PIN_MOTOR_REV - 2),ISR_Motor,FALLING);			// one IRQ / motor revolution

 ... snippage ...
}
```
The maximum motor speed is about 11 kRPM, so interrupts should be at least 5.5 ms apart and the digital input should be low. If that’s true, then the code updates a bunch of useful information:
```
struct pulse_t {
 byte Counter;
 unsigned long TimeThen;
 unsigned long Period;
 word RPM;
 byte State;
};

struct pulse_t Motor;

... snippage ...

//------------------
// ISR to sample motor RPM sensor timing

void ISR_Motor(void) {

static unsigned long Now;

	digitalWrite(PIN_SYNC,HIGH);

	Now = micros();

	if ((5000ul < (Now - Motor.TimeThen)) && !digitalRead(PIN_MOTOR_REV) ) {	// discard glitches
		Motor.Counter++;
		Motor.Period = Now - Motor.TimeThen;
		Motor.TimeThen = Now;
		Motor.State = digitalRead(PIN_MOTOR_REV);		// always zero in a Physics 1 world
	}

	digitalWrite(PIN_SYNC,LOW);
	return;
}
```
The scope trace shows that the handler takes about 7 µs to get control after the glitch (the left cursor should be on the falling edge, not the rising edge), so the input read occurs when the sensor output is over 4.5 V, causing the handler to discard this spurious interrupt.

Because Motor.Period is a four-byte unsigned long, the Arduino’s CPU must handle it in chunks. Rather than disable interrupts around each use, it’s better to read the value until two successive copies come back identical:
```
//------------------
// Return current microsecond period without blocking ISR

unsigned long ReadTime(struct pulse_t *pTime) {

unsigned long Sample;

	do {
		Sample = pTime->Period;				// get all four bytes
	} while (Sample != pTime->Period);		//  repeat until not changed by ISR while reading

	pTime->Counter = 0;						// this is a slight race condition

	return Sample;
}
```
Because the interrupts don’t happen that often, the loop almost always executes only one time. On rare occasions, it’ll go back for another two values.

Converting the pulley rotation period into revolutions per minute goes like this:
```
		Motor.RPM = 60000000ul/ReadTime(&Motor);		// one (deglitched) pulse / rev
```
That’s easier than hiding the setscrew and it also discards any other glitches that may creep into D2…
2014-11-10
Kenmore 158: Motor RPM and Shaft Sensor First Light

Using basically the same Arduino firmware as before, so the pedal scales the motor current without feedback:

Curr Sense RPM Spindle Pos

The top trace is the motor current, sampled through the ferrite toroid / Hall effect sensor / differential amp, at about 525 mA/V, so the current limit along those flat tops is 630 mA. There’s a small initial spike leading into each flat top, where (I think) the rapidly rising collector voltage rams enough current through the Miller capacitance into the base to briefly push the collector current upward.

The next trace is the motor RPM sensor, ticking along at 14 revolutions in 160 ms = 87.5 rev/s = 5250 RPM. The glitch toward the right side comes from me hitting the scope’s STOP button to freeze the display in mid-trace. There’s no trace of the setscrew glitch, although that may be due to the compressed scale rather than the absence of the glitch.

The bottom trace is the shaft position sensor, with 1 rev in 125 ms = 8 rev/s = 480 RPM. It’s nicely divided into equal halves, which is what you’d expect from looking at the counterweight.

Under these conditions the speed ratio works out to 10.93, a whopping 9% over my original guesstimate.

2014-11-07
Kenmore 158: Power Switch Timing
The crash test dummy sewing machine now has a cheerful red momentary pushbutton in the same spot the original machine sported a 120 VAC push-on/push-off power switch:

Kenmore 158 – Digital Power Switch

It’s held in place by a dab of epoxy on the bottom. The threads aren’t quite long enough to engage the ring, so another dab of epoxy holds that in place. In the unlikely event I must replace the button, I’ll deploy a punch and hammer it out from the top; the slick paint on the sides of the straight-sided hole doesn’t provide much griptivity.

The button connects in parallel with the GX270’s front-panel button and the one on the Low Voltage Interface Board, so it operates exactly the same way. My original code didn’t include a delay before turning the power off, which meant that brushing the switch while doing something else would kill the power.

This is not to be tolerated…

You (well, I) must now hold the button down for one second to turn the power off. Releasing it before the deadline has no effect, other than blinking the green power LED on the front panel a few times.

The routine maintains a timer that allows it to yield control to the mainline code, rather than depend on a blocking timer that would screw up anything else that’s in progress:
```
//------------------
// Handle shutdown timing when power button closes
// Called every time around the main loop

void TestShutdown(void) {
	
	if (LOW == digitalRead(PIN_BUTTON_SENSE)) {			// power button pressed?
		if (ShutdownPending) {
			if (1000ul < (millis() - ShutdownPending)) {
				printf("Power going off!\r\n");
				digitalWrite(PIN_ENABLE_AC,LOW);
				digitalWrite(PIN_ENABLE_ATX,LOW);
				while(true) {
					delay(20);
					TogglePin(PIN_PWR_G);				// show we have shut down
				}
			}
		}
		else {
			ShutdownPending = millis();					// record button press time
			printf("Shutdown pending...\r\n");
		}
	}
	else {
		if (ShutdownPending) {
			ShutdownPending = 0ul;						// glitch or button released
			printf("Shutdown cancelled\r\n");
		}
	}
}
```
The normal Arduino bootloader imposes a similar delay while turning the power on, which means that you can’t accidentally light the machine up by bumping the switch. All in all, it’s much more user-friendly this way.
2014-11-06