Comment

01 November 2002

Tripping to the library

Template language sanctions reusable control logic.

By Marvin Schwenke and Raymond Staron

Standard relay aladder language (RLL) is not powerful enough to allow the expression of truly generic logic that can produce circuits for any machine.

What is needed is an extension to standard RLL that lets a circuit designer express truly generic, reusable circuits. Template language lets the circuit designer determine the structure and behavior of all derived control programs while deferring the specification of machine-specific information until later.

Using these extensions, solutions for a class of applications may exist as a hierarchical collection of templates, with each template encapsulating only those circuits that are truly generic. This approach defers the machine-specific details through the use of constructs such as module specifications.

The increasing complexity of manufacturing machines and process controls is beginning to represent a much larger portion of the cost of today's production machinery. The cost of controls hardware is less of the overall cost of the machinery than the cost of turning a collection of control components into a control system.

The cut and paste approach to designing control system software may work for small pieces of equipment, but it does not work in industries where the equipment is large and/or synchronous or where there are many variations of each type of logic circuit.

A processor-independent version of relay ladder logic enhanced with certain macro, compile time, and extensions allows the specification of truly reusable units of control logic-templates-such that a library of these templates, when combined with parameters describing a specific application, results in RLL with predictable structure and behavior.

With the proper controls system design tools, the following is possible:

• A systems integrator can develop a library with templates representing all the required application-specific equipment and control
• An end user can use the library to create a description of a specific machine or process
• The system can then automatically generate the resulting RLL for a specific control system and list of I/O address assignments

This increases the user's productivity, reducing debugging and start-up time, eliminating rework, and enforcing standards.

One can summarize the cut and paste approach this way. Design specific logic circuits once, knowing that the term circuit refers to a collection of statements in the relay ladder logic control language.

Put them into a component library. Then, using copies of circuits already in the library, build components progressively broader in scope until an application can form entirely out of the components at hand.

Library components are, in effect, black boxes with predefined interfaces in much the same way that integrated circuits work in the electronics industry.

This approach works quite well for equipment that is somewhat autonomous, which is to say those machines unaffected by the equipment upstream or downstream from it in the manufacturing process, and for applications in which the needed circuits tend to be very small and highly reusable, with a small number of inputs and outputs.

The cut and paste approach, however, does not work in the metal removal and welding industries, where the equipment is large and synchronous. These applications require many more variations of each type of circuit.

In a simple circuit-normally open or normally closed tripped in the position in question and released otherwise, or vice versa-there are 16 possible standard circuits (24).

To put these circuits into our library, an OEM could create 16 standard circuits, each named for the case it handles. Creating these 16 standard circuits in our library also results in redundant circuits under different names.

Alternatively, the OEM could have placed just the four unique standard circuits into its library, but it then encounters a problem naming them so that the end user knows which physical cases are handled.

Lastly, the OEM could use 16 names each with a pointer to one of the four circuits. Even in this simple example, the practical aspects of giving each standard circuit a meaningful name that enables the user to find the desired circuit from the library can be problematic.

In the two-switch example there are 16 physical permutations resulting in four distinct circuits. In a three-switch example generated by adding a Feed switch to the original set, there are 64 (26) physical permutations resulting in eight distinct circuits, for a total of 80 permutations of 12 distinct circuits. If we add a Tool Change position switch as a fourth switch, the numbers grow rapidly.

Adding to these totals the number of possible circuits for the advanced position, the feed position, and all the other discernible positions along the axis of travel increases the number of circuits to an unwieldy level. Trying to find the standard that you need in such a library is more trouble than building the circuit from scratch.

Not all circuits are as simply structured as these position circuits. The content and topology of some circuits depend on many more variables than the position circuits do.

The structure of a circuit for a station may depend on many variables-for example, the number and type of actuators; type of spindle, if any; whether it interferes with the station across from it, if any; type of fixture; bushing plate, if any; and transfer bar type.

The cut and paste approach is not flexible enough to accommodate the number and complexity of the circuits that are common in all but the most straightforward applications. We need a solution with the following:

• Uses a library of component templates.
• Circuits for each template are specified in symbolic form and therefore not tied to explicit addresses in the programmable logic controller (PLC).
• When a component is created from the template in the library, its resulting circuits adapt themselves to the particular surroundings and configuration of the component itself.
• Is general enough for complex circuits as well as simple ones.
• Is simple to use so the designer's workload is reduced, not increased.
• Generates circuits that are as efficient in their topology as if the user had drawn them, without unnecessary overhead.

The complete definition of a customer's machine, its structure and desired behavior, plus its accompanying control system lies in three artifacts: the machine tree, the control system, and the template library.

The goal of encapsulating truly reusable logic can eventuate by extending relay ladder logic to the concept of template language. The use of template language allows the specification of truly reusable units of control logic, called templates.

The extensions to RLL support context-dependent reuse of the encapsulated logic. Using template language, a circuit designer develops circuits within the templates of a library that automatically adjust to the parameters of a machine and result in relay ladder logic with predictable structure and behavior.

The template library contains two main categories of information: rules for the proper construction of a machine tree and the RLL templates used to specify the control code.

It contains the complete description and set of rules for all allowable machine trees. The OEM or the customer's central engineering department writes the account so it promotes the company's rules, guidelines, and philosophies on control in some application domain.

As such, the template library, once completed for a specific application or set of machines, is rarely modified or updated. But it can be changed to alter control strategies, for example, or add support for new equipment.

The machine tree and the control system, however, are unique for each machine, and the end user usually authors these. A machine (or machine tree) is a hierarchy of subcomponents that, when properly orchestrated by a control system, realizes some portion of a manufacturing process.

The machine tree holds all the details of a specific machine, its structure, and its required behavior and is composed according to the rules in the associated template library.

The third major artifact, the control system, is a description of the control equipment-for example, chassis, networks, processors, and I/O cards-that will hold and execute the control program and ultimately control the equipment described in the machine tree.

MACHINES GROW ON TREES

Every node in a machine tree has a name and a type-i.e., each is a uniquely identifiable instance of a template in the template library.

Every node in the tree has both a local name that is unique relative to its parent and a full name that is unique within the entire machine tree.

Consider a partially completed machine tree, noting both the names of the components and their types, which are the entries within parentheses:

MyMachine (a Machine)

MasterConsole (a MasterControlPanel)

T1 (an Indexer)

Station1 (a Station)

Station2 (another Station)

LH (a WorkUnit)

Spindle (a DiscreteAxis)

MainSlide (another DiscreteAxis)

CrossSlide (a third DiscreteAxis)

The name Spindle is unique relative to its parent, LH; therefore, LH can have no other child with the name Spindle. The full name of Spindle is MyMachine.T1.Station2.LH.Spindle. This name must be unique in the entire tree.

Note that it is certainly possible and sometimes desirable for certain local names to appear more that once. If, for instance, Station1 also contained a mill with a cross slide, a main slide, and a spindle, then the same descriptive names CrossSlide, MainSlide, and Spindle could serve within Station1, with the local names still being unique to Station1.

Indeed, full names such as MyMachine. T1.Station1.MainSlide are still valid and unique to the entire tree.

Each node in the tree is unique, having unique surroundings and configuration. Therefore, even nodes of the same type can generate different circuits from the same library template, provided each component node, through its template, has some ability to make decisions based on its own surroundings and configuration.

This decision-making ability is the direct result of the template language used to build the templates in the template library.

The first group of extensions to RLL that appear within the template library are those that are independent of the standard rung form of RLL. These extensions include data specifications and module specifications, and they supply information describing the following:

• The set of all available components to add to the machine
• The types and number of subcomponents each component is allowed to have
• The types and number of subcomponents each component is required to have
• The order in which the components are to be compiled (determines the order of the rungs of the resulting program, although certainly, depending on the PLC used, a suitable development environment may offer many choices for the arrangement of the resulting program within the PLC)
• The data to be allocated and used within the PLC

The second group of extensions is extensions to the RLL instruction set itself. This group includes a symbolic expression language for specifying instruction operands, pseudoinstructions, and macroinstructions.

In template language, all operands on all instructions compose with a symbolic expression language, including operands on instructions in the traditional RLL instruction set.

The symbolic expression language lets the circuit designer refer to machine-specific parameters and to data items defined in other components by their associated templates. Reusable logic may include any mix of rungs, data definitions, and module specifications.

Further, rungs may consist of any arrangement of instructions, both traditional RLL instructions and extensions, as long as the shape of the rung is a valid RLL construction.

A data definition declares and reserves space for each PLC data table element, including Boolean, digital input, digital output, analog input, analog output, timer, counter, integer, and float. Each definition has a unique name, and each of these types is later mapped to a specific implementation on the target PLC. Data definitions can reference by any type-compatible RLL instruction.

A compiler attribute has a unique name but results in no PLC memory storage. The attribute's specification includes a short executable script. At compile time, the script executes and must resolve into a Boolean value (true or false), a numeric value, a string, or a component in the machine tree. The result then functions within an operand of a compatible RLL instruction.

A compiler list attribute is much like a compiler attribute except that the execution of its script results in a collection of items all of the same type. This resultant list then serves as the iteration list of an AndMacro or an OrMacro macro instruction.

A parameter represents an integer, real, Boolean, or string value that the end user will edit to specific requirements. The parameter values can be converted to compiler attributes that can be subsequently referenced by RLL instructions and hence influence the generated RLL code.

MODULE SPECIFICATIONS

Template language defines several kinds of module specifications. The kind of specification affects the type and number of modules that can or must be created, which in turn determines the number of instances of reuse of the specified template. Many module specifications need machine-specific parameters so the compiler can expand them properly.

A module list specification allows zero or more component modules of the specified type. The exact number of modules created is machine specific. Each module must take on a unique machine-specific name to ensure uniqueness. For example, a specification that an Indexer contains multiple Stations can add to the Indexer template. The end user supplies each Station created with a unique name.

The template library supports inheritance among the modules, allowing inheritance of type (e.g., a MotorStarter is a type of Actuator) independently from inheritance of implementation (e.g., when expanded, the code for a MotorStarter includes all the code defined for an Actuator).

A fixed module specification does not result in the creation of a module. The specified template simply expands within the parent context that refers to it and inherits the implementation of the parent. An example of this is a specification that a MotorStarter includes the implementation of its supertype Actuator.

There is also a need to allow a module to include the implementation of another module without regard to any supertype/subtype relationship. It may be convenient, for example, to place some often-used code in its own module and simply include it wherever needed. An include module specification such as "a Cycle contains ModeOfOperation logic (but a Cycle is not a subtype of ModeOfOperation) provides the solution.

A named module specification results in a single named component module of the type identified in the specification. A module name must also appear in the module specification - e.g., a MasterControlPanel contains a Pushbutton named MasterStartPB. Using this specification, the template can refer to MasterStartPB in its RLL and know that the user cannot change the name of the button. IT

Behind the byline

Marvin Schwenke has 32 years' experience in developing machine tool controls, the last 13 with Allen-Bradley Co. and Rockwell Automation. He holds seven U.S. patents in the area of automatic generation of controls programs. Raymond Staron has degrees from Case Western Reserve University and the Massachusetts Institute of Technology, including a Ph.D. in computer science. He has worked with Allen-Bradley Co. and Rockwell Automation for 25 years.

Read Schwenke and Staron's original ISA paper online for further discussion of module specifications, symbolic expression language, macroinstructions, and psuedoinstructions and to see example code: www.isa.org/journals/intech/1088.pdf

Related Links