Technical Application Notes Power Programming – A Rockwell Automation Solution that Helps Machine Builders Meet Industry Standards and Guidelines Purpose of this Document: This application note introduces Power Programming and provides a basis for using it to develop an application program. This document assumes an audience of mid- to high-level programmers who are familiar with RSLogix™ software and Motion programming. Control Challenges: Many standards, guidelines, and best practices exist in the Factory Automation world. For the machine builder responsible for supplying a machine that meets all the appropriate standards/guidelines and works seamlessly within a larger system, this can be extremely taxing. Rockwell Automation understands how difficult it is for both machine builders and end users to get their arms around all of these needs and make them work together. Taking full advantage of Rockwell Automation’s extensive resources and breadth of offering, Power Programming embodies the expertise that machine builders are finding increasingly expensive to maintain within their business. Control Solution: There are several ways to program an application/machine and a great store of knowledge available that can be tapped and incorporated into your method of programming to increase efficiency and reduce costs. This application note provides a consistent, standardized approach to programming that will allow you to save a significant amount time, and as a result, money. This Application Note: Creates a template for rapid program development. Introduces state model programming. Provides sample programs for reusable code development. Outlines technical considerations for specific applications. With Power Programming, you don’t need to write programs from scratch. Rockwell Automation provides starter modules, or samples of modular structured code, which incorporates current standards and guidelines, that you can use and emulate and machine control templates that you can use as the basis of your program. These starter modules incorporate state models, which provide the guidelines for consistent terminology throughout your program. You also have the ability to add PackML state logic to your existing RSLogix code. You will see immediate benefits to reusable and rapid development programs with the same look and feel. Using this modular approach to programming means that you can select the parts from existing programs and tailor them to suit your particular needs for the current application. You have all the necessary parts and you can just adjust the parts to fit the project’s particular needs. In this application note, we cover one application, and from there you can branch out into your own application. We show you the states of a machine, cover power up, initialization, ready, producing, stop, fault modules, and give program examples for each that you can use in your own application development. Program Layout The state programming approach has been used for program layout for years, but the concerted effort to use a standard method has not. This paper outlines the steps of creating a motion control program using these tools. In this example, we use the PackML State Model* to define what should happen in each state and to create a functional specification document to define the intended operation of the machine. This becomes the programming document referenced by the application engineer when he begins to write the control program. Once one axis is up and running, creating another axis is a simple cut and paste operation. There may be specific changes that an axis requires, which can be easily done by editing the pasted version of code.

The machine state controls the entire system to drive the axes by monitoring the machine state to control actions on an axis level. This brings up the axis modules, which is an intuitive method of defining actions for an axis. Implementation of this is in the axis subroutines we provide as example starting logic. These modules include actions like Homing, Gearing, Camming etc. that are fully functional. Although the module will most likely have to be modified for your specific application, it provides a good start, and an example of how we would recommend structuring a module. The machine state dictates the actions needed for a particular axis. These are defined in the functional description for the machine. Beginning a Project To successfully integrate a motion program, several things should be available: Functional Specification Program structure example State Models Machine control templates Axis module templates Functional Specification of the machine - The customer should provide a functional specification that describes, in detail, the operation of the machine from the viewpoint of what needs to happen for a complete machine cycle. In some cases, this information is sketchy or non-existent. You need to determine what goes into this spec and how you get the information. The method shown here allows you to easily develop a specification. To develop a specification, start with a machine state model and define what happens in every one of the states. This information you include eventually becomes the functional specification, programming specification, and test and signoff verification specification all rolled into one. The following example shows a state model being used to define what the machine does in each state. The development cycle is to fill the diagram for the entire machine. This is an example of what to put into each state, although the specifics may vary from machine to machine.

Auto State Model Diagram

From Producing

STOPPING 1) Stop Initiated on Master 2) Once Master Stops All axes commanded to stop and disable feedback. State=32 Stop Command

