Control Logic Strategies
Control logic options available for automation system design have expanded. When there were fewer alternatives for control logic, the path was clear, but with today's myriad options, where do you start? Consider these facts: Proliferation of microprocessors and related software allow logic to be centralized, decentralized or highly distributed.
This article contains online extras.
Control logic options available for automation system design have expanded. When there were fewer alternatives for control logic, the path was clear, but with today's myriad options, where do you start?
Consider these facts: Proliferation of microprocessors and related software allow logic to be centralized, decentralized or highly distributed. Hardware and software platforms differ widely. Hardware options for resident logic include PLCs, single-board computers, PCs, relays or intelligence onboard various devices such as I/O modules, light curtains, or even an industrial printer. Software choices include the IEC 61131 languages and others. Off-the-shelf designs can be used, or custom engineering may be chosen.
With all these options, at what point in the control engineering design process should these decisions be considered?
System integrators lift the hood on recent projects to explain how to make your next automation project easier to design and more successful to implement.
Scott Shaw, president, Automated Control Systems Inc. (ACSI), says when considering control logic design, those involved need to account for customer standards, staffing and skill levels, training needs for current and proposed technologies and the installed base. Requirements include system load, process data control, cycle control rate, and environmental conditions such as temperature and other elements.
Shaw says that along with environmental considerations, operators' training and familiarity, as well as future project needs should contribute to system design decisions. In flow test systems that ACSI has worked on recently, controls and discrete I/O modules are embedded to deliver measurements in 3-10 milliseconds. In a recently designed manufacturing cell, some controls are distributed and operate in a closed loop because of the speed required for decisions being made. Communications with a central PLC are made as needed. (See sidebar on fine-wire welding.)
Take time to design
Resist the urge to move too quickly from design to implementation. Time invested on the front end of the design process is critical to success, advises Sam Hammond, chief engineer, Innoventor. A thorough understanding of all the requirements and environmental conditions is the starting point for design decisions. Next, identify a workable architecture for the logic and partition the hardware, communications, and software. It is essential that the architecture work within the specified environment. Now, Hammond says, you are ready to develop a prototype and implement the design. Prototypes, revisions, existing hardware, and integration requirements all need to figure into the project plan.
Perhaps the biggest challenge to implementation is interfacing with legacy systems, Hammond says. While a number of technologies, such as Ethernet, are becoming more prevalent in the manufacturing environment, older serial devices are often encountered. These conditions require diverse solutions and programming tools.
Hammond notes that the decision to distribute logic is sometimes mandated by reliability and having a certainty of a positive action to events at a given rate. The line between what an embedded controller can do and what a centralized controller does continues to erode at a rapid pace. This makes deciding where to place the logic more transparent to the user. Future programming software seems likely to recommend where intelligence should reside based on specific application needs, Hammond suggests.
Although distributed and centralized control designs both work fine, says Daniel Parrish, VP of engineering for Tegron, "keeping logic centralized within a single controller can be:
Easier to manage, as code is contained and maintained within a single space. This is the driving force behind integrated automation initiatives by Rockwell Automation and others. Examples of this would be integrating discrete and motion control in the ControlLogix platform, or integrating discrete and process control in the ProcessLogix platform. Entivity's Think & Do promises to integrate control logic and HMI, he says, as do products from Wonderware, a business unit of Invensys, and GE Fanuc. Attempts to combine code bases into a single container enhance maintainability and decrease costs of development and deployment.
Easier to maintain. Having everything in one place enhances maintainability. Distributing the solution can detract from the visibility of the system as a whole and the interactions of subsystems. Industry trends such as outsourced maintenance and high turnover greatly influence the need for a system design that can be easily understood and maintained, he suggests.
Less costly. Centralization also can result in lower costs, but not always, Parrish says.
Moving logic to distributed or embedded controllers also has benefits, Parrish notes. These would include faster decision-making. Decisions pushed to the device or component level can occur dramatically faster than the same decision made in the central controller. Likewise, data required for that decision typically reside at the point of action, but not always. Thinking distributed can improve scalability. Adding control requirements after implementation has reduced impact on the supervisory controller, Parrish says; the addition of logic has no opportunity to cause issues with other existing logic.
Parrish agrees that centralization "makes it easier to find the problem when it's 2 a.m., something goes wrong, and you need to find where the logic is." If controls are distributed, there's a question about what to do with the data—should that also be distributed or be sent to a central repository? Facility guidelines and applications also may determine data requirements.
Shaw cautions, and others agree, that what a customer says is needed for a particular application and what is actually needed can differ. Integrators and consultants might want to explore project requirements, and end-users or OEMs using integrators should consider reviewing specifications to seek another perspective, to see if it better fits the application and those involved with it.
"I like software-based objects," Parrish says. Standard, compact, aggregated ways to represent functions allow higher visibility for the code, letting things be checked, maintained, updated, and reused more easily, saving time and effort, he points out.
All three espoused pragmatism over religious fervor, avoiding debate about PLC vs. PC vs. embedded or any other form of logic, opting for what best fits the application and those running it. Proliferation of PCs may also have encouraged easier-to-use PLC hardware and software design.
Manufacturing cell speeds fine-wire welding
This manufacturing cell fabricates complex initiators for automotive airbags, commercial mining and blasting, and aerospace military explosive bolt injection. The line uses many control platforms to achieve a high-speed manufacturing application, faster than 3 seconds per cycle.
The line has three machines, 27 process and inspection stations, explosive powder dispensing, mechanical press control, machine vision servo control, fine wire welding electrical tests, and laser welding.
Specifications for the machine-vision-guided weld system are:
50 nanometer X-Y stage;
0.0007-in. positional tolerance;
0.0005-in. wire diameter;
3-5 grams wire tension;
0.4 microns weld follow-through measurement;
80 grams weld force; and
7 axes of motion.
Automated Control Systems Inc. did the design and system integration. DVT was used for the vision.
Applicator seals can-package tops
This machine identifies, orients, and applies a top seal to a tea can package. A multi-camera vision system and motor controller are used to detect a feature on the side of the can. A rotary indexer and pneumatic robots are used to move cans through the process.
All control and logic is local with PXI chassis. An independent controller is used to sequence feed of product. Interactions are controlled through sensing of product positioning. Programming tool is National Instruments LabView and Imaq image processing. Hardware includes NI's PXI-1000B General Purpose Chassis, PXI-8175 Embedded Controller (WIN2000), PXI-6527 Qty 3 Isolated Digital I/O, PXI-1409 4 Channel Monochrome Image Acquisition, and PXI-7342 4 Axis Stepper Controller. Innoventor did the design and system integration.
Panel covers logic at NNW
A panel by the same name at the article, “Control Logic: Where Should it Reside?” was held Thursday, Feb. 26, 10-11 a.m., part of the automation track and one of more than 100 sessions at National Manufacturing Week Conference. Panelists were:
—Scott Shaw, president,
—Sam Hammond, chief engineer,
—Daniel Parrish, VP of engineering for
Moderator for the session was Mark T. Hoske, editor in chief, Control Engineering team since 1994, in technology journalism since 1987, and writing and editing since 1982. Areas of coverage in recent years include process control, networks, machine control, and control components.
Parting recommendations from the three system integrators offer common-sense reminders. Hammond says slow down on your project and think things through. “Many decisions you make up front, you’ll have to live with later.” Parrish suggests giving appropriate attention to the maintainability of systems. Shaw adds that automation vendors can add expertise and should be considered part of the control system design team.
Do you have something to add?
Call for papers: Have an idea for a world-class panel or presentation? Please contactMike Critser, planning committee chairperson for next year’s National Manufacturing Week conference; for more information, see also
Logic and advice: a view from an automation vendor
To get some advice from automation manufacturers on control logic, Control Engineering asked a few questions of a few manufacturers expressing interest in participating in this article. Here are responses from Mike Miclot, marketing manager, Logix Controllers, Rockwell Automation, and John Weisenberger, manager of strategic marketing, Distributed I/O Business, Rockwell Automation.
Question: Many automation vendors can provide control logic in more than one form factor. When a customer asks for a certain product and you feel that another type of control device would better fit the application, do you ever try to change the customer's mind? Under what circumstances?
Answer: Sales 101: The first rule is “the customer is always right.” And the second rule is “see rule one.” When a customer asks for a control logic solution, our goal is to assess the customers’ needs without an answer in mind. We ask questions like, “What problem are you trying to solve today?” and “What problems do you anticipate you will need to solve in the next five years?” The customers’ answers help us offer a future-proof solution— a solution that meets immediate needs while simultaneously providing capabilities to meet future needs. On the other hand, if a customer is firmly set on a specific product, most likely they’ve done their homework and have valid reasons for what they want!
Question: Do you see customers migrating from one type of control logic/device to another? What are the reasons for doing so? Are some technologies "winning?" How so?
Answer: It can be said that the 1990's was the decade when Fieldbus technologies enabled the large-scale migration of lower-level control components out of the control cabinet and onto the factory floor. As an extension of this migration, the current decade will most likely go down in automation history as the period when today's centralized control systems began to disappear from the factory automation landscape as well.
Question: What's causing this migratory trend towards the use of more highly distributed control components?
Answer: Users are looking for more than control; they are interested in optimizing processes, asset management and predictive maintenance, all while continuously chasing a more highly customized product. Achieving this optimized, adaptable solution is based on:
The need for lower overall system design, installation and maintenance costs.
The need for acquiring more real-time process data due to new regulatory standards.
The need for higher performance, higher speed, machines, delivering increased operating efficiencies.
The need for more flexible/agile reconfigurable automation systems.
The need for better diagnostic/prognostic capabilities to improve return on manufacturing assets.
The need for safer automation systems capable of tolerating various component failures without injuring a person, damaging a machine or polluting the environment.
All of the above will contribute to the accelerating migration of control logic out of today's centralized control cabinets and into "Smart Components" which will be placed closer to the point where the control is actually taking place. Evidence of this migration can be seen already as an increasing number of smart components (such as process control field instruments/actuators, motor starters, variable frequency drives, pneumatic/hydraulic values, distributed I/O systems, etc.) are all gaining increased adoption rates in both process control and discrete manufacturing applications. When utilized within larger automation systems, these smart components can each operate autonomously providing improved system performance and advanced diagnostic capabilities all packaged in enclosureless designs capable of being distributed right at the point of control.
Question: What does this mean for end-users?
Answer: University and industry studies involving applications using distributed On-Machine components have shown overall installation cost savings of up to 30%. Several Rockwell Automation DeviceLogix Smart Component Technology installations have demonstrated improved system performance and fault tolerance capabilities as well. For example, one pharmaceutical packaging machine OEM was able to achieve a 40% increase in overall machine performance simply by moving some of the centralized PLC control logic into DeviceLogix enabled distributed I/O blocks.
This simple movement of a small portion of the control logic into several distributed smart components increased the machine’s overall performance without necessitating a major change-over to a higher speed centralized controller or a higher speed communication network. This demonstrates that system architecture is often more important to overall system performance than the raw speed of the controller or network. Additional gains in distributed system performance, diagnostic capability, fault tolerance and overall system cost reductions will be made possible by emerging industry standards along with their associated component products and system development software tools.
Question: Other control logic/device migrations?
Answer: Another example of migration from one device to another is the programmable automation controllers (PACs) available today. Users are asking PLC vendors to incorporate more PC-like functionality and features to increase productivity and broaden their use of automation. The result is the PAC, which enables data collection by business systems and multi-discipline control.
Question: What mix of programming do you see? How does that differ from five years ago and/or how will it differ from five years from now?
Answer: A variety of programming languages are available today– including ladder diagram, function block, structured text, and more. Since each language has unique characteristics that address different types of applications, savvy users are employing all languages to best meet their needs. In the future, we expect to see an increased programming focus on segregation, based on the ISA S88 standards. For example, users will make a point to separate recipes from logic from equipment state – helping to permeate changes throughout a system and minimizing the impact to other elements. We also expect users to seek automation systems with memory layouts that allow them to mimic their processes. For example, the ability to group data tags associated with a particular tank or vessel in their process.
Question: Will programming environments or tools unify as the targets for programming continue to diversify?
Answer: In the future, users will continue to see increased unification of programming packages. Using only one programming environment for various aspects of plant-wide control (batch, process, packaging, etc.) simplifies programming and saves time and money by eliminating the need to purchase, learn and troubleshoot multiple programming packages. Furthermore, vendors will provide greater unification of a broader set of tasks associated with design and specification. For example, an itemized list in a bill of materials used for purchasing purposes will be able to also populate a CAD drawing and a controller-programming project. The goal will be for the user to only need to enter the data once, then allow it to be shared across multiple applications serving tangential needs.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.