Control Engineering Online Update for February 11, 2005

Object-based programming has become a common aspect of today’s office automation software products. Anyone who has added a customization to a spreadsheet or a user interface to a database is familiar with the benefits of these re-usable, self-contained modules. The world of programmable logic controllers (PLCs), however, had been slow to react to user demand until the release of the IEC61131-3 programming standard and subsequent products.

The IEC61131-3 standard attempts to bring order to the chaotic world of PLC program development by implementing a better definition of program and data table structure. By adopting these standards into the definition of data table tag structures, a re-usable piece of logic can be developed which is not unlike objects that we use in Visual Basic, Access, or Excel.

In its simplest form, an object is a piece of logic that executes one or more functions based on data contained within it. In addition, this object/data pair can be reused easily throughout the same program or in different programs.

To show how this is done, Rockwell Automation’s ControlLogix will be used to depict how object-based programming is performed on PLCs.

Defining an object
The general architecture of programming an object within the ControlLogix processor is shown below.

To illustrate how such an object can be implemented in an actual ControlLogix program, let’s use an example of conveyor control. The object requirements are as follows:

• The system has many conveyors

• Conveyors use full voltage non-reversing starters

• All conveyors have overloads and auxiliary contacts

• Manual-off-auto functionality is required

• Human-machine interface control is required

• Simulation of I/O prior to installation/commissioning is required

• Diagnostics are required (failed to start, overload, failed to stop, etc.)

User-defined types
If we were designing the above using traditional PLC products, we would assign blocks of data for each control element. A variety of Boolean or binary files would be required. In addition, some integers, timers, and floating-point files would likely be required. The end result is data fragments for each conveyor. By using the user-defined type (UDT) model, data is grouped together regardless of type. In addition, data types can be nested to allow re-use of sub-structures. The following illustrates some possible UDTs, which could be developed for conveyor control:

Master UDT: Conveyor
The master UDT is the variable type we use when declaring our tags. A timer structure, in conventional PLC terms, is an example of such a structure. The timer can have a preset (.PRE), an accumulated value (.ACC), an enable bit (.EN), a done bit (.DN), etc. These dot-references are, in fact, elements of a system-defined-type (SDT) structure called Timer. When we define a master UDT we are creating similar elements and sub-elements. We may create references to other UDTs (nesting) and/or may define the actual data references. This screen shot shows the master UDT definition for the type Conveyor.

Sub-UDTs
The sub-UDTs provide functionality, which may be re-used on master UDTs other than Conveyor. For example, mode selection is a common requirement for many devices, not just conveyors. For this reason, a UDT called Process_Mode was created. Below is an exploded view of the Conveyor UDT to depict the Process_Mode sub-elements:

When defining sub-UDTs and elements within UDTs, descriptive names should be used. This will be beneficial for program documenting since only the master UDT will require a descriptor. The element names will serve to further describe themselves.

Declaring the UDT
In our example, let’s assume we have 100 conveyors (CNV1 – CNV100). We can either declare the tags individually or in an array. The advantage of declaring the tags separately is that each conveyor can have a unique description. If declared in an array, descriptions will not carry through the structure.

Object logic definition
Now that a data structure has been defined, logic must be written to act on this data structure. Utilizing the ControlLogix multi-program layout, a program called “Devices” can be created which contains a subroutine for each conveyor. The subroutines should be named the same name as the object. For this example, create a subroutine called CNV1 (as shown below in the program file tree).

It is very important to ensure that all logic in the object subroutine only reference elements of the object data structure. This will allow re-use of the object code in its entirety. Real I/O can be mapped into object elements from another subroutine located under an “Inputs” program and real outputs can be activated from object elements programmed in another subroutine located under an “Outputs” program. This I/O mapping accomplishes the following:

1. Synchronization of input and output scan

2. Segregation of real-I/O from logic

3. Possibility of using I/O simulation from inside the object code

Typical input and output mappings are shown here (input is top graphic).

Once the I/O has been mapped, the object logic follows. The following example shows a simplified run command using object elements only.

Summary
When defining a multi-device system, object-based programming can drastically speed development and deployment. Once the initial object logic has been written and debugged, the following steps can accomplish re-use:

1. Create a controller-scoped object tag for new object

2. Copy device, input mapping, and output mapping subroutines

3. Rename routines to object name

4. Search and replace object names within routines

5. Re-map real I/O

The speed of deployment comes because only one search-and-replace needs to be done per subroutine if I/O alias tags are used to define device I/O. All device functionality required for current and future needs can be built into the object model. This allows re-use within existing and future projects.

Testing and commissioning accuracy can be another derived benefit from using this model. By building simulation logic and data structure into each object, the entire testing and simulating process becomes a function of the object. This also adds to object portability because the object can be completely tested without a physical connection to the I/O sub-system.

Mike Voll is controls manager, manufacturing/industrial, Stantec Consulting Ltd.