Visual Programming for Automation
Graphical programming methods have been around the manufacturing, automation, and instrumentation space for a long time. Software tools—ranging from National Instruments’ LabView to The MathWorks Simulink and including many proprietary PLC and DCS programming tools—are nothing like textual languages such as Cobol or C. But graphical programming (also called “visual programming”) has significant benefits, and is quite common for creating automation and manufacturing IT systems.
Visual programming involves a graphical palette upon which a programmer creates, arranges, and connects images that represent various programming concepts. Once the visual representation is complete, the diagram can be translated or compiled into a standard executable program, or it can be executed directly.
Christian Fritz, National Instruments product manager for motion control and mechatronics, says “Graphical tools are ideal for describing and programming complex automation systems. From the machine level up to the production line or manufacturing execution system (MES) layer, modern systems combine parallel, sequential, iterational, and diactric tasks that make it hard to use text-based sequential programming for application development.”
Dennis Brandl, president of BR&L Consulting, says visual programming is “a formalization of things we do in workflows and process flows. We’ve been doing it for a long time [in manufacturing IT environments] and other industries are just catching up.”
In a paper on visual programming in Labautopedia, an online information resource, Mark F. Russo says, “Many a non-programmer can attest to the surprising level of frustration associated with an attempt to “get right” the arcane syntactical detail often demanded by a text-based programming language. The problem of exposing the functionality of a complex system so that it is usable by a non-programmer is the subject of much ongoing research.”
Three ‘flows’ represented
Visual programming tools vary and Russo says the concepts underlying them can vary too. He puts the potential “flows“ expressed by a visual programming language or toolkit into three categories: flow of data, flow of material, and flow of control.
Textual languages focus on the manipulation of program data, thereby keeping the flow of data itself hidden from view. “In contrast, a data flow programming model makes data the primary focal point upon which its programs are assembled. Operations that occur become side effects of the flow of data through the program,” Russo explains.
NI’s Fritz says NI LabView is “a data-flow based graphical system design tool that offers a high-level of abstraction and an extensive library of functions for I/O, analysis, data-logging and control for machine control and monitoring applications.”
Flow of material focuses on raw materials and newly produced materials in a process. Material flow is not important to general purpose visual programming tools, but it can be very important to tools geared for the laboratory or process industries.
Russo says flow-of-control style visual tools are “much more comparable to standard imperative programming than data or material flow tools.” The most common tool in this group is the flowchart. Other ways to visually represent the control of flow are statecharts and activity diagrams, both part of the larger set of diagrams that make up the Unified Modeling Language (UML) standard, he says.
Brandl says another visual programming option is the Petri net, a visual modeling method which is both a graphical and mathematical formalism of workflows and processes. Petri nets have been used for years to model and simulate the behavior of diverse complex systems, especially those that display concurrent behavior, as they form the basis of certain tools. Petri nets have been used extensively in automated manufacturing and to develop manufacturing execution systems. He says Simatic IT, Siemens’ software for manufacturing operations management, is based on the Petri net concept.
Higher level modeling and simulation tools are another class of visual software. Tony Lennon, industrial automation and machinery industry manager at The MathWorks, says that although Simulink can concisely represent both your plant model and the controller logic in a single graphical canvas, as well as perform other tasks, it does so without the use of Petri nets.
“Simulink provides not only for simulation and early verification and validation, but also automatic code-generation targeting C, HDL, and IEC-61131 structured text,” says Lennon. “Petri nets give you a very abstract and generalized way of representing concurrency and process flow. However, they are far too abstract to represent dynamical systems and supervisory logic.”
Lennon’s analogy: “Imagine building the whole world using one atom at a time, no molecules and nothing bigger to work with. In contrast, Simulink provides a graphical platform for dynamic system simulation and various high level blocks, subsystems and even domains such as Stateflow. Stateflow supports the use of hierarchical finite state machines, truth tables, and flow graphs. The semantics of Stateflow are deterministic in nature, enabling the modeler to define logical algorithms in a clear and consistent way.”
Simulink and Stateflow are control flow (or signal flow) based software, says Lennon. Stateflow offers state machine capability like UML, but also integrates truth tables, flow graphs, and continuous systems through Simulink. Stateflow semantics are deterministic because the user defines the order of processing the system states, he says.
Bridget Fitzpatrick, the practice lead for HMI at Mustang Engineering, says interfaces similar to the Petri net symbology are increasingly common. “Done well, they can make the current condition of the process work flow quite clear. Done cryptically, they can be a hurdle to acceptance,” she says. “Some purely sequential flows have been done in a GANTT chart format, similar to Microsoft Project or calendars in Microsoft Outlook. These can be useful and intuitive if done well, and overwhelmingly complex if done poorly.”
William “Bill” Gilbert, industry business development manager for Siemens Industry, is the prime contact for converting industry application engineering at Siemens. He says that when programming and monitoring an application that is a process, he prefers graphical languages. “The main benefits are the unique ability to graphically communicate process flow, and [the ability to] provide documentation of the program from the engineering effort,” he says.
All languages have their place, says Gilbert, and the use of a specific language must fit the application: “Regarding ladder logic, no language can better take discrete logic in the form of inputs and set output bits. Sequential function charts suit programming for a machine that follows or runs a sequence. Graphical programming languages are best suited to programming a process-oriented application. Controllers that cover a wide range of applications will offer multiple languages.”
|Renee Robbins is senior editor for Control Engineering. Reach her at firstname.lastname@example.org .|
Visual programming: an HMI programmer’s perspective
Bridget Fitzpatrick is the practice lead for HMI and abnormal condition management at Mustang Engineering. Mustang has a very broad base of experience with sophisticated HMI tools, in recent years routinely generating 5,000-10,000 operating displays annually. “We tend to use the native platform tools where possible, rather than starting with a custom application that only interfaces independently to the control layer,” she says.
Mustang uses dedicated software to draw in Microsoft Visio and convert its drawings to control interfaces, although that is not the most common process. “Basically, the new open system HMIs create a new generation of interfaces and possibilities,” she says. “Moving data around the system is much simpler in many cases.”
Regarding the graphical drag-and-drop and connection methods of modern open systems control languages, “the main benefits are the apparent ease of use and the relative ease of troubleshooting. Copying and cloning for a new similar application tends to be much easier as well,” she says. “On larger scale projects, we tend to make one template for each major type of control and then sort out a method for bulk importing or bulk building.”
As for drawbacks, “in reality, the purely graphical methods tend to look easy, but there can be pitfalls hidden from clear view, layered in dialog boxes that may not be entirely intuitive. At times, there can also be issues where data can be read in and out in only limited formats, which may not be intuitive to less technical users. Error messaging can also be a bit cryptic and less precise than formally coded applications.”
Fitzpatrick says, “At times, graphical programming is clearly the best way; at other times, it’s a bit too simplistic to manage effectively. If too complicated, alternate means of troubleshooting and operator presentation are required.”