How to Build a PC-based Control System
PC-based control can be one of those subjects not to be discussed at dinner parties, ranking right up there with politics and religion. Many companies have emerged staking their existence solely upon it, many seeing the control market as "us versus them." The concept is powerful enough, however, to also draw the attention of the large PLC manufacturers—so the "them" are often also "...
PC-based control can be one of those subjects not to be discussed at dinner parties, ranking right up there with politics and religion. Many companies have emerged staking their existence solely upon it, many seeing the control market as “us versus them.” The concept is powerful enough, however, to also draw the attention of the large PLC manufacturers—so the “them” are often also “us!”
There is no doubt that one powerful force driving adoption of this technology is e-commerce. Many companies are staking their future on selling over the Web. This sales model places great demands on manufacturing for real-time information to serve both customer service and production planning masters. Who has this real-time information? Control engineers have it locked up in their controllers. PC and Microsoft Windows technologies for data communication like COM, DCOM, and OPC both feed data to the enterprise and receive production data providing flexible manufacturing.
Ken Spenser, president of Think & Do Software (Ann Arbor, Mich.), says, “The Internet means instant communications. Corporate planning requires integrating control with e-business systems. This is the power of PC-based control with Microsoft Windows DNA [Distributed interNet Architecture] technologies. It’s not just a PLC replacement but something that adds significant value to the business.”
Jess Bowling, director of MES manufacturing services for Phoenix Contact (Harrisburg, Pa.) integrator Hughes Automation (Graham, N.C.), weighs in with a view from an integrator. “I have noticed a subtle refocus from a controls architecture to facilitate process automation to a process automation architecture to support data automation. The transition is driven mainly by expectations of production and business managers. Control system design must now support data availability supporting the business model.”
Build a system
It is best to consider PC-based control as a system. Unlike PLCs that usually come packaged or in a rack with plug-in modules, PC control is inherently distributed. Parts of the system include a PC, software control engine, programming software, data communications software, communications cards, I/O device network, and I/O modules.
Before considering individual components, the first thing to do is to consider implementation of that first PC-based control system as a typical engineering project. That means, first defining the scope of the project. The beauty of this type of control lies in its ability to add new features. The devil lurking is the ability to add new features.
Julien Chouinard, president of AlterSys (Longueuil, Quebec, Canada), has been installing PC-based control since 1984. He points out, “The biggest mistake is to start a project having something in mind, but then ending up saying, ‘While we’re at this, why don’t we…?’ Don’t try to grow the system while you’re building the first one. Do small chunks at a time. Please do the first project with reasonable scope, then go to the next step.”
Mr. Chouinard says that implementation should be approached as a software project. PCs allow more communications, calculations, reports, and work with other systems. Develop strict procedures to handle this internetworking. A parting piece of advice, “Using open control doesn’t mean using cheap equipment. Select hardware and I/O devices as carefully as you would any PLC project. Look at power surges and environmental conditions. Don’t use TTL signals and lab equipment in an industrial application. You’re not just replacing a PLC, but you can now do more with the system. Make sure the technology you implement is something you can handle.”
MDSI (Ann Arbor, Mich.) has gathered experience through many projects retrofitting PC-based CNC on older machine tools. Product engineer, Bob McGinnis, segments the plan into three major parts: machine specifications and project planning; electro-mechanical integration; and, software development and installation.
“Define the servo system and mechanical configuration first,” says Mr. McGinnis. “Then define control hardware requirements. This entails PC selection, I/O specification, operator station design, and electrical component requirements. Finally, identify software requirements. Define soft logic, user interface, and configuration files.”
Six step program
David Gee, vice president technical marketing at Steeplechase Software (Ann Arbor, Mich.), contends, “A PC-based control project is still a project. We recommend six steps to follow to successfully implement a system. First understand the operational sequence through a process narrative and process flow diagrams. Next develop functional descriptions always including a diagnostic strategy. This is followed by installation design and then developing the control program. Next test and debug the system, and finally, revise, and optimize.”
Important design steps, according to Mr. Gee, include specifying the I/O subsystem, assuring the correct solution for the machine’s needs. Identifying main machine activities become top-level flow charts for the programming effort. Reusable subprograms are derived from identification of common control activities. Figure out what things can go wrong to develop exception conditions in the program. Finally, identify what the operator will do to guide HMI development.
Some people choose PC-based control because it is an “open” architecture. Many suppliers develop for this platform offering choices to the system designer. Larry Ricci, industrial platform business unit director at GE Fanuc Automation (Melrose Park, Ill.), cautions, “Carefully examine the linkages among control, HMI, and communication software and controller and I/O device hardware. We still do not have universal plug and play. Make sure the PC platform supports the chosen operating system.”
Take advantage of all the choices suggests Bruce Fuller, GE Fanuc Automation (Charlottesville, Va.) control software products unit manager. “Explore various control options. While Windows NT is great for most applications, users may want to look at real-time extensions like VenturCom’s RTX for some critical applications. Windows CE is another option to consider for its small footprint and price.”
Sometimes different vendors will provide pieces of the system. In this case, adds Mr. Fuller, “Understand who’s responsible for the system. Purchasing the entire system as a bundled solution from one vendor prevents potential finger pointing of a multi-vendor system. Another point is to evaluate and test all devices before implementation. This will save hours and dollars at start up. If something goes wrong, have a disaster recovery plan.”
All PCs not alike
The image often called to mind at the mention of PC-based control is that of a desktop “white box” PC sitting in the factory with a bunch of wires hanging out the back. Actually, PCs come in many shapes, sizes, and environmental ratings. Venture Development Corp. (Natick, Mass.) research reported in “Market Update” in this issue reveals 70% of PCs used in industrial automation are ruggedized for the factory environment. Development of small form factors for use as “Internet appliances” will spill over into control appliances in the not-so-distant future.
Ryan McDonald, industrial automation product manager at National Instruments (Austin, Tex.), suggests evaluating speed and safety requirements of the application then deciding where the control should reside. Perhaps it will be in a Windows NT standard box, or perhaps a CompactPCI industrial computer or a small, distributed Windows CE controller. Safety or other similar situations may require a real-time operating system (RTOS) reducing risk of inadvertent OS shut downs.
Another item to watch for when procuring PC hardware is the processor chip. Aldo Marcuzzi, Nematron (Ann Arbor, Mich.) software manager, points out that Intel has an embedded chip roadmap. This guide details product progression and maintenance over a period of years. “Don’t just go for the latest Pxx chip,” he adds. “It will be obsolete in three months, and you will be facing potential upgrade problems.”
Michael Griffin, a user engineer from London, Ontario, Canada, reports several years of experience with PCs in manufacturing have produced problems only with hard disk drives and power supplies. He recommends buying a PC with ready access to these components for easy repair.
Mr. Griffin has been unable to determine cause of power supply failures. In lieu of a hard disk, many manufacturers now supply flash memory, but this solution is not without problems.
Joseph Rubino, Cutler-Hammer (Westerville, O.) application engineer, offers several hardware items to be considered in system design. Consider the working environment by specifying the appropriate NEMA ratings for equipment. Since memory is often more important for system speed than CPU, and it is impossible to keep pace with processor advancements, buy the most memory and hard drive the project will afford. Assess serial port capacity for the application. If values in memory are to be retained after a power cycle, battery-backed RAM may be needed.
Additional hardware considerations include power source and surge protection. Look at power line noise and usage to determine if an isolated or dedicated power feed is required. Power lines are often checked for voltage surges and transients, but Mr. Rubino reminds users to also ex-amine telephone, coaxial, serial, and other communications.
Don’t scrimp on RAM
Rick Hudson is general manager of information systems for Emco (Charlotte, N.C.). The company is a system integrator using VMIC (Huntsville, Ala.) products. He says, “Especially if you’re working with Windows NT, don’t scrimp on RAM. In our experience, if you minimize the amount of memory, it eliminates any advantage you had with processor speed. Another thief of CPU time is reliance on serial communications. If you use a fieldbus, the add-in card takes over network processing, which frees up some CPU time.”
Another consideration regarding memory overhead, according to Mr. Hudson, is using OPC. Some applications required him to go around OPC due to memory constraints. The ability to use custom C-programmable programming blocks helps this situation. A system speed consideration is type of fieldbus I/O devices. Dave Rohn, Rockwell Automation (Mayfield Heights, O.) product development manager, notes several hardware issues. “Make sure to control which drivers you load in your system. Ensure that only a vendor-approved driver for the specific card is used. A mismatch can have bizarre consequences. A guard against hard-drive failure is a RAID (Redundant Array of Inexpensive Disks). RAID can be set up to provide for near seamless change-over in the event of one drive failure.”
Addressing software issues, Mr. Rohn remarks, “When considering which OS to use, remember that a vast pool of talent familiar with Windows NT already exists. Consider programming languages that are already known for faster development. Source code control cannot be overstressed. Build early and build often. Qualify each build with a ‘smoke test’ and run weekly regression from the first day a software engineer shows a prototype.”
Omron Electronics’ (Schaumburg, Ill.) industrial automation marketing manager, Dave Quebbemann suggests evaluating the software’s online debugging capabilities. “You also need to address programming languages. Do you want ladder diagram or another language? Can you program in sections and then merge? Can the software handle different fieldbus systems at the same time? Is the software OPC compliant?”
Connect to outside world
Gary Marchuk, Think & Do Software product manager, cites as a key element for successfully building a PC-based control system the ease of integration of the I/O or intelligent network. “Nearly all bus systems,” he adds, “build intelligence into the device or sensor to provide information like diagnostics, statistics, safety, and/or maintenance information. Evaluate your software candidates for capability to control this aspect of the system.”
The I/O network is the nervous system of PC-based control. It connects the brain to the outside world through sensory inputs and activating outputs. Not to consider all the ramifications of this element of the system will lead to unpleasant situations.
Siemens Energy & Automation (Alpharetta, Ga.) product marketing manager, Matthias Hoffmann, says, “Together with the benefits of open operating systems and combining PLC and HMI functions, users should also select open networks for information and control. Since many PC-based control systems are used in critical applications, be sure that chosen networks contribute to system performance by providing necessary bandwidth. The network should be able to bring field I/O devices into a safe, predefined state. Also evaluate ease of configuration, set up, and cabling.
“The choice of Network Interface Card should be considered carefully. An on-board processor decreases host CPU loading. Data Consistency assures data received is from one scan of the bus, not a dangerous combination of two scans.”
Three flavors of a system
Use PC-based control to brew beer? New Belgium Brewery (Ft. Collins, Colo.) does just that with a system from Opto 22 (Temecula, Calif.). Senior control systems engineer, Igor Valuyev, has studied the various flavors of this system to find the best one for his applications.
He states, “There are three flavors of PC-based control. The first, and most known, runs 100% on the operating system, usually Windows NT, and is suitable for applications that don’t require high availability. One step above that is still 100% PC control in the sense that it is running on the Intel chip, but the operating system runs on a real-time kernel like InTime or RTX. The third flavor entails putting the control on a PC card. This yields benefits of real-time control while using the database, communications, and HMI capability of the PC.
“The cost generally rises with each flavor, but reliability may be an overriding concern. When you choose the platform, weigh these issues, plus the bus you plan to use before deciding.”
Schneider Electric’s (North Andover, Mass.) response to PCs is to do just this third flavor. If the operating system or even computer power go down, the control engine will still run. This gives comfort to those who are still not ready to trust the operating system.
Another company promoting a hybrid solution for those who are not yet ready for full PC control is CTC Parker (Milford, O.).
While the FUD Factor (Fear, Uncertainty, and Doubt) still exists, especially swirling around the operating system, there is no doubt that many successful PC-based control systems just perkalong keeping manufacturing running. If the analyses of current business trends are correct, more engineers will be putting these tips to the acid test of design and implementation.
When to use an integrator for PC-based control system
The good thing about PC-based control is that users can shop around filling the shopping cart with the best computer, operating system, programming and control software, networking, and I/O devices to fit the application. The bad thing can be that very same thing. Unless a bundled solution is purchased, someone has to put it all together.
Scott McCrary, president of Cimetrix (Salt Lake City, Ut.) integrator Advanced Automation (Greenville, S.C.), offers these suggestions to those who don’t feel comfortable going it alone:
Educate yourself and the organization about this system, and don’t undertake it until all are convinced of the benefits;
Don’t expect the integrator to organize debate within the organization, and don’t start a big integrator project without management commitment;
Involve the IT community within your organization;
Leverage the integrator’s experience—perhaps you can do future implementations;
Ask integrators about their experiences in hardware, software, standards, implementation and training;
Specify standards that must be adhered to; and,
Expect to separate, to the degree possible, the choice of integrator from choice of system components.