Graphics Lighten the Programming Load

A picture is worth a thousand words.

Programming can be more than just a chore. For one manufacturer of tobacco products, it was a weight—one that was helping to sink a complex automation project. The machine builder that the company had hired to automate its manual material-handling processes was struggling under the weight of the task, and deadlines were slipping. Management knew that it needed help fast if it was going to recoup its big investment in the facility upgrade.

As it soon discovered, it needed someone who knew how to exploit the latest technology, emerging standards and best practices that most major automation vendors have been building into their products. These graphical tools have been a boon for engineers because they streamline the programming of even the most complex control systems and human-machine interfaces (HMIs).

To reap these benefits, management at the tobacco-products facility turned to Prism Systems Inc., a systems integrator based in Mobile, Ala., and certified by Siemens Industry Inc., of Alpharetta, Ga. “The facility’s system is so big that one PLC [programmable logic controller] can’t control everything,” recalls Alan Stabler, Prism’s lead engineer on the project. “We put more than 20 controllers in the plant, and they all have to act as one integrated, intelligent system.”

Consequently, the facility’s Ethernet network handles a tremendous amount of interprocessor communications. To gain control over them and recoup lost time, a team of the integrator’s engineers deployed new graphical programming tools called iMap, from Siemens, which is based on the vendor’s component-based automation. Facing a four-month deadline on a project that was already months behind schedule, the team needed these tools to squeeze every hour it could from the programming process.

The component-based automation runs on the ProfiNet Ethernet network and is configured with iMap. The deterministic network ensures that data arrive at their destinations. “It alleviates a lot of headaches, including having to write PLC code to handle message delivery failures,” says Stabler.

By exploiting the principles of object-oriented programming, the technology also allows engineers to treat a section of code, an entire machine, or even sections of a factory as function blocks. The HMI, PLC, input/output (I/O) and drives are represented in the block. “To program a system, you just drag in the components and draw a couple of lines to signify the communication between them,” explains Eric Kaczor, product manager for programming software at Siemens.

By eliminating the need to work with the ladder logic, the technology streamlined the once-cumbersome process of establishing communications among the plant’s conveyors, hundreds of trays of work in process, and production machinery. It also permitted several programmers to work on different aspects of the same project. “We were able to put 10 good engineers on the project, get it back on schedule, and then ease back down to a team of three to complete the job,” says Stabler at Prism Systems.

Copy and paste?

Dealing with function blocks also made it possible to develop code for one production machine and duplicate it 75 times for use on identical machines. Not only did duplicating software make programming less prone to error, but it also expedited the development process. Because of this and the other timesaving benefits of component-based programming, Prism was able to rescue the controls portion of the project and deliver it on schedule.

As alluring as the copy-and-replace function may sound, using it for programming controls and HMIs is usually more complex than on a spreadsheet or word processor. Consider an HMI for a project in which several of the same type of generator are connected in parallel or at different locations. A simple replication would connect two screens to the same generator, rather than connecting each screen to a different one.

“The programmer would still need to change each attribute of the new screen in order to be properly aligned with the other generator,” explains Jacob Kimball, HMI product manager, at automation supplier Schneider Electric, in Raleigh, N.C. Even if the PLCs were the same, the tag names will be different—Generator 1 versus Generator 2, for example. Even if the generators were to share the same electrical distribution bus voltage and main fuel tank, as well as the main cooling system, the individual temperature controls and measurements will be unique.

Finding and editing each bit of communication between the copied screens and generators can sometimes take more time than starting from scratch. Tools in the HMI development software often can expedite the process, however. Another aid is importing the information into an office database or spreadsheet program as CSV (comma-separated values) or simple text. “The office program could be used to sort, find and replace the affected attributes or parse, dissect and concatenate strings,” says Kimball. “This file can be re-loaded into the automation software with the changes and put to work quickly.”

Evolution from flowcharts

Many of today’s graphical programming tools are based on flowcharts. “Flowcharts have long been used to organize computer programs, and even before that to describe or illustrate other types of processes,” says Benjamin Orchard, an applications engineer at automation supplier Opto 22, in Temecula, Calif. As flowcharts evolved, automation vendors discovered that even complex industrial control systems could be programmed with a fundamental set of symbols, simply stated command functions and other graphical elements.

