Control programming: Write once, run anywhere with open systems

With industrial controls, it is extremely difficult to design sophisticated programs for process and even discrete control that run on multiple devices, often requiring simplification. Open systems help.

12/18/2011


Today’s programming software, like Opto 22 PAC Control, can be easier to use than traditional ladder logic. When other programming tools are needed, open hardware can accept programming from other software. Courtesy: Opto 22If people write control programs, it would be useful to run them on multiple types of control devices: “Write once and run anywhere.” One of the major hurdles in developing control programs for multiple controllers is that despite the promises of various vendors, closed and proprietary architectures and programming difficulties resulting from attempts to develop for more than one hardware platform or “tier” create serious stumbling blocks in achieving this portability.

The dream has always been that the individual automation vendors would move on from nonportable machine-level code and programming designed to run on only one particular brand or type of their hardware, and offer a way to develop programs that can be used more broadly. While this may work in the IT world, but in the world of industrial controls, it creates a development nightmare for the programmer. It’s extremely difficult to design sophisticated programs for process (and even discrete) control that run on multiple devices. Very often the program will have to be “dumbed down” to the point where it begins to reduce the functionality of the entire application.

Also, debugging might uncover an entirely new set of issues. Something may execute smoothly on one of the targeted devices but not on the other. It then has to be determined whether this is a software problem or a hardware problem. So the programmer may alter the code to correct the problem occurring when the hardware runs on the one device, and it ends up compromising the execution on the other devices. In this regard, it’s very similar to the problems web developers encounter when they have to code pages for multiple web browsers—Internet Explorer, Firefox, Chrome, Safari, etc.

And, of course, attempts to enable portability to many types of controllers can leave the vendor facing serious challenges in terms of having to support many different devices.

Instead of trying to be all things to all programmers, Opto 22 provides one set of programming tools designed to work with a family of Ethernet-based hardware (stand-alone and rack-mounted controllers) to accept control programs. Everything is tightly integrated to work together; there are no tiers; and there’s no concern about the program working only on one type of controller.

But at the same time, if control engineers aren’t comfortable or happy with this approach, and they want to port code to multiple types of host controllers, there’s a solution for that. Instead of using Opto 22’s standard flowchart-based programming software, PAC Control, the programmer can work in C, Java, or other programming language, then use a PC or IPC to communicate with Opto 22 I/O modules. Advantages include using controllers beyond those that Opto 22 offers to execute the program. Using higher-level programming languages (like C and Java) provides the ability to port to plant-floor PCs and IPCs (which naturally have no problem understanding and executing such code).

To facilitate this, the free OptoMMP Toolkit includes drivers and sample code to communicate from a PC directly to Opto 22 I/O interfacing to your field devices. In this way control programmers can develop code (or “write once”) for multiple kinds of controllers—our own PACs, plus PCs and IPCs, and even board-based control.

Some closed architectures wouldn’t allow that option. Opto 22 I/O systems are designed with an open, networked-based, co-processor architecture. A dedicated I/O processor allows it to perform independently of the controller. This creates an ideal scenario for control programmers that want to write their code in C (or some other higher-level programming language), run it on a PC, and communicate to I/O.

NES+L programming

For example, New Enterprise Stone & Lime Co. Inc. (NES+L) operates contracting firms, concrete plants, quarries, and production facilities throughout Pennsylvania and Delaware. Projects completed by the company include PNC Park (home of the Pittsburgh Pirates), the Pennsylvania Turnpike, and Beaver Stadium at Penn State University.

NES+L uses a variety of PC-based control systems and Opto 22 I/O to control equipment used to manufacture concrete, blacktop, cement, asphalt, and other aggregates. Typically, the Opto 22 systems the company uses include an intelligent I/O processor communicating to a PC over an Ethernet network. The PC interfaces to analog and digital I/O modules to control the movement of conveyors used to haul stones into the mix. The PC-based system also controls the opening and closing of hydraulic gates used to release other ingredients into the mix.

But the control software defining these and other process for NES&L is a custom PC-based control application created by NES&L programmers using Visual Basic. And this control application runs on its PC rather than on the Opto 22 controller. NES+L control programs have many options, such as variables and functions for the scores of concrete “recipes” NES+L has to create. These programs often require modification depending on plants’ needs, and NES+L felt it would be easier to make these types of changes with a “home-grown” application rather than with Opto 22 programming tools.

NES+L also wanted to send operations data back to its offices to facilitate expedited billing. This type of data acquisition and communication to software databases is something PC-based systems can do natively. Because of inherent “enterprise connectivity,” the PC-based system was especially attractive. NES+L has been pleased to use an I/O system it needs, without being forced into a dedicated programming package and controller.

Some control hardware vendors require use of their software, which often costs a thousand dollars or more per seat. NES+L programmers avoided those costs by using an open hardware architecture.

- Tom Edwards is senior technical advisor for Opto 22. Edited by Mark T. Hoske, CFE Media, Control Engineering, www.controleng.com.

See control programming articles related to the January 2012 cover story.

www.opto22.com 

www.nesl.com 

http://controleng.com/pac