Stop Process Complet e Initialize Comman d

STOPPED 1) System powered. 2) All Axes Off (Feedback Off) 3) Axes must be homed and repositioned before running. State=1

STARTING 1) Axes faults are cleared 2) Axes are enabled, Homed & moved to start positions 3) Gearing/Cams initialized 4) Master not Started State=2

Stop Command

Initialize Process Complet e

READY 1) Starting Functions Complete 2) Axes Geared/Cammed 3) Master NOT running

Stop Command

Start Comman d

STANDBY 1) Machine armed for produce conditions to commence motion.

Fault

Start Command

HELD 1) Holding Command Completed 2) Axes Remain active.

State=8

State=4

Fault

Stop Command

State=128 Fault

Hold Command

Fault Produce Condition s Become False

Produce Condition s Met

To Stopping

Fault

Holding Process Complet e

Stop Command Stop Command

A uto Mode Initiated BY Operator (STA RT A UTO)

ABORTED

PRODUCING

1) All Axes Off (Feedback Off) 2) Axes must be homed and repositioned before running. 3) Fault indications remain for review by operator State=512

1) Master Started 2) All axes performing auto motion 3) Bars being packaged State=16

HOLDING

Hold Comman d

1) Coordinated stop initiated on master. 2) All axes remain geared or cammed State=64

Fault

Fault

ABORTING A borting Process Complete

State Transitions Initialize Command Start Command Stop Command Hold Command

Initialize Process Complete Start Process Complete Stop Process Complete Hold Process Complete Produce Conditions Fault

1) Axes Individually commanded to stop (no coordination) 2) After Stopping Axes Disable Feedback. State=256

Draw ing Title: A uto State Diagram Rev1.0 Creation Date: January 15, 2003 File Name:

A utoStateModel.vsd

Programming Structure Example Included with this note are sample applications that you can review. This program sample is created to run on a standard ControlLogix Motion demo box available at your local AB distributor.

*Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

2

In the main module the Auto State logic module and Machine Logic module dictate what axis modules will be called to run. Put only the modules that you require into your axis program.

The major sections of the motion program structure will be consistent. Auto States Logic Machine Logic Axis module templates Machine control templates user defined data types (UDTs) Study the program sample to ensure you understand how the structure is laid out. Notice that the basic structure has the axis modules in their own Unscheduled Programs. This is where you can select which axis modules are needed for an axis. Auto State Logic The basic principle is that this module controls the Auto State model shown above. You can only transition to a legal state. This is explained further in the PackML section. Machine Logic This is the interface to and from the axis programs. It dispatches the axis modules for the axis commands such as homing, jogging, moving etc. Axis Module Templates This template has the modules for the axis commands, homing, jogging, moving etc. You can customize it for a particular axis and if you decide another axis requires similar functionality, copy and paste that module.

*Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

3

Axis Module and Component Plugs*

When you look at this axis module, you see that much of this is already in use and that the axis module structure lends itself well to our axis modules. Many of what they call components are closely related to our modules. These modules are a great way to reuse code that has been previously developed. Home Module - This Homing component is a canned homing sub-module for the axis that follows the homing method set up in the axis properties, or if need be as set via SSV. Jog Module - For a master axis, this Jogging component would be the actual start MAJ command of the machine to begin producing after the axes are synced with the master. This function would be in the AutoControl module for the master axis. For secondary axes, MAJ is found in the manual module for that axis. Move Module - This module has several purposes. For a master axis, this is the Move to component could be a cycle once incremental MAM command in the Registration module. For a slave axis, this is typically an offset move for registration correction. For more straightforward application types, this could be a manual move, or part of the AutoControl module (an absolute MAM of the master axis). It could be part of a manual module for the master or individual axes. Reset Enable modules - These are set in the reset enable task for each axis. PCam or Gearing modules - These modules are for each axis. State Models - We define and use state models for machine states and also axis states. This allows us to know what the machine is supposed to be doing at all times. The PackML Machine State Model serves as a basis for this application note. We’ve expanded on this document to form a template for the questions that need to be answered in order to define what should happen in each state. The Main Program has the Auto State Logic, which is a direct implementation of PackML state.

*Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

4

State Programming Diagram* Motion applications are typically sequential in flow, step 1, 2, 3 etc. (even though they are discrete systems of combinations of axes working on different things at the same time. It would arguably, rightfully be considered discrete control). That’s why states are used for programming. Many users have developed individual methods that work for them. We’ll define how we may combine some of that work with a larger model. This state model approach has been in use for years, and the new slant on it is that there are groups of corporations, OEM’s, automation suppliers, and end users, who are ready to embrace this as a standard method of programming. One of the main groups, PackML has developed guidelines for machine state control systems. We use this standard of state programming to simplify motion control programming. Note: This type of architecture is independent of programming method (i.e., Ladder, Structured Text, C, Sequential Function Chart, or Function Block). It applies to all types. This method determines the current state of the machine and what the possible avenues are from one state to the next. With this type of programming method, it is clear that it can only be in one state at a time and it makes problems with the machine more obvious. States A state completely defines the current condition of a machine. Transitions between states occur: As a result of a command As a result of a status change. This is generated by change of state of one or a number of machine conditions, either directly from I/O or completion of a logic module. Final state - represents a safe state (i.e., no moving parts). Transient state - represents some processing activity. It implies the single or repeated execution of processing steps in a logical order, for a finite time or until a specific condition has been reached *Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

5

Quiescent state - used to identify that a machine has achieved a defined set of conditions. In such a state the machine is holding or maintaining a status until transition to a transient state. Off - (Final) all power is removed from machine, electric, hydraulic, pneumatic etc. Power up - transition power up is when the power is turned on or the controller has been switched from Program to Run mode. Stopped - (Final) the system has been powered up or aborted, and requires initialization. Starting - (Transient) transition, the command to initialize the machine from the stopped state has been sent. This is where the faults are checked and cleared, axes are enabled, geared, and synchronized. Ready - (Quiescent) the machine has been initialized and serves as a place to wait for a Run or Jog command. If in auto mode, it goes into standby if there is intermittent motion waiting for product on the in-feed, or in the case of a continuous motion machine going into the producing state. Standby - (Transient) This state is used with intermittent motion cartoners, and not addressed here. The purpose of this state is to wait for product from the upstream machine. Producing - (Transient) Once the start button is pressed, the machine has been initialized, and is ready for production. The master axis begins jogging and the geared slaves follow the master axis. Aborting – (Transient) indicates that a fault (e.g., axis fault, E-stop, or guard open) has occurred. This attempts to bring the machine to a controlled stop before disabling the axis. Aborted – (Quiescent) awaiting a reset command. Stopping – (Transient) This is the result of a cycle stop or a program stop. If there is a product run-out, such as carton run-out, it invokes a cycle stop of the machine and alerts the operator that the machine requires replenishment. Machine Control UDT’s (User Defined data Type) Our axis modules all refer to the axis as ServoAxis, this is aliased to the controller scoped axis. The other alias that is created is that of the ServoVars, which is the structure below and should contain all of the information that you share between the axis module and the Main Program. This is so that only two aliases need to be created for the ServoAxis and ServoVars.

Axis Modules These are the generic modules that are used for axis control. (See the axis module figure on page 5 for a visual of the modules.) These are modules that will get an axis up and running, they should serve as examples of how to create a module, and you can edit this to suit your specific program needs. 6 *Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

