Advances in device-level communications along with dedicated software let intelligent motor-control architectures provide useful information to maximize machine uptime.
By David Blair
Edited by Miles Budimir
No question that microcontrollers are built into even more equipment. Motor-control centers (MCC) are no exception. Advances in intelligent power devices have given rise to a new breed of MCC often called the Intelligent Motor Control Center (IMCC).
Improvements in electronics have had an impact on purchasing criteria. Many MCC users now look closely at solid-state overload relays and networking options and less at more traditional factors such as the design of power bus-bar connections.
An IMCC is relatively easy to install and maintain without specific training. Setup is basically plug and play. Once in place, the IMCC monitors real-time data, notes trends, tracks component history, and even organizes wiring diagrams, user manuals, and spare parts information. Though it costs more than an MCC, the IMCC more than pays for itself through predictive maintenance, better manufacturing efficiency, and similar factors.
The three major parts of an IMCC include motor-control components, an open device-level network, and software.
The main piece of hardware in the MCC is the motor starter. Over the past few years, several solid-state technologies have been built into the motor starter to make it more intelligent.
The general trend is more features at a lower price. Consequently, overload-protection relays have become more economical. Built-in microprocessors and networking now let these devices be applied to all loads throughout the plant, not just critical ones. Their electronics provides features such as communication, programmable alarm and trip values, and ground-fault sensing.
Early versions basically protected against overloads. Traditionally, these devices only signaled on or off; they sensed the current in the motor and tripped when the phase current got too high. There was no ability to read ground fault current, current imbalance, or whether the motor was close to tripping. Later models added an adjustable trip setting and had quicker phase-loss protection and features such as jam, stall, ground fault, and phase imbalance. More recently, overload relays have been given an ability to communicate. This lets users monitor current, see how much thermal capacity is utilized, and identify the reason for a trip.
These overload relays may even include built-in input points. Frequently, input points are needed to monitor the status of the disconnect switch, contactor, or hand-off-auto switch. In the past, input points had to either be wired to an input/output (I/O) chassis or to a small I/O module in each unit. Adding I/O to the overload relay (and to communication modules associated with ac drives and solid-state controllers) eliminates hard-wiring to the I/O chassis, allowing all control and monitoring to go over the network.
Historically, MCCs have used hardwire connections for control and monitoring of on/off status, and sometimes for transducers that monitor feedback. But hardwiring is giving way to communication networks. Device-level networks such as DeviceNet have become standard fare in IMCCs. The reasons include access to more information, less wiring and documentation, and ease of adding or moving units.
Various cabling strategies have been used, the most common being a trunk line in the horizontal wireway and daisy-chain drop lines in the vertical wireways. The cable has generally been round, rated 4 A, 300 V, NEC/CEC Class 2. Connectors between the trunk line and drop lines have either been terminal block or quick-connect style. This approach worked well for the first device-level networks. But as networks in MCCs become mainstream, there is pressure for cabling components that cost less.
Recommended practice is to place trunk and drop cables behind barriers, rather than letting them be exposed in the MCC wireways. This minimizes the danger of their accidental damage when large power cables are pulled through the wireways.
There are also improvements available in the daisy-chain architecture. Its shortcomings are twofold. First, equipment will shut down if the chain is accidentally broken. Second, adding a device requires shutting down an adjacent unit. One solution is to provide network ports at the rear of each vertical wireway. This approach keeps the trunk and drop lines safely behind barriers, while simplifying installation, relocation, and the process of adding MCC units.
Several new cables now make it practical to simplify network designs and lower costs. Communication cables rated 8A are now available. When combined with an 8A power supply, they eliminate the nuisance and cost of multiple power supplies. Flat cables also are available. They can use insulation displacement connectors (connectors that clamp onto the cable, piercing through the insulation jacket) to minimize breaks and splices in the trunk and drop lines. Flat cable also slashes manufacturing time because installers can use a wire stripper to bare conductors in a single motion. Finally, cables with Class 1 insulation ratings are now available, eliminating the requirement for separation from power cables.
Operator interface software now makes it possible to monitor data and establish predictive maintenance practices. The reality, however, is that designers seldom have time to create customized screens for this purpose. So predictive information is still an untapped resource in most facilities.
Helping to solve the problem is monitoring software with preconfigured screens. It works with the IMCC and lets operators see information without creating any customized views. The software polls intelligent devices, recognizes their type (e.g., ac drive, solid-state motor controller, etc.), and displays the most critical real-time parameters on a preconfigured screen. The polling algorithm segregates monitoring and control, ensuring that monitoring scans do not affect control scans. Supplementing this information is a database containing job-specific items such as AutoCAD documentation, spare parts lists, and nameplate data.
Operators in the control room see a screen that mimics the elevation view of the IMCC, complete with nameplates and indicator lights to show status, including on/off, warning, tripped, and communication failure. In the event of a problem, they can readily see from the screen which component is alarming and causing the problem. The problem can then be corrected before it brings unscheduled downtime.
Alternatively, the system can present monitored data in a spreadsheet, making possible filtering and sorting as well as a more compact representation. To probe further, users could quickly see key data pertaining to a specific MCC unit. Typical parameters include current levels, time-to-trip, trip cause, ground fault current, and I/O status. In this instance, it's easy to provide an overload of data. For example, today's ac drives can have more than 300 parameters, but only a dozen are typically viewed during operation.
Preconfigured screens show the parameters typically of greatest interest but also let operators redefine them if need be. Critical parameters can also be displayed via trending graphs and large analog-type dials for greater emphasis.
In the event of a trip, the software serves as a comprehensive information system, providing more than just real-time data to minimize downtime. For example, to help quickly identify which replacement parts to order, the software lists the electrical components in each unit.
Another source of excessive downtime and frustration is lost documentation. This is not a problem when the software contains electronic versions of wiring diagrams, user manuals, and AutoCAD drawings.
With the trend toward locating MCCs in low-traffic areas, the software must allow remote viewing, ideally in a control room or at an engineer's desk, or on a laptop plugged into the IMCC. This means the software must make views available over facility-wide networks such as Ethernet, as well as on the supervisory control network and at the device-level network.
The information available to the IMCC software and to a predictive-maintenance program depends on the raw data coming from intelligent devices in the MCC and associated system. The supervisory and connected-device networks need a design that permits timely receipt of alarms produced by end devices. It must also allow for the interrogation of Electronic Data Sheets.
Beyond graphically showing the health of the network, the screen permits navigation and selection of any connected device object. The selected object's EDS can then display the current operating parameters.
The benefits of predictive maintenance are twofold. First, the device can be left in place beyond the calculated statistical replacement scheduled under a preventive maintenance program. Second, because devices are replaced less frequently, the failure experience due to infant mortality and misconnection is reduced.