Down in the framework, beyond the powerful programmable controllers and flashy operator stations, in the belly of the beast, lives the true heartbeat of a machine. Servos with their precise actions and pneumatic devices breathing life into the smaller movements can’t hold a candle to the true soul of the beast. It is the venerable variable-frequency drive (VFD) that has kept automation alive all these years.
For those of us who remember the early years, deploying a frequency drive was no small endeavor. Why, even the very footprint, by today’s standards, was downright huge.
For example, a conversion project from a few years ago took a 10-hp, 240-V drive from the 1990s up to current standards. The original drive was so large—11 inches wide by 19 inches tall—that it was mounted on the outside of the enclosure.
The new drive—5 inches wide by 10 inches tall—is literally one half of the size. In the old terminology, that 10-hp drive was frame size B because anything under this would be a frame size A. In today’s terminology, that same 10-hp drive is a frame size D.
Even with one-half the physical size, there are three more frame sizes even smaller than the 10-hp drive. What is described here supports the well-known concept that bigger things come in ever smaller packages, but size is only part of the story.
An electric drive aims to control the speed and torque in a motor to achieve the desired application result. In induction motors, the voltage induced in the stator is directly proportional to the product of frequency and flux. The four primary motor-control methods are voltage/frequency (v/f), v/f with encoder, open loop and closed loop.
Voltage/frequency could be called a loose control of motor. It alters the voltage and frequency to keep the magnetic flux in the motor constant. To tighten up the speed control, an encoder can be added to provide feedback of the resultant motor behavior.
Open loop, sometimes called sensorless vector, further enhances the control by using a variety of techniques. Early drives would control a motor using a converter, feedback loops and sensors. To reduce the cost, sensors were eliminated, and newer methods were used to control the torque and speed of the motor.
There are multiple methods to provide constant flux to a motor. In one method called flux vector control, the magnitude and orientation, or vector, of the ac excitation is controlled. If the current vector is adjusted relative to the rotor flux vector, the flux vector magnitude and torque can be controlled independently. In sensorless vector control, voltage, frequency and vector are controlled independently to vary motor speed and torque as desired for the application.
Finally, closed loop takes the open-loop techniques and adds an encoder to finalize that control. With ever tighter control algorithms, a VFD combined with an encoder can be almost as accurate as a servo drive and motor, without the additional cost.
Variable-frequency drives still employ these techniques. Enhanced technology, in a smaller format, makes it easy to deploy drives in applications where a starter might have been used in the past due to cost and space considerations.
The greatest enhancement to VFDs, perhaps, was the introduction of the fieldbus. The ability to control a drive without myriad wires connecting the controller to each drive has promoted the easy deployment of drives in a control system.
With the relatively small size of the variable-frequency drive, it is not unreasonable to make this the primary method of motor control in your design. Just being wireless, except for the power and network connections, isn’t the real enhancement.
Wired solutions and early fieldbus still relied on digital type control. Start, stop, accelerate and decelerate were the basic commands. Started/running, stopped and faulted were among the status bits. Wired systems sent an analog signal for the speed or used preset speeds, selected by binary-coded digital bits.
With the implementation of a fieldbus, these same control and status bits were available, but as words in an exchange of data fields. Two words each for status and command at first but more possibilities as the technology got better. Second accel/decel values, more status like accelerating, decelerating, bus voltage and drive temperature were all available. If there is sufficient bandwidth and room in the data table of the controller, the possibilities are nearly endless.
Drives take the original data table exchange method and format that data into easy-to-use structured tags. To the user, instead of bits, bytes and words, the information is interpreted into informative tags with names such as CommandDir, OutputCurrent, FreqCommand, Start, Stop and Reverse.
While the ability to quickly add a drive to a programmable controller and assign a network address is wonderful, the additional memory and capabilities of the drive itself provide an even greater advantage to the designer. Here is where things get interesting.
Most drives come with pre-configured profiles. These profiles allow the user to choose a function that closely matches a desired function.
For example, a user can select one of conveyor, mixer, compressor, centrifugal pump, blower/fan, extruder or positioning, and the drive parameters will pre-set to best execute that function when commanded by the processor.
These profiles aren’t meant to be the end configuration but, rather, a recommendation of settings that will elicit an expected set of results. From that first setting, the drive can then be fine-tuned to best suit the desired application.
As an example, a conveyor needs quick acceleration followed by a ramp to the speed set point. A mixer, on the other hand, requires a slow ramp with a lot of torque to overcome the weight of the product and ribbon followed by speed and torque control to react to product that is flowing around the vessel as the ribbon turns. The speed and torque are always in variance and require more fine tuning to maintain the performance requirements.
With early drives, the user had to use a somewhat cumbersome human interface module (HIM) to access and change parameters in a drive. This module could be directly connected to the drive or come as a plug-in device.
The buttons on the module were used to cycle through a rather large set of parameters to set functions. Early drives only had numbered parameters, and the user would have to use a list of parameters to figure out what number to access and change.
As drives evolved, the HIM acted more as an interpreter of the parameters and enhanced the user experience by adding text to the parameter number to identify what the parameter was and, in some cases, prompt for potential settings to apply to the parameter.
With the advent of the fieldbus connection to a VFD, application software was developed to give the designer a window into the function of the drive. This software provided an electronic means of setting and monitoring parameters in a drive. Residing on a laptop, the software was opened and then a connection to the drive was initiated using an interface cable between the laptop and the drive. If the drive is networked, there are usually two separate connections, one for the programming port and one for the network port.
Most manufacturers have now taken another step toward easy integration by including the drive-configuration software in the processor-application software. The great part about this advance is the designer only needs one software to connect to the drive for both configuration and operation. The initial interaction usually involved manually setting up the network address, using the HIM and then all other functions and parameter settings can be accomplished via the drive configuration portal in the programming software.
Another feature added more recently is a daughter add-on module that allows the user to use switches on the module to configure the network address physically. Once the drive is connected to the network, via this hardware module, the drive can be accessed via the controller or programming software without having to take that initial step of using the HIM to establish the network address.
One final feature of particular interest is a function called automatic device configuration (ADC). This can be used in a couple of different ways. Some designers use it to save the drive parameters in the application for the programmable controller. After doing so, a non-functional drive can be removed from the network, and, when the replaced drive is connected to the network, after the network address is set, the controller will identify that a new device is plugged into the same node address as the old device and automatically download the saved parameters to the new drive on first appearance.
The second way to use the ADC function is to do all of the drive parameter setup during the development of the initial software application, offline, and then use the download function available once the new program is downloaded to the processor to send the parameters to each drive in the application using that same ADC download feature. This also comes in handy if the designer is making multiple machines.
Once the initial application is installed and tested, the remaining machines can be quickly configured for operation by downloading the processor application and using the software portal to the drives to manually trigger a download to each drive with the parameters stored in the process application.
It is very apparent that hardware manufacturers have taken great lengths to make it easier to use their products in our applications. Variable-frequency drives continue to drive automation.