Meanwhile, other graphical tools evolved too. Perhaps the most popular are function block diagrams and sequential function charts, both of which are part of the IEC 61131-3 standard promulgated by the Geneva-based International Electrotechnical Commission. “This standard gave focus to programming methods like function blocks and sequential function charts, thereby driving many vendors that just used ladder logic to expand their capabilities,” says Joe Bastone, product manager for Experion controllers and fault-tolerant Ethernet at Phoenix-based vendor Honeywell Process Solutions. “It’s fairly difficult to program a PID (proportional-integral-derivative) loop in ladder logic.” This work is easier to do with function blocks.

The ISA88 batch standard promulgated by the International Society of Automation (ISA), in Research Triangle Park, N.C., also played an important role in the development of graphical programming tools. “It allowed vendors to fit their tools to a standard model, instead of forcing them to develop proprietary models on their own and then develop tools that fit these models,” says Bastone.

Despite the rise of graphical tools, other tools, such as ladder diagrams and structured text—also specified by the standards—continue to find widespread use. Orchard at Opto 22 points out that each kind of programming tool is particularly well-suited to certain tasks. “For example, ladder diagrams work well for simple discrete logic, but analog signals and process control are easier to program and understand using function block diagrams,” he says. “Sequential function charts are effective for writing sequenced control programs, and structured text gives experienced programmers the control and flexibility they need for custom applications.”

For this reason, vendors such as Opto 22 have developed their programming software to give programmers a variety of programming options. Although Opto 22’s PAC Control software, for example, is essentially a flowchart constructed from symbols and graphical elements, it also includes a scripting language, OptoScript, that is similar to structured text. Consequently, programmers can work with it as they would graphical sequential function charts, but switch to a language similar to Visual Basic or C++ when control functions require complex mathematics or string handling.

Having a variety of programming at your disposal can come in handy. At least, that is what St. Louis-based system integrator Malisko Engineering Inc. discovered when it upgraded a thermal processing furnace control system for Advanced Energy Industries Inc., in Fort Collins, Colo.  This manufacturer of gas and liquid flow-management systems and other products for the alternative power industry uses the furnace to fire components before they go into larger systems and machines. It is imperative that the furnace executes the correct thermal profile precisely. Any malfunctions or imprecision can result in faulty components, which can be very costly.

Programming the system was quite demanding because the furnace relied on many custom commands that were developed using the Forth programming language. These external commands could not be imported into the new Opto 22 control system that Malisko put on the furnace, which meant that the comments had to be re-coded or otherwise reproduced. Fortunately, the controller supported a variety of programming tools, including the graphical PAC Control. Malisko was able to examine the external command library and replicate its functionality with equivalent commands that were programmed using a combination of PAC Control flowcharting and OptoScript.

Life beyond programming

Graphical tools have a life beyond the design and programming phases of a project.  Because graphics allow users to see how the different function blocks or other elements of a program fit together, graphical tools are a kind of self documentation that is much easier to comprehend than ladder logic. Most also contain documentation features that experts urge programmers to use as they develop their control strategies.

Such documentation serves a few purposes. Not only do notes embedded in the control modules help programmers to remember later what they had been thinking at the time, but they also help other engineers who come along after them to grasp the control strategy quickly. “The industry is very fluid, and an engineer who is working something today might be in a completely different position a couple of years from now,” says Bastone at Honeywell.

Another benefit of embedding documentation into the program is that operators and maintenance technicians can have access to it, too. “By using the appropriate viewing function, an operator can look at the function blocks as they were laid out by the control engineer during design,” says Bastone.

Some of this work can be done through remote access via personal computer (PC) and the Internet these days. “Remote access to the HMI screens can provide a window for the programmer and the local technician to work through details and make corrections,” says Kimball at Schneider Electric.

Progress in virtual technology is another advancement promising to streamline programming. Because virtualization is the ability to run multiple workstations from one PC, the most obvious benefit is the ability to put more systems onto a server and, therefore, reduces costs. Another is that it lets you test patches before you load them into a PLC or HMI. “If you don’t like what you see, you can roll back to an earlier snapshot of it,” explains Bastone at Honeywell. “So it can greatly reduce the amount of effort that goes into maintaining PCs.” Maintaining the programs is much less of a chore.

Subscribe to Automation World's RSS Feeds for Feature Articles

More in Control