Drives: Control, Safety, and Data Management
| By: Kristin Lewotsky, Contributing Editor
Back in the day, the role of the drive was simply to power the motor. Today, they can do far more than just provide input to make a motor turn. With increasing amounts of onboard processing power and memory, modern drives can perform the tasks of motion controllers, safety PLCs, and even data logger/edge-computing devices. As automation becomes more pervasive and complex, these intelligent drives give OEMs and end-users the flexibility to develop the most effective, most economical solution for the application at hand.
One of the advances enabled by the development of smart drives is distributed motion control. In centralized control, the central device (motion controller, PC, or PLC) coordinates path planning for all axes, while the drives just amplify those commands. In distributed control, the drives handle the path planning, as well. Distributed motion typically uses a master-follower architecture in which a designated master drive/axis provides setpoints to the other follower axes (see Figure 1). One master drive can control multiple follower drives or they can be daisy chained together, with the same drive acting as both master to one drive and follower to another.
Figure 1: In centralized motion control (left), a centralized device performs path planning for the entire system. In decentralized, or distributed motion control (right), intelligent drives perform path planning for a single axis or for multiple axes connected in a daisy-chain configuration. (Courtesy of Kes47)
Distributed or drive-based motion control eliminates the need for a centralized motion controller, reducing cost and footprint. “Distributed logic advantages include helping increase throughput and actuation speeds,” says Simon Keng Soon Wong, product manager, motion control business at Rockwell Automation (Singapore).
There are always trade-offs in engineering and distributed control is no exception. Smart drives are not as effective at managing highly coordinated motion. They typically need to be programmed in higher-level languages, which could be a stretch for engineers used to working with more common PLC alternatives like structured text, function block, or ladder logic. Vendors have made strides in the past few years toward more accessible engineering tools with graphical interfaces. OEMs can take advantage of some drag-and-drop capabilities and then write their own higher-level, application-specific blocks.
A decade or so ago, there was quite a bit of excitement around the benefits of the approach. Today, opinions differ. “Distributed architectures have continued to evolve, as network bandwidth has increased, as local processing power has increased, as the configuration software has gotten better, more user centric,” says Andrew Jaap, business manager, motion control business at Rockwell Automation (Milwaukee, Wisconsin). Whether or not distributed motion control is a good fit depends on the needs of the application, the scale of the project, and even the skills of the team.
"You run into limitations,” says Craig Nelson, senior product marketing manager in the general motion control group of Siemens Digital Industries (Alpharetta, Georgia). “Is it as user-friendly as programming in some highly developed controller environment? Typically not. That’s why two to three axes is the general rule of thumb for decentralized control. If you need to control more than three axes, then typically that motion control is going to be handled by a higher-level controller."
Nelson points to both ease-of-use and greater functionality as the reason more design teams typically turn toward centralized motion control. "People are adding so much more automation and so many axes of motion control to their machines that the engineering time is an important consideration,” says Nelson. “I would say the majority of the motion control market uses a higher-level controller.”
That is not to dismiss distributed motion control, however, he cautions. “There are still a number of applications and a number of solution providers out there that prefer to do coordinated motion control in the drive,” says Nelson. “So, yes, there are markets out there for both, but I think the largest growth we see is in central control motion.”
There are some sweet spots for distributed motion control. For equipment with very simple motion requirements, a high-level controller can be overkill. Engine hoists in automotive production lines, for example, don’t even have central controllers. They just use drives and distributed control for the simple motion. Drives can also provide faster response in certain types of applications. The arm of a storage and retrieval robot might oscillate when holding a load at extension. Drives can detect and damp these oscillations with vibration compensation techniques. Although PLCs or motion controllers can offer the same capabilities, the latency introduced by communications between drive and controller can slow response. This problem shows up in a number of other applications, from the overhead cranes used on factory floors and in metal foundries, to dockside loaders, where offshore wind can cause shipping containers to sway.
Drive-based control provides a way to add motion to a platform when access to the controller code is restricted. The OEM may want to protect proprietary code from third parties, for example. Perhaps the asset owner is retrofitting or expanding an older machine and the controller code can't be accessed. In these types of situations, the additional motion can be implemented using distributed control of axes with smart drives. The PLC or motion controller would continue controlling the existing parts of the machine and communicate with the new axes over the machine network. The approach also applies for cases in which a machine needs a function added that the existing motion platform can’t support.
With these types of deployments, the line between centralized and decentralized is no longer sharply defined. “It basically blends those two paradigms, centralized and decentralized, to the point that it becomes much more difficult to look at one versus the other, and just say, ‘Hey, if you're doing three axes you do this, and if you're doing more than three axes, you do this’ because that's not entirely true any longer,” says Jaap. “The technology has been evolving.”
Although there is still a place for hardwired safety in simple systems, functional safety is becoming increasingly popular in automation. The benefits go beyond the core mandate of maintaining a safe environment for personnel to protecting equipment, streamlining operations, and enhancing throughput. In functional safety, a safety controller analyzes motion feedback and the drive modifies the operation of the motor using built-in functions that are configured to achieve a defined safe state. Initially, drives invoked safe torque off (STO), which removed torque-generating current from the motor while leaving the drive energized, speeding restart. Today, drives are available with more than 20 safety functions, such as safely limited speed, safely limited position, and safe direction (see sidebar).
Safety drives have become more sophisticated in other ways. Just as for motion control, safety control can be centralized using a safety PLC or decentralized, with the drives executing the safety logic. In the case of safely limited speed, for example, a drive would use encoder feedback to monitor the velocity of the axes. If defined conditions are violated¾an operator breaks a light curtain, for example¾the drive would use its function to execute a predetermined response, such as slowing down or stopping.
The choice of architecture depends on the assets involved. For a small machine, safety-enabled drives could handle the safety logic as well as the functions (see Figure 2). A more complex machine with a higher axis count might use a centralized architecture with a small safety PLC to control the drives. For a larger layout combining machines and robotics, the solution would probably require distributed IO and distributed safety devices among multiple safe fieldbuses. In the case of a fully networked factory floor, a master safety device could be used to run an entire production line of 15 or 20 machines.
Figure 2: Safety architectures range from drive-based (left) to safety-enabled drives run by a safety PLC (center) to large numbers of assets connected via safe Ethernet to a master safety controller (right). (Courtesy of Bosch Rexroth)
Today’s machines not only have more motion axes, they are also increasingly integrated with linear robotics, collaborative robotics, and other intelligent conveyance technologies. Particularly as pressure to decrease footprint increases, functional safety needs to essentially operate in a 3D space. "When you have multiple types of devices operating in the same space, they all need to be somewhat safety aware and have some ability to understand where they are relative to other devices,” says Jaap. “And that's where we start to talk about Cartesian-based safety instructions.” Using this approach, an axis or subsystem operating under safe limited speed, for example, would be able to locate itself in 3D space and determine whether there was a risk of colliding with another element moving through the same space.
Flexibility, Scalability, Productivity
Functional safety is particularly useful given the interest today in reconfigurable factories. Instead of changing hardware and wiring when the setup changes, users can redefine safety functions in software. And with today’s safety offerings, updates often can be made through the graphical user interface rather than by rewriting code.
“If your system changes, with a couple of clicks, a couple of check boxes, you can reconfigure what your safety functions do,” says Tim Loria, principal engineer at Bosch Rexroth (Hoffman Estates, Illinois). “Suppose you started out with safely limited speed but now, based on changes to your operation, you need safe direction. You just click another box in the configuration window and activate the function.”
Functional safety is also attractive because it can streamline the engineering process. OEMs serve a global marketplace with varying performance expectations, regulatory environments, and cost limitations. End-users and even machine builders need different things at different points in their life cycles. Having an architecture that can address the needs of a simple a five-axis machine or one with 150 axes using similar tools, a similar simulation environment, and a similar emulation environment can be a game changer. “That flexibility, that scalability can really help more customers deploy motion,” says Jaap. “At the end of the day, you still have to make things move but it’s all these other capabilities that simplify the design, reduce engineering hours, and document the process by which you got there.”
Despite the many advantages and broad availability of safety-enabled drives, adoption still lags¾although it is improving. “We’re starting to see more and more people recognizing the efficiency gains they can get from functional safety, but it’s been a relatively slow process,” says Daniel Zachacki, senior product marketing engineer for servo/motion at Mitsubishi Electric Automation (Vernon Hills, Illinois). “Most engineers just know they need safe torque off. It’s less common to run across someone saying, ‘Hey, this needs safely limited speed.’” In his estimation, the exercise of risk assessment and determining safety levels tends to steer designers toward safe torque off, when they could get greater functionality from using a different strategy. “There’s a general lack of understanding about how to use other safety subfunctions or combinations of safety subfunctions to maintain that same level of safety but also increase the productivity of your plant or your machine,” he says. “When people start to realize that, we’ll start to see more sophistication in how safety subfunctions are used. At the moment, you see it quite a bit in the automotive world, but you’re not seeing it necessarily in packaging, for example.”
Loria attributes this to misconceptions around deploying more sophisticated functional safety. “They think it's going to cost more, it’s going to hinder their machine, it’s going to take more time, but that’s not the case,” he says. “People are starting to realize that it can actually be a very easy, low-cost upgrade from a drive without safety to a drive with all the numerous benefits. It provides a very quick return on investment.”
The modern factory floor is festooned with sensors and devices to help turn readings into actionable information. Data historians or data loggers can capture vast amounts of input at high speeds. From there, it can be sent to the cloud to be used with analytics.
On the downside, data historian/data loggers add cost and complexity to the system. The processing power and storage found in intelligent drives enables them to handle aggregating and processing data, and potentially even more sophisticated tasks like machine learning and other types of AI.
Drives have access to significant amounts of data that can be mined for insights into system operation and asset condition. Drive current, for example, is proportional to motor torque. Unexpected increases in torque demand can be caused by issues such as bearing defects, lubrication breakdown, improperly tensioned belts, etc. Some drives collect this information using sensors; others use virtual current monitoring.
Because drives are connected to the machine network, they are able to capture data from other sources and sensors, providing a context around functional data and a history that can be mined for predictive maintenance. The data can be sent to the cloud to yield actionable intelligence. “You have a web-based dashboard where customers can push all the data from the drives up, evaluate them, download back to the drive, and act upon it,” says Rafael Larcher, product marketing manager for general-purpose drives at Siemens.
The data can also be leveraged for process control and even quality assurance. In the automotive industry, for example, smart drives are being used in test stands for evaluating the motors used in electric vehicles. "We have an application for our system drive where we can take data at an 8 kHz signal out of the drive to an edge device,” says Nelson.
Although cloud-based analysis is a powerful tool, data transfer requires bandwidth and there’s a cost to data ingress and egress. The round-trip transit from drive to cloud also introduces latency. For torque monitoring, that’s not an issue but for some applications, every millisecond counts. In high-speed web processing, for example, if there is a motion issue that could cause a web break, the system needs to respond immediately. As a result, edge computing¾using local devices to perform preprocessing or even full analytics¾is becoming increasingly popular. It reduces data volume, eliminates transit time, and delivers faster results.
Although most edge processing takes place on dedicated devices, that does not have to be the case. “Smart drives are likely to become edge devices and hubs as they incorporate additional data surrounding the axis,” says Jaap. “Most smart drives are capturing significant amounts of axis performance data. The overall trend for drives is to deliver more data at even higher capture rates as operating speeds, reliability, and operational productivity increase. So, once you capture the data, do you really want to send that all to the cloud? the answer is probably not.”
“With the evolution of servo drives to ’smart drives,’ they are in an excellent position to assist edge devices,” says Zachacki. He points to drives running predictive maintenance algorithms. The drives monitor internal and external feedback and when limits are exceeded, notify the machine operators. “You can recreate your predictive maintenance routines using edge computing. It's not impossible, just difficult,” he says. “But then you have to capture all those data points. You have to build the model and you have to save that data somewhere for reference. If that all happens locally in the drive, you just saved yourself, not just a ton of programming work, but also having to store that amount of data.”
In an era of increasingly complex automation in a global marketplace, smart drives provide greater flexibility in controls and safety architectures while helping increase productivity through functional safety and data capture and analysis. By doing the duty of other system components, drives also help reduce cost and footprint. In particular, the cost of implementing safety through drives may be much lower than users anticipate and offer quick return on investment. Finally, it’s important to observe that the capabilities discussed above aren’t exotic. In fact, a look at the drive’s manual may reveal that safety, control, and processing capabilities are built in. The key is to work closely with vendors to uncover hidden functions and discover the options available for best achieving performance, throughput, and cost objectives.
Know the Code
Today’s safety-enabled drives are available with more than two dozen safety functions. A few of the more common ones are:
- Safe Torque Off (STO): Removes power to the motor but leaves the drive energized for fast restart
- Safe Stop 1 (SS1): Active braking for equipment with high kinetic energy; prepares for STO
- Safe Operating Stop (SOS): Drive holds motor at zero speed without removing torque
- Safe Stop 2 (SS2): Controlled braking ramp for equipment with high kinetic energy; prepares for SOS
- Safe Brake Control (SBC): Controls an external holding brake; typically for motors holding loads on vertical axes
- Safely Limited Speed (SLS): Sets a maximum speed
- Safe Direction (SDI): Restricts direction of motion
- Safely Limited Increment (SLI): Limits motion increments to support jog operations
- Safely Limited Torque (SLT): Prevents motor from exceeding specified torque
- Safely Limited Position (SLP): Establishes an operating envelope