Axis Enable & Reset Module This module enables the axes using the MSO instruction and gearing using the MAG instruction. The master axis in most cases is a virtual axis to maintain synchronization between axes. Machine State Module The following is a listing of all of the machine states. Fault Monitor Module - This watches for a cycle stop or Fault Action, and attempts to bring the machine to a controlled stop before the axis is disabled. A hardware E-stop circuit disables the axis immediately, if it does not use a safety relay that opens after a set amount of time delay. Fault Actions Module - This is an abort condition. A guard door has been opened or an E-stop has been pressed. We attempt to bring it to a controlled stop before the axis is disabled. Re-initialization is required after a fault has occurred. Cycle Stop Module - This is a controlled stop. The operator would like the machine to stop in a synchronized state and be able to restart without having to initialize the machine. Fault Reset Module - This module is always scanned and runs through resetting axis faults and clears the fault arrays when this module is called. Part of your fault recovery may include a light curtain application. Related Information Application types All applications are different and are generally treated as individual systems. Tuning a system Before a machine can be run you may need to know more about tuning a servo system. Refer to the auto tuning application notes at http://www.ab.com/motion/appnotes/index.html for more information. The following illustration shows the thought process for creating the functional specification and programming document. It shows what happens and when.

*Used with permission of the PackML packaging workgroup. www.arcweb.com/OMAC

7

Stopped to Starting, we wait for an initialize request. Off to Stopped, we wait for the communications.

We use lifted stop PB or MCR pos transition.

Starting to Ready, we consider initialize. We Home, Sync, Gear, Offset Move to C-Stop position.

We are using a 60 sec timer and ring status etc

8

Ready to Standby, currently we go straight to Producing. We wait for Start PB and determine Mode and start jogging master axis.

Machine Rates Calculator The following worksheet calculates the values of a production machine so that you can more accurately predict the tolerances of the machine. Of particular interest in this application is the timing required to fire outputs for applications of glue on the carton and the ability to place it where we want it at varying speeds. With that in mind, we can decide ahead of time if we can do the operation with program methods or if some sort of hardware PLS module is required. Double click on the sheet to allow input to the Excel spreadsheet below. This is the distance, leading lug to next leading lug of the cartoner.

Machine conversions Centre inches (cycle to cycle) Centre mm Speed ppm Speed pps

9 228.6 240 4

Speed Inc/sec Speed Inc/msec

36 0.036

Speed mm/sec Speed mm/msec

914.4 0.9144

Speed deg/sec Speed deg/msec

1440 1.44

Servo coarse update rate (msec) Actual motion group scan time Controls blind in inches Controls blind in mm Controls blind in deg. (min PLS window) Safe scan time (msec) no more than = Gun Delay sec Cam Compensation offset in degrees

The customer specified maximum speed.

This is a calculated value using the Coarse Update Rate Calculator shown in appendix A.

6 2 0.216 5.4864 8.64 4

This is the actual value online in the Motion Group Properties, Attributes tab.

This is the maximum allowable delay for a response; you can see the result of delay in offset in degrees.

0.015 21.6

Note: Enter new data in the red cells only the black values are calculated mechanical constants and the blue values are calculated values. This worksheet is just a tool to calculate the amount of error that is introduced in the response time delay based on the system speeds and hardware configuration. This indicate whether or not it is able to respond quickly enough using an MAOC (Motion Axis Output Cam), or if you should consider a PLS module for glue application.

9

Coarse Update Rate Calculator You can double click on the chart to open the Excel worksheet. Enter any values that are needed and the calculator does the rest.

Sub-Task

5550 R9 delta

5555 R9 delta

5563 R10 delta

5550 R9 total

5555 R9 total

5563 R10 total

214 177 23 350 214 78 234

124 117 18 208 124 69 146

122 55 11 17 11 21 37

214 1593 184 700 0 390 1404

124 1053 144 416 0 345 876

122 495 88 34 0 105 222

Total Execution Time

4485

2958

1066

usec

Coarse Update Period

9

6

2

msec

Motion Task Overhead Servo Axes Servo Active S-Curve Move Trap Jog Gear (Command) PCAM (Command, Cubic)

