Minimizing Machine Safety Risk with Servo Drives

April 24, 2012
Motor runaway conditions not only increase expenses, but can also create dangerous situations. The incorporation of a Velocity Limited Torque Mode function on a servo system can mitigate runaway motor issues by allowing both the maximum velocity and maximum torque values to be specified and varied during the process.

The bottom line in an automated system is that the reduced risk of motor faults translates into higher machine efficiency and productivity.  Wherever people work directly in operating areas of machines or systems, personal protection is of utmost importance.  That’s why safety engineering has become standard in servo systems to optimize productivity and protect valuable products and machinery.

For any machine process powered by a servo motor it is important to estimate and evaluate risks early in the planning or development of a machine.  The keys to constructing a safe machine or process are to detect potential hazards upfront, estimate and evaluate the risks, and eliminate or reduce risk to an acceptable minimum.  Risk can be minimized through careful analysis of the machine process in all phases of its service life—from installation and commissioning, through the production period with operation and maintenance, right up to disposal.
 
The integration of safety functions in the drive is referred to as drive-based safety.  The primary purpose of all safety functions is to safely limit the motion of the drive on command or in the event of an error.  The stop functions are therefore among the most important.  Depending on the situation, when the drive is shut down for safety reasons, it is done in the “safe torque off” function, whereby the energy supply to the motor is safely interrupted.  Building on this concept, some servo systems incorporate higher-order safety functions.  For example, the Lenze 9400 Servo Drives include extensive standard safety controls, such as safe torque off, safe stop 1, safe stop 2 and safe speed.
 
Integrating the safety functions into the drive controller offers many advantages over conventional solutions.  Drive-based safety gives greater clarity to the form in which the safety technology is implemented, and it simplifies the system structure.  From a functional standpoint, the faster shutdown on command — or in the event of an error — means an increase in safety, since no points of separation with contacts are required.  Because the safety technology provides status information available in the servo inverter and, therefore, in the PLC, there is also an improvement in the diagnostic capabilities.
 
Velocity Limited Torque Mode
Standard servo drive-based safety functions may not always be adequate to address every fault that can lead to motor runaway, however, especially in continuous automation applications.  Motor runaway not only drives up expenses but can quickly create a potentially destructive and dangerous situation.  Depending on the machine operation and specific risks of motor runaway, an application may benefit from the incorporation of a Velocity Limited Torque Mode function, where both the maximum velocity and maximum torque values can be specified and varied during the process.
 
In a synchronous servo motor the torque is linearly proportional to the current supplied to the motor.  The torque constant Kt describes the torque generated for a specific motor current (Kt=T/I).  Often servo systems performing torque control for web handling or nut runners may not directly monitor the motor velocity, except as a rigid definition of motor mechanical overspeed.  In this situation, the constancy of the torque controls the speed at which the machine will operate and the servo system may not fault prior to actual motor runaway.
 
Torque control without a specified maximum velocity can send a servo motor into runaway in the case of either a loss or a sufficient decrease of load.  Velocity Limited Torque Mode is most applicable to machine processes requiring greater definition and when a speed fault could result in user injury, damaged products, or damaged machinery. 
 
The Velocity Limited Torque Mode concept has been successfully proven in scores of servo drive applications that require greater torque control definition.  
 
Sample Program
To illustrate the concept behind the Velocity Limited Torque Mode function on Lenze’s PositionServo drive product, Lenze uses a sample program that exemplifies how speed limits can be applied for faults that may lead to motor runaway. Follow this link to access detailed information about the program.
 
For the purposes of simplicity and replication, the program uses Analog Input 1 (AIN1) for the velocity reference to the drive.  Analog Input 2 (AIN2) is used for the torque reference to the drive.  This allows the user to alter both the torque and velocity references and observe the effects on the motor.  In this application, all logic to set these points is conducted within the drive’s indexer program.  However, an external device networked to the drive over any of its offered communications interfaces could alternatively set these variables.
 
The Velocity Limited Torque Mode program uses the Enable Input IN_A3 as a safety enable for safety devices on the system.  Input A4 is defined as the Run/Stop input to cause the motor drive to start or stop.  The velocity reference AIN1 is accessed through drive variable AIN1 (+/- 10VDC).  Scaling, dead-band, and offset (as set in MotionView or through associated variables) are not applied to the AIN1 variable; this functionality has to be created within the user program.
 
The PositionServo is placed in velocity mode with internal reference through the relevant variables at the start of the program.  The drive must be in velocity mode for the program to be able to apply speed limits.  The program uses IREF (internal reference) as its velocity reference when in internal velocity mode.  Therefore, AIN1 is transferred to IREF within the main program loop.  Since AIN1 is represented in volts and IREF in RPS (revolutions per second), AIN1 must be scaled before it can be applied to IREF.
 
This program uses the analog scaling entered in the MotionView Parameter as this allows the customer to make parametric changes to the scaling from within MotionView without having to alter the user program.  The program applies any offset to AIN1 as entered into the MotionView parameter in the same way as for scaling.  Lastly, the program applies a dead-band in RPS before the calculated velocity is transferred to the IREF variable and output to the motor.
 
To control the torque, the program writes to the drive nominal current limit parameter, and also to the two peak value current limit parameters (for 8kHz and 16kHz output frequency).  The peak current limits must be set equal to the nominal current limit to prevent the drive from trying to use its peak currents and creating step changes in the torque control.  Torque control reference is input on Analog Input 2.  AIN2 values are represented in volts, which must be scaled before it can be applied to the current limit parameters.
 
This program uses the analog scaling entered in the MotionView Parameter for the same reasons as Analog Input 1.  The drive will continually execute this code loop until the drive run input is switched off.  An event is used to detect the run/stop input transitioning from run to stop once the drive is in a run condition.  For the purpose of this example, no subroutines are used.
 
Motor Mechanics: For the purpose of the demonstration a motor should be used with a disc fitted to the motor shaft so that the user can visually see the Velocity / Torque output executed by the PositionServo.
 
Fault Handling: In the event of a fault, the code will be restarted.  The operator must switch the drive run/stop input off and on again for the main program loop to restart.
 
I/O: IN_A3: Safety Enable/stop - Connected to machine safety Guards/Devices; IN_A4: System Run/Stop Input; AIN1: Drive Velocity Reference; AIN2: Drive Torque Reference
 
Connection: See image Connection Diagram image linked to this article, which shows how the P3 terminals need to be connected to successfully replicate this sample program.
 
White Paper author: Joel Kahn, Product Manager—PositionServo, Lenze

Companies in this Article

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...