Washing Machine Repurposed
Modern appliances claim to be more efficient, but they’re certainly not designed to last as long as older models. In this project article, Brian describes how he reused subsystems from a defunct modern washing machine to power his bandsaw. The effort provides valuable insights on how to make use of the complete 3-phase Variable Frequency Drive (VFD) borrowed from the washing machine.
Twelve years ago, we decided to replace our still-functional 25-year-old G.E. washer with a new “high efficiency” front-loading model. It claimed to save lots of hot water, and reduce electrical energy use. It lived up to that promise, but 10 years later it became extremely noisy. Googling this model uncovered a litany of videos on how the drive mechanism/bearings on front-loading washers were poorly designed. If you’re interested, just Google the subject for yourself, but the short story is that it would not be cost-effective to repair this machine when the bearings wore out. We dropped the spin speed down from fast to slow, to minimize the noise symptoms somewhat (negating some of the efficiency gains provided by the high spin rate), and kept it working for another year or so, before it finally died.
I worry that we may fool ourselves into thinking that we are protecting the environment by purchasing modern appliances touted as being “green” or “high-efficiency.” In my case, I doubt that I made the most environmentally friendly choice, because my older washer continued to work for another family member for three more years (28 in total). In contrast, the new one only lasted 12 years before it added almost 200 pounds to the local landfill.
Before I took the washer to the curb for pickup, I took it apart and saved a very nice 3-phase motor, a motor controller and the mechanical cycle timer. My thoughts were that I could re-purpose the motor for use on my band saw. My band saw is a carpentry model, which operates at a high blade speed, suitable for wood. Lately, however, I’ve wanted to use it for cutting metal, which requires a much slower speed. I was hoping that the washer motor and its companion motor controller would serve the purpose. During the wash cycle, the motor turns very slowly. But in the spin cycle the motor really revs up—probably why the bearings don’t last so long.
To run an AC motor at variable speeds with useable torque, you need a Variable Frequency Drive (VFD). Also, because homes are only supplied with a single-phase electricity supply, a VFD is required to generate the 3-phase power that this motor requires. With that in mind, I knew that the motor controller module from the washer must contain a complete 3-phase VFD. I was hoping that I could get it to do what I wanted. This turned out to be more complicated than I had hoped, but it certainly made for a very interesting project.
MOTOR CONTROLLER DETAILS
Initially, I was hoping for an easy solution. That is, I hoped that the mechanical timer in the washer was the real “brains” of the unit—that it would send the “dumb” motor control module “commands” via the timer switch closures. Having worked for G.E. Appliance Service Division at the start of my career, I was well-versed in the workings of mechanical timers used in washers/dryers of the day. Forty years ago, these mechanical timers were indeed the “brains” in the appliance.
Had I paid much attention to the way modern front-loading washers work, I would have realized that the wash cycle consists of many short bursts of low-speed tumbling—reversing every 20 seconds or so. The spin cycle involves a somewhat slow acceleration, from rest up to whatever final speed setting you have chosen on the front panel. Even though these mechanical timers are quite complex—containing about 10 cams—they could not possibly handle that many short and different “phases” of the wash cycle.
Figure 1 shows a block diagram of the motor controller module in this Kenmore 970-C45162 washing machine. Sears provided a very good wiring diagram/troubleshooting guide for the complete washer, but a detailed schematic for the motor control module itself was not provided, nor did I expect it. Therefore, I did some “reverse-engineering” to come up with this block diagram. In my early investigative stages, I wired up the timer switch assembly to the motor controller and manually advanced it through the various cycles, to see how the controller performed. This would have been impossible to do without the good wiring diagram Sears had provided with the machine.
This controller uses a custom, masked-ROM DSP device—the Analog Devices (ADI) ADMC326YR. This is basically an ASIC device for OEMs, based upon ADI’s ADSP-2171 general-purpose DSP device. ADI also sold EEPROM versions of the ADMC326YR—for development purposes—when they first introduced the chip. But the EEPROM variant was not available from distributors when I checked.
While not shown in the block diagram, six or so switch contacts (driven by cams in the timer) are connected to GPIO pins of the ADMC326YR. As the timer advances and these switch states change, the DSP in the ADMC326YR generates the requisite 3-phase PWM signals needed to run the motor in the direction/speed required. However, for each “phase” of the wash cycle—which may last from 2 to 20 minutes—the ADMC326YR will modify the 3-phase PWM outputs frequently. For example, in the wash cycle, it will rotate slowly, in short bursts, for 20 s or so, then reverse. It will repeat this process for 10 to 20 minutes.
FROM DSP TO MCU
Long story short, there was no way to use the ADMC328YR DSP for my purposes. What I need is to be able to select certain speeds within the overall range of the motor, and have the motor maintain this indefinitely, until I select another speed or shut it down. Also, given that I would be driving a band saw, I only need one rotational direction, because the bandsaw blade cuts in only one direction. However, I made provisions for both directions. I knew I would need to replace the ADMC326YR’s firmware with a microcontroller (MCU) running my own code.
In the factory-designed motor controller, the ADMC326YR produces three PWM signals, each 120 degrees apart in phase. It also produces the complement of each of these three PWM signals. This is needed because each of the 3-phase PWM signals feeds a half-H-bridge power control circuit, and to do so requires two complementary signals. The ADMC326YR also handles the issue that the two complementary PWM signals (for each phase) cannot be “perfectly” complementary. If they were, there would be very short intervals during which both power control devices in the half-H-bridge would be conducting at the same time. This is due to differences in the turn-on and turn-off times of the power devices used (either MOSFETs or IGBTs), and to inherent delays in the circuitry that drives them. If both switching devices were to conduct at the same time, even very briefly, the resulting direct short across their power source would likely destroy them. The ADMC326YR inserts a “dead time” into the complementary signals to prevent this short-circuiting from occurring.
The other major active device in the motor controller is an International Rectifier (now Infineon Technologies) IR2136S 3-Phase H-bridge driver. This device converts the six TTL-level PWM drive signals into the drive signals needed to operate the six MOSFET (or IGBT) switching devices. The IR2136S contains its own “dead-time insertion” circuitry, so, strictly speaking, the ADMC326YR doesn’t really need to take care of this issue. The device also contains some current-sensing circuitry that performs over-current fault protection. The version of IR2136 used in this motor controller needs active-low PWM drive signals, whereas the ADMC326YR provides active-high PWM signals. While it’s likely the manufacturer could have used chips that had matching logic signal conventions, they chose to use a 74HC14 Hex Inverting Schmitt-trigger device to handle the logic inversion. Probably the 74HC14’s Schmitt-triggers were the more important feature, because they provide more noise immunity to the overall circuit.
The three half-H-bridge circuits used in this controller were mounted directly on the unit’s metal enclosure (for heat-sinking) and were connected to the main PCB via a wide, flexible FPC connector. Since the output switching transistors were not directly accessible without tearing the whole unit apart, I didn’t investigate whether the switching transistors used were MOSFETs or IGBTs.
In Figure 1, you can see that the HV power for the unit is obtained by a half-wave voltage doubler, providing a total of roughly 320 VDC to the half-H-bridge drive circuits. In reality, it provides ±160 VDC with respect to the mains (grid power) neutral line. You can see here that the Logic Common reference point (for the ADM326YR and IR2136S), is connected to the -160 VDC node. So, all the control circuitry floats at -160 V with respect to mains Neutral. Signal-conditioning circuitry in the motor controller interfaces the timer switch contacts—which operate at 120 VAC—with the ADMC326YR’s GPIO inputs, handling this difference in ground reference.
CONNECTING THE MCU
While I was designing the MCU circuitry to replace the ADMC326YR, I had to be careful how I connected my replacement MCU to the original motor controller. I definitely could not connect the motor controller to my MCU board while it was simultaneously connected to a computer via the USB port for programming/debugging. Because the computer’s USB port ground is referenced to mains Neutral, that would mean I was connecting the Neutral-referenced MCU board to the motor controller circuitry, which had its logic common referenced to -160 VDC.
This was not the only problem. Early on, I needed to determine what waveforms were being generated by the ADMC326YR. I had a rough idea, but needed more exact details, which could only be obtained by oscilloscope measurements. Nearly all oscilloscopes, including my old Tektronix analog scope and Siglent Technologies SDS 1202X digital storage scope, have their ground terminals connected to mains Neutral. So, the same ground-reference problems mentioned above existed here as well.
Luckily, I had previously built a 100 VA isolation transformer for use with my scopes. I used two identical transformers, salvaged from cordless power tool battery chargers, and wired them back-to-back. During this project, I chose to run the scope directly from the power line, and used the isolation transformer to power both the motor controller and 3-phase motor. This meant that the logic common of the controller was no longer at a potential of -160 VDC, as mentioned earlier. Instead, it was floating with respect to mains ground.
While the 100 VA capacity of the transformer was not enough to run the motor at anywhere near full-power, it was adequate for initial testing/reverse engineering purposes. As a bonus, I figured that if there were something drastically wrong with my program, the destructive power available would be limited by the 100 VA isolation transformer. I was also aware that the large filter capacitors in the power supply would negate this to some extent.
Even with the isolation transformer powering the motor controller module itself, during development I was cautious, and programmed the MCU board in my office, using that PC, and then carried the board down to my basement shop. Whenever I hooked it up to the motor controller, my MCU board was powered by an isolated 5 V power supply.
I never seriously considered wiring my replacement MCU directly to the remaining circuitry of the original motor controller. Once my initial investigation/reverse-engineering was done, I planned to use three Silicon Labs SI8620BB-B dual isolators to couple the six PWM signals between my MCU circuit and the original controller circuit. The SI8620s easily handle the 160 VDC difference between the motor controller’s logic common and Neutral and are so fast that they don’t affect the timing of the PWM signals in any significant way.
You might wonder why I didn’t just leave my added MCU circuitry floating at the motor controller’s -160 VDC logic common potential, once the design was finalized. My additional controller circuit was going to have an LCD display, rotary encoder and some push-button switches. It was not practical to have those all referenced to something other than Neutral, for safety reasons.
Safety Note: As mentioned above, this project involves working with high voltages—±160 V with respect to mains ground. Also, the two large power supply filter capacitors in the original motor controller did NOT have bleeder resistors mounted across them, so high voltages persist even when the AC power is removed. I had to discharge these by hand, when doing my initial investigative work. The reader should proceed with caution if tackling a project like this.
GENERATING 3-PHASE SINE WAVES
I have used PWMs to generate DC voltages (in place of a DAC), and was also somewhat familiar with Class “D” audio amplifiers, which use PWM signals to generate high-fidelity audio. But I had never before needed to generate 3-phase sine wave signals using PWMs.
An initial Web search led me to the upper part of the diagram shown in Figure 2. At first glance, it would seem logical that you would generate a varying PWM signal that drove the upper gate of the half-H-bridge, using the PWM signals that are shown superimposed on the positive half of the sine wave. The lower gate of the half-H-bridge would be driven by a separate PWM signal, displaced in time by one-half of the period of the signal you were synthesizing—that is, the PWM signals superimposed on the negative half of the sine wave. Three pairs of such signals, each 120 degrees apart, would provide the requisite 3-phase AC voltages needed for the motor.
When I hooked up my oscilloscope to each of the six PWM signals coming from the ADMC326YR, it was clear that this controller did not work this way at all. Also, the assumptions from the previous paragraph do not line up at all with the way that complementary PWM signals (for motor control) are generated in any of the MCUs that I had used in the past. Instead, during the positive portion of the sinewave, you will see various duty cycles of both the “normal” and the “complementary” PWM pulses. The same thing applies for the negative portion of the sine wave. To put it another way, for the positive half cycle, the “normal” PWM output will be high 50-100% of the time, but the “complementary” PWM output will also be high for 0-50% of the time—depending on where you are within the cycle. The opposite will be true for the negative portion of the sine wave.
This can be seen in Figure 3, where I have superimposed both scope channels. The yellow trace is the “normal” PWM output, and the purple trace is the “complementary” output. You can see where the two basically add up to 100% of the period, except for the short region that is marked by the vertical yellow cursors. This is the “dead-time” region mentioned earlier. These scope traces are the actual signals that I now feed the IR2136S 3-phase H-bridge driver in the original motor controller. At the top right, you can see that the PWM frequency is 10.788 kHz. This is just one single scope capture- you can see that the “complementary” PWM output is the longer of the two. At the instant of this capture, the sine wave was somewhere in the negative half of its cycle. If you slow the scope sweep time down significantly, and take a single capture, you can see traces like those in Figure 4. While you can’t make out actual PWM detail, you can discern that the purple trace is at its most dense 180 degrees out of phase with the yellow trace, as you would expect with complementary outputs.
From this investigation, I knew that I would need to use an MCU containing three PWM circuits, each of which contained complementary outputs. I wanted the PWM resolution to be at least 8-bits, preferably more. And I wanted the overall PWM period to be the same as used in the original motor controller: roughly 11 kHz.
Doing the math, at 10-bit resolution and 11 kHz period, I needed the PWM circuits to be clockable at: 11,000×210 or 11.2 MHz. This is well within the clock speeds of the PWMs contained in various MCUs that I had in mind to use.
I started this project between Christmas and New Year’s. With the holidays, I couldn’t get parts the next day from Digi-Key, as I usually do. While I had several different MCU boards on hand, I had only a few single-channel isolators, and none of the SI8620 isolators. So, my initial experiments were made without the isolators—very carefully!
Besides isolation, the SI8620s can also provide logic-level translation. In the original motor controller, the IR2136S device and the 74HC14 inverters that feed it are running at 5 V logic levels. Most Arm MCUs, including the Teensy 3.x boards that I frequently use, operate at 3.3 V power and logic levels. The NXP Semiconductor Kinetis MCUs found on Teensy boards contain a fancy FlexTimer module that will easily do 3-phase PWM motor control—including dead-time insertion and fault control. I quickly wrote the code to try it out, and the waveforms looked fine on the scope. Unfortunately, the 3.3 V logic levels would not drive the 74HC14 on the motor controller. When the SI8620 isolators finally arrived, they would have taken care of this logic level issue, but I was too impatient to wait.
In the past, I had done some projects using Cypress Semiconductor’s PSoC family of Programmable System-on-Chip devices. The newer PSoC4 and 5LP devices are Arm-based, but they can be powered by and accept logic-level signals at 5 VDC. These PSoC devices are unique in that you can basically design how you want their internal circuit blocks to be allocated and configured, both from an analog and a digital perspective. What would normally be a rather complex design process involving Verilog is handled by Cypress’ Creator 4.2 IDE application. It hides most of the complexity of these tasks with a much simpler drag and drop GUI interface.
For this project, the PSoC 5LP family seemed ideal. Cypress sells the CY8CKIT-059 development board for only $10. It contains the CY8C5888LTI-LP097 MCU, and a full SWD programmer/debugger/USB serial port (on a tiny snap-off module). All the digital and analog functions needed for this project can be handled internally by the CY8C5888LTI-LP097 PSoC device, itself.
In part 2 of this article series (Circuit Cellar 350, September 2019), I’ll describe in detail how I used the PSoC 5LP to handle both of the motor control PWM functions, and to provide a user interface.
For detailed article references and additional resources go to:
Analog Devices | www.analog.com
Cypress Semiconductor | www.cypress.com
Digi-Key | www.digi-key.com
Infineon Technologies | www.infineon.com
NXP Semiconductor | www.nxp.com
Tektronix | www.tektronix.com
Siglent Technologies | www.siglent.com
Silicon Labs | www.siliconlabs.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2019 #348 – Get a PDF of the issueSponsor this Article