State/Action ( Motion Task Overhead Servo Axis Virtual Axis Consumed Axis Auto Tag Update Servo On Trap Move S-Curve Move Trap Jog S-Curve Jog Gearing (Actual) Clutch Gearing (Command) Clutch Position Camming (Actual, linear) Position Camming (Actual, cubic) Position Camming (Command, linear) Position Camming (Command, cubic) Time Camming (linear) Time Camming (cubic)

# Axes

9 8 2 0 5 6

5550 R9 214 177 173 928 197/108 23 216 350 214 316 252 157 78 130 432 524 234 385 180 286

5555 output Cam

3.7

output cams (1 cam per output) output compensation elements non zer0 latch/unlatch delay time

10 10 10

5555 R9 124 117 103 573 114/79 18 137 208 124 199 157 74 69 72 244 305 146 201 112 169

5563 R10 122 55

x faster 1.0 2.1

11 9 17 11 14 24 27 21 25 40 41 35 37 21 25

1.6 15.2 12.2 11.3 14.2 6.5 2.7 3.3 2.9 6.1 7.4 4.2 5.4 5.3 6.8

10

Important User Information Solid state equipment has operational characteristics differing from those of electromechanical equipment. Safety Guidelines for the Application, Installation and Maintenance of Solid State Controls (Publication SGI-1.1 available from your local Rockwell Automation sales office or online at http://www.ab.com/manuals/gi) describes some important differences between solid state equipment and hard-wired electromechanical devices. Because of this difference, and also because of the wide variety of uses for solid state equipment, all persons responsible for applying this equipment must satisfy themselves that each intended application of this equipment is acceptable. In no event will Rockwell Automation, Inc. be responsible or liable for indirect or consequential damages resulting from the use or application of this equipment. The examples and diagrams in this document are included solely for illustrative purposes. Because of the many variables and requirements associated with any particular installation, Rockwell Automation, Inc. cannot assume responsibility or liability for actual use based on the examples and diagrams. No patent liability is assumed by Rockwell Automation, Inc. with respect to use of information, circuits, equipment, or software described in this document.

www.rockwellautomation.com Corporate Headquarters Rockwell Automation, 777 East Wisconsin Avenue, Suite 1400, Milwaukee, WI, 53202-5302 USA, Tel: (1) 414.212.5200, Fax: (1) 414.212.5201 Headquarters for Allen-Bradley Products, Rockwell Software Products and Global Manufacturing Solutions Americas: Rockwell Automation, 1201 South Second Street, Milwaukee, WI 53204-2496 USA, Tel: (1) 414.382.2000, Fax: (1) 414.382.4444 Europe/Middle East/Africa: Rockwell Automation SA/NV, Vorstlaan/Boulevard du Souverain 36, 1170 Brussels, Belgium, Tel: (32) 2 663 0600, Fax: (32) 2 663 0640 Asia Pacific: Rockwell Automation, 27/F Citicorp Centre, 18 Whitfield Road, Causeway Bay, Hong Kong, Tel: (852) 2887 4788, Fax: (852) 2508 1846 Headquarters for Dodge and Reliance Electric Products Americas: Rockwell Automation, 6040 Ponders Court, Greenville, SC 29615-4617 USA, Tel: (1) 864.297.4800, Fax: (1) 864.281.2433 Europe/Middle East/Africa: Rockwell Automation, Brühlstraße 22, D-74834 Elztal-Dallau, Germany, Tel: (49) 6261 9410, Fax: (49) 6261 17741 Asia Pacific: Rockwell Automation, 55 Newton Road, #11-01/02 Revenue House, Singapore 307987, Tel: (65) 6356-9077, Fax: (65) 6356-9011

Publication RA-AP013A-EN-P – September, 2003

11

Copyright © 2003 Rockwell Automation, Inc. All rights reserved. Printed in USA.