Most industrial facilities include electric motors that require overload relays for protection, control and monitoring purposes. The latest overload relays are often called motor management relays (MMRs) because of their high-end motor protection capabilities and unique operation modes. The latter includes support for direct motor applications, as well as for reversing, two-speed, start delta and other motor applications. This article will cover expansion I/O capabilities, logic and the applications in which MMRs are used.
The logic and expansion I/O allow for offloading some logic from a system controller and offer the ability to take immediate action at the MMR level of a control system. This logic adds nearly infinite features and capabilities to an MMR above and beyond the embedded firmware.
There are many applications and additional capabilities that include the elimination of the main system controller altogether. The obvious benefit to this is cost savings and increased system reliability.
Capabilities Beyond Embedded Firmware of an MMR
Nearly any application or feature not included in the embedded firmware of an MMR can be implemented using the logic engine embedded in many MMRs. When using the logic capability, additional digital, analog and temperature inputs and outputs may also be required. These features make an MMR a very powerful asset to any control system.
Offloading Control Functions from the Main System Controller
There are many applications where certain tasks can be better handled local to the motor by the logic engine in an MMR. Some examples follow, but these are a subset of potential applications for this technology.
1. Temperature Applications
The expansion I/O capabilities for MMRs often include temperature inputs, such as thermocouple and RTD inputs.
Critical motors frequently include RTD or thermocouple sensors on the motor windings and/or bearings. Sending this information back to a system controller typically requires distributed I/O connected to a network for the controller to monitor, then take action by indicating an overtemperature fault for the motor, and possibly stopping the motor via the overload relay.
This requires a network for the controller to communicate to the distributed I/O and to the relay.
Offloading this functionality to a logic engine in the same device that is already controlling and protecting the motor can save time and money. It can also reduce the size of the system controller by reducing the amount of logic in that controller, in addition to the amount of I/O it needs to monitor and control each motor.
The logic engine of an MMR can monitor temperatures from the motor windings or bearings, and if a temperature goes beyond a specific rating, trip the motor and generate an overtemperature fault. This fault can be transmitted back to the system controller and displayed on an HMI and appear locally on the MMR’s user interface.
2. Special Local Control
Any local control scheme not implemented in a MMR’s firmware can be accomplished with the logic engine, which often requires some additional digital inputs. This could include things like an hand/off/auto (HOA) switch; special interlocks such as pressure, temperature, limit, photo and proximity switches; and switches from a light curtain or pull cord to stop the motor or prevent it from running.
The logic can also be used for special timing control functions, so as to enable multiple fault reset input options and any other control and monitoring function necessary for an application beyond the scope of the firmware in an MMR. The logic can also generate user-defined faults to trip the motor and provide fault codes specific to any application fault not included in the suite of motor faults included with the MMR. There is no limit to the control capabilities of an MMR when using the embedded logic and expansion I/O capabilities.
3. Analog Outputs
Some applications require one or more analog outputs to transmit 4-20 mA signals, for example, to a PLC for motor parameters such as motor current, power (watts), HP, voltage and more. The logic program can handle all the necessary scaling and send this kind of data to an analog output.
4. Time-of-Day Control
Many MMRs provide a real-time clock (RTC) option for time stamping faults. This information can also be used for time-of-day and day-of-week control. For applications requiring that some motors start and stop at specified times on specific days, the logic engine can be used as the control source for this purpose. Interlocks would be required to ensure this type of automated control operates in a safe manner.
5. Remote Pump Stations
Remote pump station in the water and wastewater industry generally consist of—at a minimum—an overload relay to protect the pump motor and a small PLC to control and monitor the system. The PLC also communicates to a system controller via a SCADA network.
With the logic and expansion I/O capabilities in MMRs, the PLC can be eliminated and the MMR can be used for both purposes in many cases. With the communication networks supported by MMRs, they can also communicate on the SCADA network back to the main system controller. This can provide a substantial cost savings at each remote pump station.
6. Other Applications
There are many other applications for the logic engine and expansion I/O, such as enabling the MMR to use more control sources than its firmware allows, or even to enable a motor jogging feature. The important thing to remember is that when any special or unusual functionality is needed beyond the scope of the MMR’s firmware, it can most likely be implemented in the MMRs logic engine. Be sure to investigate the capabilities of each MMR’s logic engine to be sure it has the following features:
- Access to all internal motor control and monitoring parameters
- Access to the expansion I/O and any I/O on the MMR
- The ability to create internal variables of different data types (integer, Real, BOOL, double integers, bytes)
- A large number of function blocks or special instructions such as timers, counters, math, data comparison, analog scaling, data conversion and even PID, if needed.
- The ability to transfer data between the logic engine and the system controller.
These features allow for maximum capability, making the logic engine in an MMR equivalent to a small PLC.
Using MMRs as the Controller
Providing additional capabilities to MMRs could allow for a complete distributed control system without a main controller. An important requirement for this capability would be for the MMRs to support an Ethernet network where they can initiate messages to each other and back to a central HMI where the entire distributed control system could be monitored.
In this case, an expensive main controller would not be needed. This also eliminates the possibility of losing the entire system should the main controller fail, making the entire control system more reliable without the use of an even more expensive redundant main controller system.
Integrating a system of devises with shorter control programs also increases the reliability of the system by eliminating a huge single, often-unwieldly control program in a main controller. These programs tend to be difficult to write and, when a problem occurs, to troubleshoot. With many small, easy-to-understand programs distributed throughout a control system, it is far easier to isolate and fix an issue when one occurs. This results in a more reliable overall control system.
Another aspect to a distributed control system is to include this logic capability in other motor control and protection products in the system. If all motor control and protection products such as VF drives and soft starters also support a logic engine with expansion I/O and with the ability to initiate communications, the distributed control scheme would be complete. All other control devices in the system could be incorporated into this system by connecting them to the analog and digital I/O on the various motor control and protection products, or else to the communication network all the devices are connected to, completing the distributed control system.
Conclusion
There are many possibilities when it comes to distributed control. Distributed logic is more reliable and easier to troubleshoot, which can lead to less downtime. It also ensures less downtime due to hardware considerations because of the cost of losing of a single small portion of a system (MMR) versus losing the entire control system (main controller).
Another consideration is system cost. Eliminating a main system controller and all the software associated with it can be an enormous savings—particularly when the system logic is incorporated into devices already in the system. These are the motor control and protection products such as MMRs, drives and soft starters.
Distributed control can be implemented in conjunction with a main controller to offload critical logic or it can be used as the system controller. The latter could be the system of the future, especially if cloud technology and IIoT is taken into consideration as the overall system monitoring tool. But an HMI in a control room or on the MCC or panel door can also be used for this purpose.
Jim Rosner is a lead industrial application engineer in the Controls and Power Conversion Division at Eaton. He has worked as an application engineer in industrial controls and factory automation for more than 41 years. Rosner’s focus has been on PLC applications, industrial networks and motor control and protection.