Objects solid in automation

Object-oriented programming (OOP) was designed from scratch with modules in mind and is straightforward, flexible, and an ideal tool for creating reliable applications to manage complex tasks.

By Matt Scott, Deseret Laboratories

BY NOW, even the most hardened ladder logic devotee has heard about programming alternatives such as object-oriented programming (OOP). This technique lends itself to structured and modular software code. Modular coding can be implemented with virtually any programming language from ladder to function block, but object programming was designed from scratch with modules in mind.

This means that OOP tools and programming languages naturally lead to discrete modules or blocks of code linked together with rules that are part of OOP programming languages.

The flip side of modular programming is simple, monolithic or spaghetti-style programming. These types of programs don’t use modules but rather have all code in one continuous string. Monolithic programming skips advanced programming techniques, and goes straight for the quick fix. This often means programmers are writing code without first thinking about the overall structure of the program. This might seem to be an expeditious way to write a program, but problems often result.

A program written without a pre-defined structure can become very complex—even incomprehensible to everyone except the original programmer. Even the original programmer could become confused as the program grows more complex or when it needs to be revisited later.

Conversely, structured and modular programming requires thought and planning prior to coding. If structure and modules are desired, then OOP is an ideal tool.

Modular coding, OOP in particular, offers many advantages over monolithic code including ease of test, reuse of code, and portability to different hardware target platforms.

OOP was developed for good reasons, and, under the right circumstances, it can produce excellent results and perform tasks that are virtually impossible otherwise. With OOP, a skilled programmer can program an application in an organized manner.

It only takes one programmer to properly develop an OOP framework. That framework can then be used by other programmers. The beauty of OOP lies in its ability to manage complex tasks, its flexibility, and its efficient use of hardware.




Inside OOP
OOP is a high-level extension of the modular code concept. By building cleverly thought out, reusable modules of code, repetitive programming is avoided. Code also becomes more organized and readable.

Individual modules of code, or classes, can “inherit” each other’s contents. A child class inherits the contents of a parent class. Inherited contents can be modified by adding new code or improving old code. For example, a parent class can be written to allow a PC to exchange data with a particular PLC brand and model.

A child class also can be created for a different PLC, with the child inheriting the parent’s common functionality, while still giving the programmer a way to add hardware-specific details.

An object is an instance of a class, and it contains data and code that operates on that data. Multiple objects or modules are linked together to build programs.

As a result, objects can be linked together in a tree structure by having them contain each other’s memory addresses. Those addresses then can be followed from object to object. This functionality is called traversal. As the program traverses, each object is accessed, and the program gathers information about that object or provides services such as settings management of that object.

For example, the traversal function can be used to build a test-and-validation document for the entire program by traversing a tree of objects that contain the file name of a test-and-validation document that describes the object and its requirements. The traversal function collects all test-and-validation information in an organized fashion.

By traversing a similar tree of objects, a programmer can gather all the pertinent information describing those objects. This information can then be used to build a new program with a similar structure on another machine. This technique is known as serialization.

An entire graphical user interface (GUI) page can be transported from one hardware platform to another by serializing an object that contains a description of the GUI page.

When to OOP
OOP takes more up-front work than monolithic code, so OOP should be applied only when dictated by circumstances.

OOP systems are particularly useful when all the eventual uses and applications of a program can’t be known in advance. Some OOP languages also are suitable when a software program is needed to control a variety of hardware, for example, when a corporate-level software engineer must implement an advanced control algorithm across several plants. These facilities contain a variety of software operating systems and hardware platforms. OOP’s inherent flexibility would allow the engineer to create a base program that easily could be modified for each platform.

OOP also excels when equipment or processes need to be connected in unforeseen ways. Each module can be written to control a particular process, and then be linked as needed.

Building with modular, connectable software blocks lets engineers swap out only the required modules if and when a process changes. Existing blocks from old projects also can be used to program new projects faster.

If a module is structured correctly the first time, it becomes a permanent solution that can be used again and again. If mistakes are found in a module or if a module is improved, it’s a simple task to update the module in all of the programs where it exists.

OOP for GUIs
Deseret Labs develops GUIs using Microsoft’s MFC. MFC is a set of classes (or a library) designed to implement GUIs. It’s provided with Microsoft’s Visual C++. MFC includes text editors, buttons, and other GUI elements. Such libraries often are contained in programming language software packages. Microsoft refers to GUI elements contained in MFC as controls and ActiveX controls. These elements are user-interactive object entities that a user can click on to simulate operation of a knob, button, or dial.

Consequently, when creating GUIs, it’s important to manage the position, size, and other attributes of all its elements using the same routines. Otherwise, separate routines must be written to manage each GUI element. The OOP inheritance scheme is perfect for this task.

With Visual C++, GUI elements are derived from (children of) CWindow. CWindow (part of the MFC library) is a core window functionality class that contains the generic position, sizing and other functionalities inherited by nearly all of the MFC classes. The chart below diagrams the inheritance linage of a simplified GUI class hierarchy.




GUIs generally operate with event-oriented programming. This means there is a never-ending loop that scans the system for events such as a mouse click or a key stroke. The loop then hands off information about the events (as well as CPU control) to event recipients.

With Visual Basic (VB), if one object receives the CPU control from the event loop and doesn’t give it back, the entire application freezes. With VB, it also is possible for a particular window to grab the event loop for itself, and stop the rest of the application. VB.NET and other OOP languages, such as Visual C++, also can solve this event loop problem.

With Visual C++, the event loop/GUI architecture is thread-safe. A thread is a collection of code, like an event loop, that executes simultaneously with other threads. More precisely, a thread is a collection of data managed by the operating system.

The operating system examines data as it schedules tasks for CPU time. The operating system will set up the CPU, begin executing code, stop, and come back later to do more.

Because separate threads access the same data space, they can trip over each other by trying to change the same data simultaneously. Avoiding this mishap requires synchronization, which means that threads will block each other from simultaneously accessing resources. Once synchronized code is made thread-safe, it can tolerate multiple simultaneous threads without crashing.

As a result, Visual C++ programs can operate multiple GUI windows without blocking each other, and do so while effortlessly managing I/O access at the same time. The cost for these advantages is elevated programming effort required by OOP in general and C++ in particular.

Control Algorithms
Control algorithms can be programmed easily as objects with OOP. Keeping algorithms generic is a key concept, because generic control algorithms are reusable, whereas specific algorithms are not.

Many OOP libraries support advanced control concepts such as fuzzy logic and neural networks. Fuzzy logic algorithms can be very good for managing extreme complexity. Neural networks are prized for their ability to learn what to do with just a few training examples. Fuzzy-neural systems combine the two.

Finite-state machines are a common example of OOP control algorithms. If a process machine has several different behaviors, rather than just one, a finite-state machine keeps track of which behavior is presently running with a state variable. Example states might be drying, stirring, and heating.

Events such as a button push or reaching an end-point can trigger a change of state. When the state changes, different code executes and the machinery behaves differently. Finite state machines are very debuggable, easy to validate, inherently well organized and stable.


  About the Author
Matt Scott is engineering team leader for Desert Laboratories in St. George, Utah. He holds a composite masters degree in technical computer science/physics from Humboldt University of Berlin, and can be reached at matts@deseretlabs.com.
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments