In Part 1, Brian began describing the process he used to convert a 3-phase motor and OEM Variable Frequency Drive (VFD) controller—salvaged from his defunct clothes washer—into a variable speed drive for his bandsaw. In this article, he completes the discussion, this time covering the Cypress Semi PSoC5LP SoC he used, the software design and more.
In my last article, I shared how I converted a 3-phase motor and OEM Variable Frequency Drive (VFD) controller from a clothes washer into a VFD for my bandsaw. My bandsaw is a carpentry model, and contained a single-phase 120 VAC motor, which ran at 1,700 RPM. I need to do more metal cutting now, and I wanted to be able to run the saw at both the original high speed (for wood) and at much slower speeds for cutting metal.
I decided to use as much of the original OEM VFD as possible, and use my own microcontroller (MCU) circuit to produce the complementary PWM 3-phase drive signals needed, along with a front panel interface for control and speed monitoring. I chose to use a Cypress Semiconductor PSoC5LP system-on-a-chip (SoC) device. This incorporates a fast Arm processor, and is one of the few Arm processors that will operate at 5 V logic levels needed to interface with the existing OEM motor controller.
I first checked that the PSoC5LP’s pulse width modulation (PWM) circuits would do what I needed, and it turns out that they were up to the task. I was able to include three 16-bit PWM “components” in my design, each of which had complementary outputs, dead-time insertion and a way to turn them all on/off simultaneously. I selected a 24 MHz clock, which would allow a PWM resolution of 2,180 counts (11 bits of resolution) at a PWM frequency of 11 KHz. This matched the PWM frequency of the original OEM VFD. I decided to use the “center-aligned” PWM mode, which is supposed to be better for 3-phase drive usage. This reduced the above PWM resolution by half, to 1,090 counts, which is still an adequate 10 bits.
When you configure PSoC devices, you do so by dragging those functions that you need onto a blank worksheet, generating a schematic diagram of sorts. For the following discussion, please refer to Figure 1 which is schematic redrawn from a screen capture of the “TopDesign” workspace for this design.
The three PWMs are at the right. The six PWM drive signals are labeled AH, AL, BH, BL, CH and CL to match the nomenclature used by the IR2136S motor controller device contained in the washer’s motor control module. All three PWMs are gated by their “kill” inputs. These are tied together and activated by Control_Reg_1, which is controlled in software. Note that while the PWM outputs are complementary, when “kill” is invoked it places both outputs at a low (inactive) level, which is necessary to keep all three motor windings de-energized.
Just below the PWMs is the Quad_Dec_1 block. This is a 16-bit quadrature decoder block implemented in hardware. It is there to monitor the rotary encoder used for parameter adjustments. Next to that is the LCD_Char_1 block, which drives the 20×2-character LCD module needed for the user interface. The LCD panel that I happened to pick from my parts bins was one that had a back-light but also needed a negative supply voltage for its contrast pot circuit. This negative contrast control voltage requirement is rare for LCDs now. I handled this inconvenience by incorporating an 8-bit PSoC PWM into my design and implementing a negative voltage charge pump with a few diodes and capacitors (shown in the lower left of the Figure 1).
The UART_1 block was included strictly for development purposes, and sends out diagnostic messages using “printf” statements. Status_Reg_1 is basically a group of 5 GPIO lines that are used to monitor the pushbutton switches on the front panel.
The clothes washer’s motor was equipped with an inductive tachometer. I decided to monitor the speed using this signal. Connecting my ‘scope directly to the tachometer coil produced the result shown in Figure 2. Yikes! Although you can see the general outline of the tachometer’s sine-wave signal, it was highly corrupted with the switching transients from the 11 kHz PWM drive. To the left of Figure 1, you can see that I used a simple RC filter, made up of R1, R2 and C1, to eliminate this high-frequency interference. Diodes D1 and D2 limit the amplitude of the tachometer signal to 1.2 Vpp, and C2, R3 and R4 level- shift this signal up to +1.024 V, which is the ground reference for the PSOC’s internal analog function blocks.
Figure 3 shows the tachometer signal after it has been cleaned up by this RC filter. Looking at the cursors and 1/ΔT reading, you can see it is 53.19 Hz. This was taken with the motor running at what I expected to be 400 RPM (given the PWM signals I was generating). Four hundred RPM equals 6.666 Hz, so the tachometer signal frequency is eight times that of the motor RPM (53.19/8 = 6.65 Hz). I assume that the tachometer coil must be wound with eight poles, giving this higher frequency signal. During the washer’s normal operation, the motor runs quite slowly at times, and having this higher-frequency representation of the motor speed would allow for better speed/torque control in the original application.
I had no way of knowing how many poles there were for the motor windings, themselves, since this was not shown on the label. So, it was quite possible that when I thought the motor should be turning at 400 RPM (given the PWM signals I was sending to it), it might have only been turning at 200 RPM. This would be the case if I had assumed it was a 2-pole motor when it was actually a 4-pole motor. However, when I set a speed of 60 RPM, you could see the motor shaft was turning once per second, which is pretty easy to judge by eye.
Inside the PSoC5LP, the tachometer’s signal is first amplified by a factor of 8 by PGA_1. It is then sent to Opamp_2, which is a conventional op amp built into the PSoC5LP and configured as a comparator, with about 350 mV hysteresis (to reject noise on the tach waveform). The signal is now digital, and it is fed to Sync_1, where it is synchronized to the PSoC5LP’s internal system clock. This Sync block is definitely needed, as I got very erratic results when I first tried to operate without it.
I initially decided that due to the (relatively) low frequency of the tachometer signal, I would measure the period of the tach signal instead of its frequency. This gives a higher-resolution rotational speed reading in a shorter measurement interval. This method is commonly used in frequency counters for low-frequency readings. Once I realized that the tachometer signal was 8 times rotation speed, I guess I could have just measured frequency directly, but I chose to stick to the period reading, and then convert it to RPM in software.
I determined the tachometer period by measuring clock pulses applied to Counter 1 and capturing this count using the Capture input of Counter_1. I used a clock rate of 50 kHz, so the 16-bit Counter_1 will not overflow until 1.3 seconds have elapsed. The “8x motor speed” output of the tachometer will always toggle in much less time than this, under normal operating circumstances. When the motor is not activated or is stalled, a Counter_1 overflow is detected, and a “stalled” message appears in place of the rpm.
Figure 1 is the PSoC block diagram displayed by the Creator 4.2 application, after I had chosen/configured the necessary PSoC “components.” Creator4.2 allows the user to additionally “draw-in” some or all the external components used in the design, to clarify the overall circuit. I chose to include the external components needed by the tachometer circuitry and the LCD charge pump in this diagram.
However, the “library” of components that you can include this way is limited. It’s not a full schematic capture application like Eagle, for example. Therefore, I drew Figure 4, containing the remainder of my custom circuitry.
In Figure 4, the Cypress CY8CKIT-059 development module is shown to the left. This contains the CY8C5888LTI-LP097 Arm MCU. To the right are the three SI8620 dual isolators used for the six PWM signals. On the input side, these isolators are powered by the 5 V Vcc supply used by my circuitry. On the output side, they are powered by 5 V obtained from the motor controller module itself–the same power supply used by the Infineon Technologies IR2136S. As mentioned before, the IR2136S requires active-low PWM signals, so I sent the active-high PWM signals, generated by the CY8C5888LTI-LP097 MCU through the 74HC14 hex-inverter, as in the original design.
I’ll stress again that the motor controller Logic common is floating at -160 VDC with respect to Mains neutral, so be careful if you are working on such a module. It is also important to note that the two large power supply capacitors used in this module do NOT have bleeder resistors across them, so there will be up to 320 VDC present for a while, unless you discharge them by hand!
The user control panel has a 20×2 backlit LCD display. R1 limits the back-light LED’s current. You won’t see anything on the LCD display until the contrast pot is properly adjusted. For the specific LCD panel that I used, this required a -5 V to be present on the low end of pot VR1 (this slowed me down a bit!). Most LCD panels don’t require this negative bias for the contrast pot, however.
It’s important to note that I had to remove C7 (a 1 µF MLCC capacitor) from the CY8CKIT-059 board in order to use Port 3 for the LCD. On this module, C7 was placed from Port 3.2 to ground, to act as a filter for the SAR ADC. However, it disrupts the D6 signal going to the LCD panel. The LCD library, provided by Creator 4.2, is very limited in terms of what port it can be configured to use, so I didn’t have much choice.
All my circuitry runs on a 5-V Vcc supply. I used an old-fashioned linear power supply design consisting of a 6.3 VAC transformer, full-wave bridge rectifier and a Microchip MCP1702T-5002 low-dropout regulator.
There was no practical way for me to draw out the full circuit contained on the motor controller. To make things work, all you need to know is the circuitry consisting of the IR2136S 3-Phase Bridge Driver and the 74HC14 hex inverter. To be honest, the 74HC14 pin numbers that I show on the diagram are just a guess on my part. I just hooked up the AH, AL, BH, BL, CH and CL signals from my circuit to the same-named pins on the Analog Devices ADMC326YR in the existing controller. Which pins of the 74HC14 went to any particular input on the IR2136S were moot in this case.
If you refer to Figure 1 in Part 1 of this series of articles—my reverse-engineered block diagram of the original controller (see Circuit Cellar 348, July 2019) you will see a *RESET line on the ADMC326YR. This is pin 20 on the device. Important note: It must be wired to the motor controller’s logic ground to put the ADCM326YR in a reset state, and tri-state the AH, AL, BH, BL, CH and CL lines so they can be controlled by the PSoC5LP MCU.
The essential part of the software consists of constantly adjusting the duty-cycles of the three PWM blocks to produce three synthesized sine waves, spaced 120 degrees apart in phase. The PWM operating frequency is 11 kHz, so these three duty-cycle values must be calculated/loaded in the PWMs at that rate. This is best done in an interrupt service routine (ISR), which, in this project, is generated by PWM_1 on its Terminal Count.
The best way to generate a variable frequency sine wave in software is to use the Direct Digital Synthesis (DDS) method. This consists of a 32- bit phase accumulator that has a phase offset value added to it at the designated sample rate (in this case 11,000 Hz). The phase offset value is proportional to the desired frequency, and is calculated as follows:
While the phase accumulator is 32 bits wide, only the eight MSBs are used to generate a pointer into a 256-byte long table. This table has been pre-loaded with values for one complete sine wave cycle, with a maximum amplitude of 1,080—a bit less than the PWM resolution of 1,090. Every time the PWM_1 ISR is executed, it updates the 3 bit phase accumulator with the phase offset value, extract the eight MSBs of the phase accumulator, and use that byte pointer to access the sine wave table. The 10-bit sine wave value that it gets sets the PWM’s duty cycle until the next ISR occurs.
Things are a bit more complicated than this. To generate three phases that are 120 degrees apart in phase, you need three pointers. The pointer mentioned in the last paragraph is directly used for PWM_1. For PWM_2, I add 85 to this pointer before looking up the sine wave value, to get a signal that is 120 degrees out of phase. For PWM_2, I add 170 to get the 240-degree phase shift. The 85 value is 1/3 of 256, and 170 is 2/3 of 256.
The other complication arises because the voltage sent to a motor must match the targeted speed. Simply put, if you have a motor rated at 1,800 RPM at 120 VAC, and you use a VFD to run it at 900 RPM, then you must reduce the motor voltage by a factor of 1,800/900 or 60 VAC. The rationale is that the motor windings exhibit inductive reactance. Inductive reactance decreases linearly with frequency. So, in the above example, the motor windings would have only half the inductive reactance, and would draw twice the rated current at 900 RPM if you didn’t reduce the voltage by half. The PWM_1 ISR looks at the target rpm and calculates what the voltage should be at this speed. A scaling of the sine wave value, obtained from the look-up table, is then performed to accomplish this.
In the world of VFDs, this voltage reduction with decreasing speed has a specific parameter associated with it: Volts/Hertz. My program contains a menu of several parameters that the user enters before actually running the motor. This is one of the parameters that you must set. Setting this parameter was a bit of trial and error, as the motor didn’t properly specify this. The nameplate specified a full speed of 15,000 RPM at 50/60 Hz. This value is definitely wrong, as a two-pole motor only runs at 3,600 RPM (less a bit for slip) at 60 Hz, and proportionately less at 50 Hz. A four-pole motor would run at half those rpm values.
It’s possible that the motor can run at 15,000 rpm as long as the VFD provides it with a 250 Hz sine wave (15,000 RPM / (60 sec./min.)). From the measurement I took, I know that the power supply for the half-H-bridges is 320 V. So, a good starting value would be 320V/250Hz or 1.28 V/Hz. I started with this value, and increased it until the motor started producing a noticeable “buzzing,” then backed it off accordingly.
To monitor the speed tachometer, I use an ISR triggered by Counter_1: isr_2. This will be invoked by either of two events:
1) The counter receives an input capture event triggered by a falling edge of the comparator output (Opamp_2).
2) The counter overflows its 16-bit capacity. This occurs only if the motor is stopped or stalled.
The ISR checks which of the above has occurred and sets two flags accordingly. In the main program, in event 1, it calculates the RPM as follows:
(using 50 kHz clock)
The remainder of the program consists of menu routines to implement user input of the following parameters: Acceleration, Motor Direction, Volts/Hertz and default motor speed. Acceleration is the ramp time in seconds that is applied going from Stop to the specified target speed. The PSoC5LP contains EEPROM, and I save these parameters to the EEPROM, and then read it at startup.
Five switches are employed for the user interface, along with the rotary encoder. Motor Start/Stop is handled by a SPDT toggle switch. The Menu push button puts you in the parameter adjustment mode. The Enter push button takes the value currently displayed on the LCD and stores it in the proper RAM variable. Repeatedly hitting Enter, without changing any values, advances through the menu, to adjust the three parameters mentioned above. The ESC button exits the menu, stores all three parameter values in EEPROM and returns to normal operation— that is, where you can run the motor.
From Figure 4 in Part 1, where I showed the complementary PWM outputs, it’s clear that it’s impossible to tell what exact waveform would be synthesized, as the duty cycles are constantly changing. You can’t display enough PWM cycles on the ‘scope to determine anything, except that things are changing quickly. I made up two RC networks, each containing a 1 µF capacitor and a 47 kΩ resistor in a low-pass configuration. If you connect these to the “normal” and complementary outputs of a given PWM, you will see two sine waves (180 degrees apart) on the ‘scope as shown in Figure 5. Similarly, if you connect them to any two “normal” PWM outputs, you will see either 120 degree or 240-degree phase shifts, depending upon which two you choose.
I should mention that the Creator 4.2 application, as initially installed, has some limitations in the way its compiler/linker handle the sprintf command. sprintf doesn’t, by default, handle the formatting of floating-point numbers, which are used in this project for both the LCD display and also the UART debugging port. Along with the article source code, available on Circuit Cellar’s article code & files download webpage, is a file called “Sprintf bug solution,” which explains how to correct this. This is not really a “bug” per se, but merely a choice on Cypress’ part to minimize code size by not including a comprehensive floating-point formatting routine in the standard build configuration.
Although I’m still bothered by the early demise of our “old” washer—the front-loading, high efficiency model—at least I managed to salvage from it a good motor and matching controller module. Figure 6 shows the motor. It was quite a job hacking off the grooved pulley, so I could replace it with a V-belt pulley (as fitted on the bandsaw, itself). The PCB layout of the original motor controller module is shown in Figure 7. Note the ribbon cable at the upper right, which connects the six PWM drive signals from my circuit to the ADMC326YR (which has been disabled by grounding its *RESET pin). Figure 8 is a photo of my controller board containing the CY8CKIT-059 prototyping module, along with the various front panel components.
For detailed article references and additional resources go to:
PUBLISHED IN CIRCUIT CELLAR MAGAZINE• SEPTEMBER 2019 #350 – Get a PDF of the issue