Object Orientfid Programming
`
`or
`Motion Control
`
`By
`
`David E. Halpert, Technical Director
`Creonics Operation, Allen-Bradley Company
`Lebanon, New Hampshire USA
`
`Abstract: The application of motion control to solve general
`automation problems has been hampered in the past by the steep
`learning curve of traditional programming languages. From the
`application development standpoint, traditional motion control
`languages demand not only a complete understanding of the details of
`the application, but also a thorough knowledge of programming
`concepts before a solution can be implemented. A radically new
`motion control concept utilizing a graphical user interface and icons
`to represent motion functions is presented. This graphical motion
`control language allows free-form motion programming by simply
`connecting the icons to conceptualize the application in block diagram
`form. Motion and process details can be filled in later. Once the
`diagram is complete, it is converted into a text file in the native
`language of the particular motion controller to be used and
`downloaded for execution.
`
`The Need for Motion Control Software
`
`Today's manufacturing needs are generating requirements for greater speed, greater efficiency
`and affordable cost in many types of machinery and for many types of applications. An industry-
`wide desire to reduce capital equipment costs and at the same time increase the variety of products
`available has stimulated a requirement for so-called “flexible manufacturing” capabilities. This need
`has caused a rethinking of machine design and process control in newly engineered systems as well
`as providing the impetus to retrofit existing equipment with new functionality in motion control.
`Many machines with existing fixed-motion automation——such as mechanical timing devices (cams,
`jackshaflzs, gears, etc.)—are now being redesigned with servo mechanisms and intelligent electronic
`controls. Also, many small machines that were never previously automated are being fitted with
`computerized control systems.
`
`Today, powerful technology is available for sophisticated and precise motion control which
`allows innovative solutions for “flexible manufacturing” requirements. The cost of these controls has
`dropped significantly in recent years permitting broad use of motion control products for both OEMs
`(Original Equipment Manufacturers) and end users.
`
`Object Oriented Programming for Motion Control
`0-7803-0453-5/9l$1.00© l99llEEE
`1330
`
`Page 1 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`The electronic and performance capabilities of these controls are reaching a high level of
`maturity and standardization. As this has happened, the job of factory automation has become more
`focused on software and application development tools, rather than on hardware features and
`performance. Certainly, one of the largest costs involved with implementation of electronic motion
`control, is the cost of deyelgning the application solution rather than the actual cost of the control
`hardware itself. Maintenance of the electronics and software has a significant impact as well. It
`involves employing trained personnel with the right expertise, available in-house.
`
`Tools Currently Available
`
`Most of the functionality required for solving motion control applications now resides within
`the resident software of the of motion controller. This has led process and design engineers to focus
`on the software to get the efficiencies they need for plant floor automation. With the primary thrust
`of developing motion control solutions now focused on software, more efficient software development
`tools are becoming increasingly important. The software tools now have the most direct impact on
`both the time it takes to implement an application solution as well as on the cost in associated
`engineering resources.
`
`Presently, many motion controllers require the use of some form of proprietary programming
`language to access their functionality. These languages range from variants of traditional
`programming languages-—such as BASIC, Pascal or Forth—to completely customized command sets.
`Even though they may have different syntax, the software available in all motion controllers share a
`common heritage in their use of traditional programming methodology (i.e. commands in text files).
`
`Customized languages are diverse, highly specialized, and incompatible with each other as well
`as with traditional programming languages. There are six or eight standard programming
`languages in common use and an even a broader spectrum of specialized languages. As a result of
`this diversity and the fact that no control manufacturer dominates the field, no standard has arisen.
`Therefore, OEMs and end users today are faced with the fact that unless a particular facility has
`only one supplier of‘ motion control equipment, they are likely to have a difficult support issue.
`Training people to understand and be efficient in developing application solutions and supporting
`them with multiple programming environments is very costly and time consuming.
`
`Some motion control manufacturers have chosen the alternative route of providing their
`functionality as an extension to existing commercial software development packages rather than
`implementing a custom language themselves. Such motion controllers usually include libraries that
`are linked into third party products such as Microsoft’s C or QuickBASIC; or Borland’s popular
`TurboPascal. Some even supply assembly language drivers and/or interfaces. This still requires
`expertise in traditional programming techniques to implement motion automation solutions. The
`third party approach also requires the developer become familiar with two or more difi"erent products
`from different suppliers. This can lead to a problem of responsibility and support since the
`commercial software vendor usually has no knowledge of motion control and the specific extensions
`provided by the motion control manufacturer. The motion control manufacturer, on the other hand,
`supplies only a small part of the software and is hard-pressed to support the entire language and
`maintain compatibility with the software vendor’s enhancements and upgrades.
`
`Object Oriented Programming for Motion Control
`1331
`
`Page 2 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`The Problem with Traditional Programming Languages
`
`there are several major drawbacks to using any kind of traditional
`Unfortunately,
`programming language or a customized version of a traditional language. First and foremost, skilled
`software specialists are needed to implement motion control solutions. Second, there is a great
`inefficiency in having the process engineer communicate hi desires to the “programmer”. Thirdly,
`the resulting code is often very difficult to support by others after it is completed.
`
`The way most process engineers think about automation is not naturally compatible with the
`way conventional software tools force them to think. For example, the syntax of conventional
`programming languages requires complete entry of all associated details at the time it is written. In
`other words, you must know everything all at once! They also force design of the solution in a linear
`way, since conventional programs are inherently linear by nature. Automation system designers
`need an equivalent to a sketchpad, it's much easier and more natural to conceptualize major process
`functions and their associated timing sequences first and then go back later to fill in the details.
`Process engineers—because of the way they think—are more comfortable with a hierarchical flow
`chart approach rather than linear program code. Conventional programming languages force too
`much attention to be spent on the use of the tools and not enough on actually designing!
`
`Often machine designers are forced to turn to software experts because programming
`languages require specialized and non-intuitive terminology, structure, and syntax. Unfortunately,
`developing software requires learning and understanding a whole set of jargon that is unrelated to
`the actual automation problem. To write programs in conventional programming languages, the
`developer must understand many software-specific concepts. These include things like variable
`“types”, subroutines, labels, loop and control structures such as IF...THEN...ELSE, DO...LOOP,
`CASE structures, etc. No process engineer really wants to know how to properly terminate an IF
`statement, or whether to use a FOR...NEXT structure rather than a WHlLE...LOOP. Nor should
`one be expected to remember the specific name of the command (is it GOTO or GO TO). How many
`non-programmers (or even sometimes software experts) have been frustrated by not remembering
`the rules for statement terminator characters or where commas are required? Automation engineers
`don't spend enough time writing software to become proficient programmers and they shouldn't need
`to!
`
`The traditional software development environment contributes to the problem by adding new
`terminology to worry about. One must know what the difference between a compiler and an
`interpreter is, what a linker does, etc.. The end result is that instead of concentrating on the
`automation solution, the engineer is forced to spend his time concentrating on the details of the
`“language”.
`
`Some motion control products have attempted to alleviate the problem by providing a “syntax-
`directed editor” with the development package. This is a tool which puts an English language
`interface between the programmer and the resulting code. Prompting for individual functions in
`English only provides a limited degree of assistance. In reality, a syntax-directed editor only helps
`you create a mess more easily, it doesn’t address the main issue which is overall readability.
`
`The multi-leveled structure required by conventional programming does not facilitate
`readability. Hierarchical structures such as nested loops or subroutine calls are not easily indicated
`in a text oriented program listing. Anyone familiar with programming knows that artificial aids
`such as indentation must be used to make the program readable. Such formatting aids are still
`insufficient to clarify the overall structure of a conventional program. It is often difficult to locate
`the source code for a subroutine that you are calling (in order to remember what parameters need to
`be specified), since the routine in question might be located in a completely different place in the
`
`Object Oriented Programming for Motion Control
`1332
`
`Page 3 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`program's listing. Programming languages were developed to focus on implementation, not on
`readability.
`
`Using traditional programming languages for motion control applications incurs significant
`support costs after they are installed in the factory. Plant floor engineers, technicians and other
`support people are usually not trained software experts. This can make it a frustrating experience to
`attempt to make minor adjustments in the process or diagnose problems not anticipated by the
`original designer. The verbose nature and specialized syntax of conventional application
`programming languages make it hard to gain a quick understanding of the underlying operating
`concept of the machine. Natural visual markers to aid in following the sequence of operations are
`lacking. Attempting to understand someone else’s software, one quickly encounters “word overflow”
`staring at pages and pages of program code listings!
`
`The end result is that the application or process control engineer is overwhelmed with a
`plethora of possible software environments, and the few software tools available are difficult to use.
`Further, conventional programming languages are not a natural or intuitive way to developing
`automation applications. The problem thus persists that solving motion control problems involves
`an investment in software experts both for developing the application solution and for supporting it
`afterward. Today, there just aren’t enough competent software people available.
`
`Using Graphics
`
`The first part of the solution to making motion control applications development easier is to
`take advantage of more of our natural capabilities than just language. Psychologists have known for
`a long time that combining the visual capabilities of our brains with the verbal facilities can make
`learning much easier. The old saying that “a picture is worth a thousand words” really has validity
`for programming as well. Dr. Jesse Quatse stated it eloquently in an article in a recent issue [1] of
`Industrial Computing magazine, "It is difiicult to say a dozen things at the same time but it is very
`easy to see a picture ofa dozen things... C is for saying not seeing!”
`
`A good way to take advantage of this combined visual/verbal method is to allow the engineer to
`conceptualize ideas in the form of simple pictures which represent basic process functions with lines
`connecting them to represent the timing sequence. This is really a graphical flow chart which is a
`very natural extension of the way the engineer thinks about machine operation. The function blocks
`can be represented by icons on the computer’s screen which also have a text field for additional
`clarity. The eye is much better at quickly picking up a symbol on a page than a word or phrase. By
`designing the icons so that they either look like what they do, or illicit a mental image of their
`function, it becomes easy to see what’s going on.
`
`Some scientific evidence now supports real benefits to users of a graphical environment. The
`consulting firm of Temple, Barker & Sloane conducted a study in 1989 in which they measured the
`benefits of a graphical interface versus a conventional text entry system [2]. When two sets of
`subjects where given a series of tasks to accomplish, their test results showed that 35% more tasks
`were completed in the same amount of time by those using the graphical system. The study also
`indicated that 58% more correct work was done in the same time. Novice users appeared to have
`attempted 23% more different tasks than their counterparts using a text entry system. Rated
`fatigue and frustration levels were documented as 50% less when using a graphical environment.
`
`Object Oriented Design
`
`The second component of the solution to making motion controllers easier to apply is to
`combine the graphical user interface with an object-oriented, modular structure. Object-oriented
`programming is a new concept just coming into wide use, particularly for graphically oriented tools.
`
`Object Oriented Programming for Motion Control
`
`1333
`
`Page 4 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`A major attribute of an object-oriented programming system is that it is designed to allow individual
`modules within the system to be developed independently. It provides the capability to design using
`sophisticated functional modules that don't necessarily require detailed knowledge of their inner
`workings. Another key attribute of object-oriented environments is the facility for allowing modules
`to be easily re~used with little or no modification. This allows creation of application-specific “black
`boxes”, greatly reducing the time to develop additional related applications or modify the original
`one.
`
`Brad Cox in his recent article on Object-Oriented Programming in Byte Magazine [3] describes
`the concept by stating that custom control systems can be built from off-the-shelf cards without
`having to understand soldering irons and silicon chips, just as vendors can engineer cards from off-
`the-shelf chips without detailed knowledge of transistors. This process has been applied for some
`time to electrical and mechanical systems design, it now needs to be applied to the software used for
`motion control applications. The potential productivity benefits are very substantial.
`
`Putting It All Together
`
`The Creonics Operation of Allen-Bradley has applied some of these principles in a unique
`application development environment called Graphical Motion Control Language (GML) which can
`be used to implement motion control solutions using Allen-Bradley Stand-Alone and PLC plug-in
`motion controllers. Following are 5 examples of the more than 100 functions blocks and their
`associated icons used to implement motion control solutions with GML:
`
`Sefiimer
`
`Providing a graphical function block library—where you can scroll through all the available
`function blocks and just point and click to select a particular one to include in the flow chart,—makes
`it very easy to put together complex operational sequences. Color coding related function types, using
`green for all blocks that cause motion or red for all blocks that stop motion for example, can greatly
`aid in quickly selecting the needed function. An example of such a library is shown below:
`
`Does absolute or incremental move or an axis to a programmable position at
`a programmable speed, aceol 8: local rate, optionally volts for completion
`
`Fooaack II: Feedback Off So! Duipul
`L1m1(
`
`Wall for
`Output Limit
`
`Axis Status
`
`d
`
`l
`
`l62£::1%¢‘é
`Change Gain Direct Drive
`Show Axis
`Redefine
`Clear Axis
`Control
`Position
`Position
`Fault
`
`is
`its
`file
`Efi
`Set Move Set Maximum Set Maximum Set Maximum Configure
`Profile
`Velocity
`Cam
`
`Object Oriented Programming for Motion Control
`
`1334
`
`Page 5 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`Another example of the value of a graphical format is that it is much easier to understand how
`a loop works by showing where it starts and ends than by trying to find words in a long program
`listing.
`
`As shown in the above fragment of an application diagram, it is very easy to understand
`exactly what is happening and in what order, without any prior experience with GML or any other
`programming language. Also, the details of each function block are hidden (to simplify the view)
`until called for by clicking on that function block’s icon. This brings up a special form which contains
`all of the necessary information in English to help fill in the desired parameters. Shown below is an
`example form for the Move Axis function block in GML:
`
`“mil
`Move -./'ll[)Sf,lllJlI?
`
`Position
`Speed7.
`
`lFeed_.length
`I-'eed_Bate @
`
`”°°°'% 31
`'Z”"°'
`Does absolute or ‘Incremental move of an axis to a programmable position at a
`programmable speed, accel 8:. decel rate, optimally waits for completion
`
`-
`
`Using a fill-in-the-blank graphical form approach permits easy entry of all needed parameters;
`in this case including which axis to move, the type of move to perform, as well as the position, speed
`and acceleration values to use. All of these can be entered or modified at any time without the need
`to consult a manual or understand specialized syntax. On-line context-sensitive help is also
`available to immediately aid in understanding exactly how each block can be used.
`
`To facilitate entering numeric value parameters into the form, a built-in calculation
`constructor facility can be accessed by clicking on the graphical question mark button next to each
`parameter. An example from GML is show below
`
`Object Oriented Programming for Motion Control
`
`1335
`
`Page 6 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`Posltlon -
`
`flctuaI_PosIlIon
`CommandJosItIon
`slrobed..PosIlIon
`FIegIstrutIon_PosItlon
`PosIl|on_£rror
`lnstnntaneous_l!eIocllg
`
`© system llarlables
`0 User llammleo and Ennsioms
`0 System Function:
`
`This tool allows construction of mathematical expressions using a very simple point-and-click
`method. All legal arithmetic operators and operands are shown in lists, including any user-defined
`variables, predefined internal variables and special math functions. This is similar to techniques in
`spreadsheet programs used to make entry of mathematical expressions very easy and user friendly.
`
`To aid in constructing application flow chart diagrams, it is desirable to use tools that are
`natural metaphors. For example, to make connections in GML, a soldering iron symbol is used to
`visually drag connections from one function block to the next in timing order such as is shown below:
`
`In a similar way, a symbolic wire cutter tool is used to break connections between blocks to
`change the timing sequence.
`
`Move Axis
`
`Use of symbolic “wire” connections to indicate the operation sequence eliminates any need for
`special programming knowledge of labels or other program flow control constructs used in
`conventional languages. These are completely handled by the graphical environment manager when
`it creates and automatically outputs a program for the target motion controller.
`
`To avoid requiring the developer to also be an artist, a graphical user interface should include
`the capability to assist in automatically routing the connection between blocks in a neat orthogonal
`way. A snap grid can be used to facilitate placement of the blocks.
`
`Object Oriented Programming for Motion Control
`1336
`
`Page 7 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`One of the other major problems with conventional programming languages that can be solved
`nicely with a graphical, object-oriented approach is the problem of understanding the overall concept
`of an application. By making the graphical system hierarchical, different levels of functionality can
`easily be represented. The designer can create application-specific modules or “black boxes” which
`make the readability of the diagram significantly better.
`
`This is accomplished by implementing a special function block called a “module” which can be
`placed in the diagram like any other block. This block can be later “zoomed” into to work on it’s
`lower level sequence of operations. You can in turn, “zoom” out to see the higher levels of
`functionality easily. This promotes breaking up the application into manageable chunks. Modules
`can also be reused where needed, thus performing the same function as subroutines in a
`conventional language without requiring any special programming knowledge. Modules can also be
`cut and pasted between different sections of the diagram or even to and from other applications.
`
`As an example, the following diagram shows the highest level view of a rotary cutoff
`application diagram:
`
`Rotary cutoff
`
`Often, an engineer knows he needs an initialization sequence, but hasn't yet established
`exactly what it needs to do. Creating a blank receptacle module allows him to continue his train of
`thought and fill in the exact sequence for initialization at a later time. Shown below is an example of
`a finished lower level sequence for the initialization module illustrated above:
`
`v/
`
`5
`
`E
`
`Slartup
`
`Define material zero here
`
`Initialize last out position
`
`Start feeder
`
`Putting high level modules together without filling in their functional details allows the
`process engineer to develop his concept without getting bogged down by specifics. At his
`convenience, he can later focus on the details of specific modules. This greatly facilitates
`implementation of motion control and automation applications by non-programmers. Another
`benefit of using this hierarchical view of the application is that it provides inexperienced operators or
`support people an easily understandable overview of the process after the design is completed.
`
`Another concept that is difficult for inexperienced programs to grasp is multi-tasking. This is
`the capability for having more than one part of a program running at the same time. A graphical
`
`Object Oriented Programming for Motion Control
`
`Page 8 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`design approach makes this normally difiicult concept easy to implement and for someone else to
`later understand. An example of multi-tasking is show below:
`
`multi-tasking demo
`
`An Example Implementation
`
`The following example illustrates the complete implementation of a typical motion control
`application using a graphical development environment such as GML.
`In this example, a self-
`adhesive label is to be properly positioned on a package. The packages are moving continuously on a
`conveyor and the labels are fed continuously from a feed roll. The packages are spaced on a conveyor
`belt at known distances from each other using pusher bars. The labels are contained on a web which
`may shrink or stretch due to heat, humidity, etc. In addition, the web is driven by feed rollers which
`may slip.
`
`Label Feed
`Motor/Encoder
`
`XRegistration
`
`1
`Label on Web
`
`Pusher Bar
`
`;
`
`Label
`
`Registered
`on Package
`k’
`
`Package Conveyor
`
`Conveyor Encoder
`
`In operation, the label web is geared to the conveyor at a 1:1 ratio, and a registration sensor
`(photo cell) detects the leading edge of the label. The Motion Controller calculates the error between
`the actual position of the label and the current position of the next package. An incremental move on
`
`Object Oriented Programming for Motion Control
`1338
`
`Page 9 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`top of the gearing is used to phase advance or retard the label web to compensate for this error,
`ensuring proper registration of the label on the package.
`
`Package Labeler
`
`Set Registration
`
`wait for Registration
`
`Phase Adjust
`
`The above picture shows the top level of the GML diagram used to implement a solution. It
`utilizes several modules to cleanly divide up the necessary functions of initialization and the actual
`phase correction algorithm.
`
`\/
`
`Initialize
`
`Start at zero
`
`initialize 1st package position
`
`Start web following conveg or
`
`Initialize
`
`The above diagram fragment shows the details of the initialization sequence.
`I
`
`Phase Adjust
`
`Compute phase error
`
`Advance or retard
`
`ompute next package position Phase Adjust
`
`The last diagram fragment shows the details of the phase adjustment module.
`
`The power of a graphical approach is shown by the how easy it is to visualize and understand
`the whole process sequence of this application example.
`
`Conclusions
`
`At the most abstract level, most machine design engineers think about their processes in terms
`of a sequence of events. Each event may be a very simple operation or actually might be a complex
`process in itself. Conventional programming languages make it very difficult to bridge the gap from
`this concept level to actual implementation. Too much efficiency is lost in continuously having to
`refer to manuals to either look up the right syntax, or to figure out how to implement the flow
`structure using that language’s constructs. A graphical, object-oriented approach to application
`development allows the process experts to be directly involved with the implementation of the
`solution, rather than having to communicate their desires to another software expert or becoming
`programmers themselves. It also has the added benefit of making making motion control friendlier,
`making the machine designer’s experience with it easy and successful. This stimulates interest and
`leads more engineers to try motion control.
`
`The graphical nature of this new concept offers a great advantage not only to the developers of
`motion control applications, but also to those forgotten people, the technicians and engineers who
`have to support the machines alter they are installed. The graphical approach makes it extremely
`easy for inexperienced operators, service people, etc. to gain an understanding of the basic operation
`of the system. This makes it possible to make minor changes in operation without having to expend
`large costs to call back in the machine designer or hire a consultant.
`
`Object Oriented Programming for Motion Control
`
`1339
`
`Page 10 of 11
`
`RA v. AMS
`Ex. 1013
`
`

`
`A Proviso
`
`There is one unexpected drawback to using a graphical object-oriented programming
`environment for motion control applications. Don Crabb said it well in his Byte Magazine article last
`year [4] when referring to the Macintosh's user friendly graphical interface, "(it) does such a good job
`of taking us over the start-up hump that we forget about that niggling little problem of subject matter
`expertise." In other words, a product like GML still only provides a set of tools, it is up to the user to
`know what he wants to build!
`
`References
`
`[1]
`
`Dr. J. T. Quatse, "A Control Paradigm: Thinking About Thinking About Things,"
`pp. 18-22. May/June 1990-
`.
`
`D. Davidson, "Benefits of the Graphical User Interface," Temple, Barker and Sloane, Inc.,
`[2]
`Lexington, MA, 1989.
`
`[3]
`
`[4]
`
`B. J. Cox, "There is a Silver Bullet," , pp. 209-218, Oct. 1990.
`
`D. Crabb, "The Place To Be For DTP," , pp. 87-91, Sept. 1990.
`
`Object Oriented Programming for Motion Control
`1340
`
`Page 11 of 11
`
`RA v. AMS
`Ex. 1013