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 UI: Button Rework

    Simplifying the Kenmore 158 UI’s buttons definitely improved the user experience:

    Kenmore 158 Controller - Simplified Buttons
    Kenmore 158 Controller – Simplified Buttons

    The trick depends on specifying the colors with HSB, rather than RGB, so that the buttons in each row have the same hue and differ in saturation and brightness. The Imagemagick incantations look like this:

    • Disabled: hsb\(${HUE}%,50%,40%\)
    • Unselected: hsb\(${HUE}%,100%,70%\)
    • Selected: hsb\(${HUE}%,100%,100%\)

    For whatever reason, the hue must be a percentage if the other parameters are also percentages. At least, I couldn’t figure out how to make a plain integer without a percent sign suffix work as a degree value for hue.

    Anyhow, in real life they look pretty good and make the selected buttons much more obvious:

    Kenmore 158 UI - Simplified buttons - contrast stretch
    Kenmore 158 UI – Simplified buttons – contrast stretch

    The LCD screen looks just like that; I blew out the contrast on the surroundings to provide some context. The green square on the left is the Arduino Mega’s power LED, the purple dot on the right is the heartbeat spot.

    The new “needle stop anywhere” symbol (left middle) is the White Draughts Man Unicode character: ⛀ = U+26C0. We call them checkers here in the US, but it’s supposed to look like a bobbin, as you must disengage the handwheel clutch and stop the main shaft when filling a bobbin; the needle positioning code depends on the shaft position sensor.

    Weirdly, Unicode has no glyphs for sewing, not even a spool of thread, although “Fish Cake With Swirl” (🍥 = U+1F365) came close. Your browser must have access to a font with deep Unicode support in order to see that one…

    You can’t say I didn’t try:

    Unicode characters - bobbin-like shapes
    Unicode characters – bobbin-like shapes

    The script that generates all the buttons:

    ./mkBFam.sh NdDn  9 ⤓
    ./mkBFam.sh NdUp  9 ⤒
    ./mkBFam.sh NdAny 9 ⛀ 80 80 40
    ./mkBFam.sh PdOne 33 One 120 80
    ./mkBFam.sh PdFol 33 Follow 120 80
    ./mkBFam.sh PdRun 33 Run 120 80
    ./mkBFam.sh SpMax 83  🏃 80 80 40
    ./mkBFam.sh SpMed 83  🐇 80 80 40
    ./mkBFam.sh SpLow 83  🐌
    montage *bmp -tile 3x -geometry +2+2 Buttons.png
    display Buttons.png
    

    The script that generates all the versions of a single button:

    # create family of button images
    # Ed Nisley - KE4ZNU
    # March 2015
    
    [ -z $1 ] && FN=Test || FN=$1
    [ -z $2 ] && HUE=30  || HUE=$2
    [ -z $3 ] && TXT=x   || TXT=$3
    [ -z $4 ] && SX=80   || SX=$4
    [ -z $5 ] && SY=80   || SY=$5
    [ -z $6 ] && PT=25   || PT=$6
    [ -z $7 ] && BDR=10  || BDR=$7
    
    echo fn=$FN hue=$HUE txt=$TXT sx=$SX sy=$SY pt=$PT bdr=$BDR
    
    echo Working ...
    
    echo Shape
    
    echo Buttons
    echo  .. Disabled
    convert -size ${SX}x${SY} xc:none \
      -fill hsb\(${HUE}%,50%,40%\) -draw "roundrectangle $BDR,$BDR $((SX-BDR)),$((SY-BDR)) $((BDR-2)),$((BDR-2))" \
      ${FN}_s.png
    convert ${FN}_s.png \
      -font /usr/share/fonts/custom/Symbola.ttf  -pointsize ${PT}  -fill gray20  -stroke gray20 \
      -gravity Center  -annotate 0 "${TXT}"  -trim -repage 0x0+7+7 \
      \( +clone -background navy -shadow 80x4+4+4 \) +swap \
      -background snow4  -flatten \
      ${FN}0.png
    
    echo  .. Enabled
    convert -size ${SX}x${SY} xc:none \
      -fill hsb\(${HUE}%,100%,70%\) -draw "roundrectangle $BDR,$BDR $((SX-BDR)),$((SY-BDR)) $((BDR-2)),$((BDR-2))" \
      ${FN}_s.png
    convert ${FN}_s.png \
      -font /usr/share/fonts/custom/Symbola.ttf  -pointsize $PT  -fill black  -stroke black \
      -gravity Center  -annotate 0 "${TXT}"  -trim -repage 0x0+7+7 \
      \( +clone -background navy -shadow 80x4+4+4 \) +swap \
      -background snow4  -flatten \
      ${FN}1.png
    
    echo  .. Pressed
    convert -size ${SX}x${SY} xc:none \
      -fill hsb\(${HUE}%,100%,100%\) -draw "roundrectangle $BDR,$BDR $((SX-BDR)),$((SY-BDR)) $((BDR-2)),$((BDR-2))" \
      ${FN}_s.png
    convert ${FN}_s.png \
      -font /usr/share/fonts/custom/Symbola.ttf  -pointsize ${PT}  -fill black  -stroke black \
      -gravity Center  -annotate 0 "${TXT}"  -trim -repage 0x0+7+7 \
      \( +clone -background navy -shadow 80x4+4+4 -flip -flop \) +swap \
      -background snow4  -flatten \
      ${FN}2.png
    
    echo BMPs
    for ((i=0 ; i <= 2 ; i++))
    do
     convert ${FN}${i}.png -type truecolor ${FN}${i}.bmp
    # display -resize 300% ${FN}${i}.bmp
    done
    
    rm ${FN}_s.png ${FN}?.png
    
    echo Done!
    
  • Kenmore 158: Bobbin Winder Repair

    For reasons which are, trust me on this, not relevant here, we now have a third Kenmore 158 sewing machine: a freebie that sat under a roof leak in an unused room some years ago and wasn’t cleaned before being stored. Even though not much water got inside the covers, the bobbin winder shaft froze solid.

    Two black screws hold it to the cover and provide a slight adjustment of the tire-to-handwheel distance:

    Bobbin Winder - old tire
    Bobbin Winder – old tire

    Prior to this adventure, I soaked the shaft in penetrating oil for a week or two, but to no avail.

    I didn’t take any before-the-repair photos, but it looked like this afterward, with the new tire installed…

    From the top right (looking over the handwheel):

    Bobbin Winder - assembled - top right
    Bobbin Winder – assembled – top right

    Notice the small rectangular hole just below the larger section of the shaft in the protruding part of the pot metal housing. That’s supposed to be an oil hole, but it’s also a fine water inlet.

    From the top left:

    Bobbin Winder - assembled - top left
    Bobbin Winder – assembled – top left

    The two obvious screws remove the obvious parts, but beware the compression spring:

    Bobbin Winder - fill sense lever
    Bobbin Winder – fill sense lever

    And the torsion spring:

    Bobbin Winder - drive latch
    Bobbin Winder – drive latch

    Some experimentation with a strap wrench rotated the wheel on the (still firmly frozen) shaft, which suggested the joint was a press fit without a setscrew, splines, or adhesive.

    Grabbing the shaft lightly in a machinist’s vise, resting it atop the bench vise, and giving it a few shots with a drift punch drove it downward through the housing:

    Bobbin Winder - driving out spindle
    Bobbin Winder – driving out spindle

    More gentle beating produced this heartrending scene:

    Bobbin Winder - corroded shaft
    Bobbin Winder – corroded shaft

    Water just isn’t any good at all for unlubricated steel in a pot-metal bushing…

    Anyhow, the shaft & housing cleaned up well, although they look a tad grody, and everything went back together in the reverse order.

    I added a drop of light oil through the lube port, chucked the shaft in the drill press, spun it for a minute at low speed to wear off a slight binding, and it’s all good again.

  • Kenmore 158: Bobbin Winder Tires

    The bobbin winder atop the Kenmore 158 sewing machine has a rubber tire that contacts a ribbed ring on the inside surface of the handwheel; the clutch knob disengages the main shaft and you run the motor at top speed. As you’d expect, both age and wear take their toll on the rubber, to the extent that the winder on Mary’s machine stopped turning. I swapped it for the slightly less decrepit winder on the Crash Test Dummy, but that was obviously a stop-gap measure.

    I mistakenly thought the metal wheel consisted of two plates that clamped a rubber disk in place, with no possibility of removal:

    Bobbin Winder - old tire
    Bobbin Winder – old tire

    The fact that the spare parts list didn’t include the rubber disk helped convince me.

    Eventually, I stumbled over replacement “tires” on, of course, eBay that suggested how to dismount them:

    Bobbin Winder - wheel and tires
    Bobbin Winder – wheel and tires

    Yup, that sucker slides right off.

    Anyhow, the replacements seem to be standard industrial O-rings, rather than the original tire with a flattened rim:

    Bobbin Winder - old vs new tire
    Bobbin Winder – old vs new tire

    The new tires measure 28.94 mm OD on the bench (I don’t trust that last digit, either) and 29.56 mm OD installed. The (hardened and cracked) old tires measure 29.94, 30.06, and 30.28 mm OD on the bench; that’s a radius anywhere from 0.2 mm to 0.4 mm larger. The winder’s mounting screws provide a very small adjustment range that helps a bit.

    Knowing that I needed an O-ring, I checked the assortment of “standard size” O-rings I bought many, many years ago, which once again failed to offer up anything suitable. To the best of my knowledge, that kit has never had the right size; apparently, every application uses a different standard.

    The O-ring definitely puts less rubber on the handwheel than the tire, but seems to drive the bobbin winder well enough to fill a handful of bobbins without any of the previous drama.

  • Kenmore 158: Linearized Speed Control

    Plugging the normalized pedal position into the code that turns position into speed:

    case PD_RUN :
    	if (PedalPosition > 5) {
    		if (MotorDrive.State != RUNNING) {
    			EnableMotor();
    			MotorDrive.State = RUNNING;
    		}
    
    		BaseDAC.setVoltage(0x0fff,false);								// give it a solid pulse
    		SampleCurrent(PIN_CURRENT_SENSE);								// sample over a half cycle
    		if (DriveOnTime > CurrentSamplingTime) {
    			delay(DriveOnTime - CurrentSamplingTime);
    		}
    
    // Pedal to the metal?
    //   ... if so, stall here with motor drive fully on until the pedal releases
    
    		while ((MotorDrive.SpeedRange == SPEED_HIGH) && (PedalPosition >= 100)) {
    			PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
    		}
    
    		BaseDAC.setVoltage(0,false);									//  ... then turn it off
    
    		delay(map(constrain(PedalPosition,0,PedalMaxClamp),
    				0,100,
    				DriveOffTime,0));
    	}
    	else {
    		if (MotorDrive.State == RUNNING) {
    			if (MotorSensor.RPM) {
    				printf("Coast: %d\r\n",MotorSensor.RPM);
    				delay(100);
    			}
    			else {
    				printf("Parking ");
    				ParkNeedle(MotorDrive.ParkPosition);
    				MotorDrive.State = STOPPED;
    				printf(" stopped\r\n");
    			}
    		}
    	}
    	break;
    

    The magic happens in highlighted statement, which flips the sense of the pedal motion and linearly scales the result into a delay() value ranging from 120 ms (pedal barely pressed) down to 0 ms (pedal almost fully pressed). If the pedal is all the way down, then the preceding while() locks up until it’s released a bit, whereafter the delay will be nearly zero.

    That sorta-kinda worked, but the user community said that the pedal response required pushing too hard for top speed: it should get faster, sooner. The problem came from the simplistic way I set the speed: it was inversely proportional to the position.

    Plotting speed against pedal position shows the problem:

    Speed vs pedal - period control
    Speed vs pedal – period control

    I figured the right approach was to make the speed vary linearly with the pedal position, so the trick was to plot the off-time delay vs. the actual speed:

    Off-time delay vs speed - period control
    Off-time delay vs speed – period control

    The second-order equation bottles up a bunch of nonlinear things. Given that this was using the original code, I made the dubious assumption that more-or-less the same delay in the new code would produce more-or-less the same speed.

    The new code discards the current-sampling routine that I was using to get a fixed delay (because I don’t need to know the current in pulse-drive mode), then used that time for the floating-point calculation required to find the off-time delay. That chunk of code took a bit of fiddling to get right:

    case PD_RUN :
    	if (PedalPosition > 5) {
    		if (MotorDrive.State != RUNNING) {
    			EnableMotor();
    			MotorDrive.State = RUNNING;
    		}
    
    		BaseDAC.setVoltage(0x0fff,false);								// give it a solid pulse
    		MillisOn = millis() + (unsigned long)DriveOnTime;
    
    		TargetSpeed = (float)map(constrain(PedalPosition,0,PedalMaxClamp),
    				0,100,
    				0,700);						// quick and dirty 0 to 700 stitch/min range
    		OffTime = (int)((1.94e-4*TargetSpeed - 0.286)*TargetSpeed + 106.0);
    		OffTime = constrain(OffTime,0,120);								// clamp to reasonable range
    		MillisOff = MillisOn + (unsigned long)OffTime;					// compute end of off time
    
    		while (millis() <= MillisOn) {									// wait for end of pulse
    			continue;
    		}
    
    		if ((PedalPosition >= 100) && (MotorDrive.SpeedRange == SPEED_HIGH)) {	// pedal down in full speed mode?
    			printf("Full speed ... ");
    			OffTime = 0;
    			while (PedalPosition >= 100) {								//  ... full throttle!
    				PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
    			}
    			BaseDAC.setVoltage(0,false);								//  pedal released, start coasting
    			printf(" done\r\n");
    		}
    		else {															// pedal partially pressed
    			BaseDAC.setVoltage(0,false);								// pulse done, turn motor off
    			while (millis() <= MillisOff) {								// wait for end of off period
    				continue;
    			}
    		}
    	}
    

    But the result looks as pretty as you could possibly expect:

    Speed vs pedal - linearized speed control
    Speed vs pedal – linearized speed control

    The pedal still provides a soft-start transition from not moving to minimum speed, which remains an absolute requirement: having an abrupt transition to that straight line would be a Bad Thing. Fortunately, the nature of the magnet moving toward the Hall effect sensor gives you that for free.

    Although we’re still evaluating the results, the user community seems happier…

  • Kenmore 158: Normalized Pedal Position

    Adjusting the output voltage vs. position for the sewing machine’s food pedal quickly revealed that the code shouldn’t depend on the actual ADC values. That’s blindingly obvious in hindsight, of course.

    The maximum with the pedal in its overtravel region doesn’t change by much, because the Hall effect sensor output voltage saturates in a high magnetic field. I used a hardcoded word PedalMax = 870; which comes from 4.25 V at the ADC input.

    On the low end, the sensor output can change by a few counts depending on small position changes, so I sampled the (presumably released) pedal output during the power-on reset:

    	PedalMin = ReadAI(PIN_PEDAL);				// set minimum pedal input value
    	printf("Set PedalMin: %u\r\n",PedalMin);
    	PedalMaxClamp = 100;						// set upper speed limit
    
    

    Given the complete ADC range, this function normalizes a value to the range [0,100], conveniently converting the pedal position into a percent of full scale:

    int PedalPercent(word RawPos) {
    int Clamped;
    
    	Clamped = constrain(RawPos,PedalMin,PedalMax);
    	return map(Clamped,PedalMin,PedalMax,0,100);
    }
    

    Graphing the normalized values against pedal position would have the same shape as the ADC values. All I’m doing is rescaling the Y axis to match the actual input limits.

    The top of the main loop captures the pedal position:

    PedalADC = ReadAI(PIN_PEDAL);
    PedalPosition = PedalPercent(PedalADC);
    

    Now, it’s easy to add a slight deadband that ensures the sewing machine doesn’t start when you give the pedal a harsh look; the deadband is now a percent of full travel, rather than a hard-coded ADC count or voltage.

    For example, in needle-follows-pedal mode, you must press the pedal by more than 10% to start the stitch, slightly release it to finish the stitch, and then almost completely release it to proceed to the next stitch:

    	case PD_FOLLOW:
    		if (PedalPosition > 10) {
    			printf("Pedal Follow\r\n");
    			ParkNeedle(NS_DOWN);
    			do {
    				PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
    			} while (PedalPosition > 10);
    			ParkNeedle(NS_UP);
    			do {
    				PedalPosition = PedalPercent(ReadAI(PIN_PEDAL));
    			} while (PedalPosition > 2);
    		}
    		break;
    

    Adjusting percentages turns out to be much easier than fiddling with ADC values.

    Obvious, huh?

  • Kenmore 158: Pedal Recalibration

    With the Crash Test Dummy in place, Mary reports that the pedal required too much motion to reach the full speed position. The graph from the last time around shows the output as a function of pedal position:

    Hall sensor output vs pedal depression
    Hall sensor output vs pedal depression

    I’d done some fiddling around after recording that data, but it remained pretty close to the truth.

    A new scale, not quite in the same spot as the previous one:

    Kenmore 158 - Foot Pedal - motion recalibration
    Kenmore 158 – Foot Pedal – motion recalibration

    The two long lines mark the active region after I finished the mechanical tweaking described below; the pedal now produces nearly full output just beyond the 12 mm mark and has about that much overtravel. Measuring those values requires squeezing the pedal by hand, holding its position, and recording the ADC output dumped by the motor control program in the Arduino, a process that could be improved, but to not much benefit.

    The original pedal writeup goes into the gory details, but the bottom line is that the mechanical motion producing that output range depends on the length of the rod from the actuator bar to the magnet.

    The original version had a thin nut securing a screw inside the brass shaft to the actuator:

    Kenmore 158 - Hall speed control - prototype interior
    Kenmore 158 – Hall speed control – prototype interior

    I later swapped the nut for three washers, after observing that the nut wasn’t actually necessary, but that produced too much dead travel at the beginning of motion.

    We discovered that the actuator bar could slip off the end of the ramp cast into the pedal cover, jamming the end of the ramp, making the case extremely difficult to disassemble, and causing heartache & confusion. Affixing a pair of rubber feet to the rear wall of the pedal case with tapeless sticky keeps the bar about half a millimeter further forward and eliminates that problem:

    Kenmore 158 - foot pedal - short actuation
    Kenmore 158 – foot pedal – short actuation

    A second nut moved the brass rod forward, but that turned out to be a bit too much, so it now has a single, slightly thicker, nut. The 3D printed frame allows for far more travel in each direction than is strictly necessary, specifically to allow this fine tuning; it’s possible to make the rod’s resting position too close to the Hall effect sensor and have them collide at full travel, but I managed to avoid that.

    It’s impossible to measure anything with the case disassembled: each change requires reassembling everything, measuring, and iterating.

    After some of this & that, this graph shows the final output curve, with the Y axis in raw ADC counts at 100/div:

    Foot Pedal - ADC vs position - graph detail
    Foot Pedal – ADC vs position – graph detail

    The first 3 mm doesn’t produce much change in the output, it smoothly changes to the more-or-less linear ramp up to 12 mm, then tapers off to full output beyond 14 mm. That’s pretty close to the original graph, with full throttle occurring a bit more than 2 mm earlier; the difference between the two scales may have some effect. In any event, Mary reports it feels much better.

    Trust me: that matters.

    The original data from the first and second mods, plus a teeny version of that graph:

    Foot Pedal - ADC vs position
    Foot Pedal – ADC vs position
  • Kenmore 158: Crash Test Dummy Installation

    The Crash Test Dummy’s double-walled and somewhat crushed base turns out to be slightly larger front-to-back than the one on Mary’s original Kenmore 158 (which has a later serial number), but it still fits into the cutout in the insulating board we’re using in lieu of a Real Sewing Surface:

    Kenmore 158 Controller - First Quilting
    Kenmore 158 Controller – First Quilting

    Lashing the UI data/power cable to the motor & LED / sensor cables from the sewing machine keeps the Arduino Mega + TFT from falling off the tabletop, but the arrangement reeks of impromptu.

    Early reports indicate that the pedal doesn’t feel quite right, with faster speeds requiring too much travel. Given that I worked hard to get more travel with slower transitions into that thing, differences shouldn’t come as any surprise, but … this will require some tweaking.