Support-focused enterprise controls series
An article in the September 2014 issue of Control Engineering reported the origins of the first programmable logic controller (PLC). It described a race to produce a PC-based or special logic controller to enable control system applications. The proponents of the special controller envisioned how the design would replace relay-based control systems with a PLC. The article went on to describe how PLCs would improve machine diagnostics, decrease panel space, and reduce maintenance costs. Examining the state of PLC designs today, it is obvious that they have only partially achieved their originally intended goal. It is true that PLCs have enabled designers to provide better diagnostics while allowing them to decrease the size of control panels. From a maintenance perspective, PLCs have replaced many hardwired relay circuits that used large panel-mounted relays with controller-based logic circuits.
Since the development of PLCs, manufacturers have shed the use of relay-based control systems, reaping the panel space and diagnostic benefits. However, manufacturers have not realized significant maintenance savings costs. This is a result of machine suppliers providing chaotic PLC applications that offset the maintenance costs by increasing support costs. The cost increase is directly associated with how PLCs make it possible to increase the sophistication and flexibility of automated machines. As a result, there is an increased need for technicians to support many uniquely formatted PLC applications coming from various machine suppliers and system integrators. Each application is customized to fit the perceived needs of each machine. Unlike simple relay-controlled machines that have a small number of circuits, new PLC applications have thousands of custom logic circuits. These circuits must be understood before technicians can safely change them to support the manufacturing process. Understanding the many different circuits becomes the maintenance-related support problem. The problem surfaces when technicians are pressured to quickly identify device failures or make repairs, or the logic changes before restoring a machine to an operational state. The cost of production delays increases maintenance-related support costs.
Another indication of the maintenance-related support problem comes from the ongoing debate about whether control systems should be PC-based or PLC-based applications. PC-based advocates argue that computer environments help designers to produce structured applications that are easier to support, whereas those wanting PLC-based controls explain why logic circuits are needed to support the agile nature of flexible machines. Both sides have valid points. So what is the answer? There are PC-based designs running in industry today. However, under close examination these applications function in support of machines that have rigid sequences. Therefore, the answer is likely a hybrid solution where a PC-based application enables a standard design and the operational support of PLC-based logic circuits. It is not hard to understand that the current development methods are expensive to execute and the finished products are difficult for technicians to support. Furthermore, it is hard to imagine that the design process used in the 20th century to produce, debug, and reproduce logic circuits will continue indefinitely into the future.
In the future it is not hard to envision a support-focused enterprise controls software product that will provide users with an interactive interface to a machine’s PLC program. As an alternative to simply showing technicians enabled circuits, this new product will provide technicians display screens that will show the physical movements of objects and mechanisms. Instead of just enabling designers to make changes directly to circuits, the product will also allow technicians to change the properties of displayed objects that will cause automatic logic circuit changes. The product will enable manufacturers to control the important electromechanical elements of machines. The interactive software will allow for systematic, rule-based construction of logic. Because the construction rules are interactively documented, technicians will not get confused when they examine various rung constructs produced by different designers.
The product will enable manufacturers to control and a designer to import the cornerstone circuits that act as the foundation for all station-specific logic. A solid foundation enables a standard way to have all designers incrementally develop the standard logic that controls the movement of objects and mechanisms. The design process will follow a structured set of rules used to construct logic. The development tool will also allow designers and technicians to configure and reconfigure shift-register applications. The development tool will allow for the insertion and sequenced activation of custom-made logic templates. These templates will conform to standard interlock signals associated with control logic and data elements residing in shift-register applications.
For a support-focused enterprise control system to be widely accepted, it must force designers to shed many of the bad programming practices found in today’s applications. These bad practices are typically associated with shortcuts designers take to replicate their designs. Some of the practices have been unknowingly enabled by PLC manufacturers that equip controllers with advanced features. The misuse of these features is just one of many reasons designs go off in chaotic directions. Other aspect are related to logic styles preferred by different designers. The misused features and erroneous styles only act to conflict with a support-focused design. This is mostly a result of support personnel not understanding the reason for various rung constructs to enable similar tasks. The basic logic design premise targets technicians understanding logic over original equipment manufacturer (OEM) designers providing logic based on quick replication and configuration processes.
During the early years of PLCs, a controls design team developed a matrix-based program that was able to self-generate Boolean equations. The team worked for a Boston-based software company that developed a Boolean development tool for Allen-Bradley. Using the Boolean development software, the designers were tasked to produce PLC logic for large, multistation welding machines used in the automotive industry. The control system designs for these machines included the following types of applications.
- Event-based application: a software program that uses a specific event to launch a logical series of examinable steps that either pass or fail.
- State-based application: a software program that examines many discrete variables to identify the physical state of mechanisms before enabling movement.
The control system programs for these multistation machines included both event- and state-based applications. The event-based applications were simple circuits used to move data, and latch and unlatch Boolean signals. The state-based applications sequentially enabled outputs to control a set of machine mechanisms. Each machine state is a set of examinable signals that are in a known pattern before the mechanism moves. The idea was to divide the machine’s mechanisms into sequential motion groups. These were the mechanisms that sequentially cycled together, asynchronously from other machine mechanisms.
The design process included constructing a matrix for each motion group. The matrix had columns to represent a mechanism’s movement, and rows to represent the state of sensors and interlocks from other sequential motion groups. The top row of boxes contained special codes, output addresses, and movement description information. Similarly, the first column of boxes contained sensor address and description information. Each box in the heart of the matrix contained a number. A zero meant it was off and stayed off when the mechanism moved. Similarly, the number one meant it was on. The matrix application used the number transitions in adjacent columns to determine which inputs were expected to change state when a mechanism moved. The process also allowed designers to place a dash character in a box normally containing a number. The dash represented a don’t-care state for the designated signal for the column-defined motion. The next part of the design process was the execution of a Fortran program to evaluate the matrix. The output of the program was a set of tag-based Boolean equations for each column-referenced motion and a tag-referenced address and description list. The output equations and tags were compatible with the Boolean development tool that when executed converted the equation and tag files to a PLC-downloadable logic file and printout with annotated documentation for each signal-addressed variable.
Figure 1 shows two logic circuits in PLC ladder and Boolean equations. Overall, the matrix-based development process supported by the Boolean development software was only able to produce 70% of the logic needed to enable a machine. Although the Boolean process was an efficient way to develop PLC programs, it never gained any acceptance in the industry. Machine suppliers most likely viewed the process as risky, and it added an extra design step, thus forcing them to train their controls engineers. The matrix and Boolean development tool had no tangible value to manufacturers, as it only streamlined designs and did nothing to improve the operational support of machines.
In the early 1990s, the control engineering department at General Motors Truck and Bus Group was developing new logic standards. The controls team worked on logic standards, and they enhanced the matrix idea by replacing it with a sequence chart development process. Since sequence charts were part of the normal design process, the chart-based interface was a logical improvement. The concept progressed to the point where GM had a functioning PC-based application that could auto-generate PLC logic. The development tool was considered a working prototype when GM pulled the financial plug on all special projects, as to allow the company to move financial resources to an electric-car program. One of the non-controls team members who was integral to translating controls information and defining how the prototype needed to work was disappointed that the project was terminated. As a result, he asked for and received permission from GM to leave the company and take the functioning prototype to Rockwell. Although some on the team were declaring success, the prototype could only generate 80% of the needed PLC logic. Some believed that the remaining 20% would come via some unknown set of rules and methods. More than a decade later, Rockwell developed an enterprise software product that was later sold off. At least one member of the team suspected the Rockwell product was an extension of the team’s original work.
In the mid-1990s, Chrysler Corporation assembled a design team to develop a plantwide vehicle tracking system. Team members used single event-based circuits that detected objects moving between tracked positions. The circuit design was similar to the PLC logic circuits used to move shift-register data. Each position-specific circuit generated an "index" signal used to trigger the PLC to send a "from-to" message to the tracking system. Each circuit detected the vehicle or the vehicle’s carrier at one position before generating a trigger to indicate it had moved toward the next tracked position. Since the tracking system needed to track objects moving through the entire plant, the design team configured circuits for hundreds of control points throughout the manufacturing process. The significance of these single-purposed circuits would not become evident until years later.
Why no solution?
Why hasn’t anyone studied controls and subsequently developed a PC-based PLC support product? Is it because most designers focus on PLC technology? Perhaps it is because many engineers entering the controls field are expected to work alone, replicating designs developed by others or upgrading existing designs. It is very possible that many controls engineers are either experienced with state- or event-based PLC applications. It is important to understand the differing views controls engineering consultants have based on their occupational experiences. Most engineers are occupationally biased and fall into one of the following expert categories:
- Start-up expert: a person who is responsible for making a machine, conveyor, and all associated applications work in the field.
- Controller expert: a person who works for a specific industrial automation controller manufacturer as a hardware and/or application engineer.
- Controls expert: a person who works for a machine or conveyor supplier as a controls engineer.
- Plant expert: a person who works for a manufacturer as an automation engineer in support of plant-specific manufacturing processes.
Many start-up experts do not have engineering degrees but have a wealth of controls-related field experience. Start-up experts usually are technicians who began their careers wiring electrical panels and/or are involved with wiring machine devices. Some start out as robot programmers or AutoCad detailers. Over time, start-up experts are responsible for making machines, conveyors, and/or applications designed by controls and/or controller experts ready for production. Start-up experts are responsible for debugging electromechanical devices, special equipment interfaces, and controller applications. In particular, they are responsible for making sure the safety devices that protect personnel from processes are wired and operating properly. Start-up experts are the hands-on technicians who work with machines or conveyors when suppliers erect them at a build shop or install them at the manufacturer’s facility. Start-up experts usually travel with machines and conveyors for long periods of time. When a start-up expert discovers a design issue, he or she must collaborate with controls and controller experts before permanently applying any hardware or software fix. The experts’ targeted role in manufacturing forces them to look at other people’s designs on the same type of machines or conveyors, thus minimizing their ability to see the common design denominators needed to define the operational scope of a new PC-based support tool.
Controller experts are graduate engineers specially trained regarding the details of controller features. They are also specialists at connecting controllers to networks, adapting interface hardware, and developing sophisticated controller applications. As a result, controller experts are more likely to trust technology and accept system-related solutions based on how they expect them to work under regular conditions. Many controller experts have only a station-level understanding of how machine and conveyor control processes work. Their targeted role prevents them from seeing the low-level picture of the features common to all control applications.
Controls experts are graduate engineers and specialize in adapting various controllers from many different industrial controller companies to machines, conveyors, or processes. In other words, controls experts are responsible for adding controls to mechanical processes to enable their operation. They do this by providing the hydraulic, pneumatic, and electrical circuits needed to make objects and mechanisms move. Although mechanical engineers select most sensors, controls experts are responsible for the designs that govern the wiring sensors, valves, and relays to controllers. Controls experts are also responsible for developing the logic circuits used to examine controller inputs before enabling controller outputs. Most controls experts consult with controller experts before making high-level hardware- and software-related design decisions.
Most discrete part manufacturers do not recognize the differences between controls and start-up experts. Both types of experts work on machines or conveyors but during different phases of a project. Most manufacturers assume they all have the same backgrounds and classify them based on the type of equipment they work on. This leads to the recognition that machine controls experts understand mechanical station and robotic processes, whereas conveyor controls experts understand how to move product from station to station. Most controls experts strive to make sure new technologies do not negatively affect machine or conveyor processes. This means they evaluate how system designs operate and fail to affect manufacturing processes. For most, their role is limited to a specific type of conveyor or machine process, making it difficult for them to see the common denominator that affects all machines and processes.
Controls and controller experts have different perceptions regarding control system designs. Controls experts are comfortable making changes to their application environment. As a result, they are more likely to recommend integrated solutions. Controller experts are less comfortable making changes to a controlled environment. This means they are more likely to recommend stand-alone, non-integrated solutions. Controls experts also have a discrete sensor or device view of machines and processes, whereas controller experts better understand the application environment and most have a station perspective.
Plant experts are usually graduate engineers and are assigned to change control systems that have been deployed in their manufacturing facility. Most have little design experience outside the need to change and improve existing designs. This prevents them from recognizing the difference between event- and state-based applications. This also limits their understanding of a finite number of plant-specific machines and manufacturing processes.
There are two main reasons controls engineers fail to recognize the common denominator needed to enable a PC-based PLC support application. First, many experts either stay in one job position throughout their career or move up the ladder into management. This limits their exposure to many different designs. Second, control system designers feel they need to stay focused and up-to-date on the sophisticated features of today’s PLCs. As a result, it is difficult for them to identify the common operational details when they are focused on the technical features of new controllers. Together, this means their thinking will not evolve to be able to identify the method described in subsequent articles. As a result, they are not able to recognize, understand, and document the design details needed to define the operational scope of a support-focused control system.
Support-focused controls system overview
All PC-based design tools provide a common approach for modeling manufacturing processes and generating associated control applications. Most use block flow diagrams that define the start, decision, and end points of a process. The actual code structures are usually built into the various execution blocks. This is contrary to the way PLC-based designers produce their programs. Most simply cut-and-paste a previous design to create the next. Many simply visualize the process and then tackle the area of the application that will allow them to quickly generate a high percentage of logic. Until now, there were no rules critical to generating a PLC-based application. To enable others to recognize the rules of a support-focused control application, strategists and/or designers of the tool need to understand the critical steps and components to this new development process. To transfer the necessary knowledge, Control Engineering will publish a series of articles covering the following topics:
- Object detection
- Control system triggers
- PLC basics
- Control logic fundamentals
- Template design strategies
The next article on object detection will describe the ability of a simple circuit to initiate a process and/or trigger another application. Anyone who has taken a PLC-101 controls class knows that state-based control applications need to detect objects arriving, exiting, and/or entering a station. Most class labs have simple drill-motor machines equipped with a sensor to detect an object stopped in position at a drilling station. The need to sense the stationary part before drilling is apparent to most students. Most students also recognize that after the drill cycles, the control application must set a critical variable that is later reset when the part exits the station or when the next part enters. Although this PLC lab example is simple, the class instructor never discussed the critical nature or possible variations to needed object detection circuits. A discussion of detection will enable designers to understand the differences between what the author calls "presence detection" and "movement detection." The proper understanding and application of these circuits will help designers to improve the reliability and the supportability of a control system.
A subsequent article on control systems triggers will describe the many variations of movement detection circuits and their effect on manufacturing processes. Specifically, it describes the details of four common forms of movement detection circuits and provides an overview of the less common forms. The key is not just recognizing how movement detection is used, but also how it is, or can become, the common circuit for regulating and improving all control system designs. This article goes on to describe how movement detection integrates with anti-repeat circuits and how it affects a design’s ability to allow or prevent object collisions.
A future PLC basics article will describe many of the simple elements and characteristics of applied programs. It targets those who are new to PLC programming concepts. It also describes many of the "look-and-feel" issues associated with circuit substitution techniques. Lastly, this article reveals how some PLC manufacturers have equipped PLCs with instructions that when improperly used are detrimental to a support-focused control system.
Later, an article on control logic fundamentals will detail many of the programming concepts critical to developing a support-focused control system. It starts by describing the layers of PLC applications and the common operating modes adapted to suit most machines. It goes on to detail how manufacturers can regulate designs beyond simply providing examples of template standards. This type of regulation guarantees that suppliers will provide the base electromechanical designs needed to ensure more reliable applications. This foundation allows manufacturers to further regulate and improve how applications use standard triggers to set and reset operational variables. With the foundation and triggers in place, this article describes how a support-focused control system models conveyor and machine processes, thus allowing for a systematic generation of, and interaction with, standard logic.
Lastly, an article on template design strategies will describe two common methods used to develop PLC applications that are compatible with a support-focused control system. It goes on to explain how controller experts and controls experts focus on different design goals. One approach assumes only highly trained engineers are expected to interact with logic, while the other suggests keeping designs simple for average, support-focused engineers and technicians.
None of the articles will describe how a support-focused design will improve the operation and supportability of upper-level system designs, while reducing their integration costs. It improves upper-level system designs when controller-based system applications adapt to the more reliable triggering method. This allows control applications to eliminate their reliance on the timed delivery of system information. Instead of time, enhanced trigger designs enable control applications to synchronize moving parts with system-delivered information. A support-focused control system improves supportability when both control and system applications react to the same set of triggers. This eliminates the support issues associated with control applications triggering upper-level system applications in a nonsynchronous fashion.
A support-focused control system reduces integration costs by providing an application environment that standardizes triggers and applications. This means both control and upper-level system applications can be tested and placed into production. This eliminates the time and cost associated with using program emulators, and debug-related deployment delays. Overall, a product of this nature would eliminate the need for system integrators who typically layer controller-based applications while producing redundant or custom trigger circuits to enable upper-level system applications.
In the November 2014 Control Engineering North American print and digital edition, an excerpt of this article appears as a "Technology Update," entitled, "Healing PC and PLC divisions."
Daniel B. Cardinal graduated from Michigan Technological University as an Electrical Engineer. Mr. Cardinal has over thirty years of experience designing control systems and working as a Controls Integrator. In the early 80’s he was a controls supervisor for one of Europe’s largest machine tool suppliers, helping them to establish an operational presence in the United States. Later, he started his own controls company and was a co-owner of Control Systems Associates Inc., a company that specialized in integrated system designs. He is currently working as an engineering consultant for INSYTE Inc. implementing integrated scheduling and part identification applications in the automotive industry.