Up-Front Planning Keeps Automation on Track

Steve Meyer
Contributing Editor

Control-system design is rarely easy. It can be a difficult task even when automating an old, well-understood machine. Troubles stem from the need to make mechanical and electrical design, control-system architecture, and software all form a cohesive, whole solution. It is often the case that one or two of these aspects are much more successful than the others.

Project managers in dozens of applications have found that initially defining the key elements of the overall structure can head off such problems. Among other things, this definition process involves establishing a list of core issues to insure completeness. Moreover, it imposes a structured approach on software development to reduce the incidence of potential ambiguities.

An initial structure, for example, guarantees connections among areas of functionality in the code. Most performance questions can be answered by referring to the functional specification. This approach avoids the usual traps created when software is written in a somewhat random way. Programmers waste no time creating code for functions that overlap.

Finally, an up-front definition process lets more mental energy go toward innovative solutions to the key attributes of system performance. The tendency otherwise is to just generate the initial features and minimum performance requirements that will satisfy the application.

The approach here is somewhat similar to the structured programming approach required in high-level software development. Segmenting the project into appropriate parts makes it easier to develop software as modules, to debug the modules individually, to debug the interaction of modules, and ultimately to complete the work more quickly.

Many control projects naturally divide into three main areas: the power-up sequence, run-time events, and handling faults. Each of these areas, in turn, consist of a few general subtopics that ordinarily vary little from one project to another.

Power up
What happens when the machine is turned on for the first time? The design of the electrical startup sequence covers all typical housekeeping issues, ensuring that power is applied and that control power comes on. This may sound simple but can actually be quite involved.

For example, newer systems may have special issues revolving around the application of energy in the proper sequence to different parts of a complex control system. Typically 24-Vdc logic power must come up first and 110-Vac devices next. Higher-voltage devices are generally powered last. In any event, developers should research such conventions prior to determining the final electrical wiring scheme.

Communications networks, device-level networks, and I/O devices themselves need special attention. Prior to machinery start up, the system must check status switches for the presence or absence of product, air pressure, lubrication or cutting fluids, or other substances potentially left over from the last time the system was on. Certainly, any failure conditions noted during the power-up sequence should be among the fault conditions that keep the system safely unpowered.

In recent years automation has put a premium on machinery uptime. It is now routine to design in ways of reducing setup, teardown, and maintenance. As a consequence, developers are applying technology, such as sensor networks of various kinds, to machine diagnostics.

Thus, part of the power-up sequence in modern systems is devoted to electronic setup and teardown. The information that allows this to happen is, in its most basic form, data about how the machinery should process products of differing sizes or types. Typically, it might consist of part sizes or line speeds, from which stem parts-per-minute or parts-per-hour calculations. Human operators or some other source on the network generally provide this information to the controller. The intent is to minimize or eliminate the hard tooling changes needed for different products.

A simple example might be a machine that can accurately place a label on a cardboard box. Clearly, as the line carrying the boxes speeds up, the labeling fixture must keep pace or it becomes a bottleneck. The controller may need to adjust the line speed if box size varies.

All such parameters must be part of the machinery setup sequence. In this regard, programmers need to ensure there are data registers ready to take the information. Such precautions let the control system implement changes electronically without revising the mechanics or shutting down the machine.

Automation projects that include motion can demand a control-system architecture and programming that are a lot more complicated than might first appear. The most important issues concern accuracy and repeatability of homing. The home point is critical because it is the mechanical reference for axis motion whenever control-system power comes up. Key to accurate homing and repeatable motion is the selection of a sensor with the right properties.

In machine tools, for example, great care goes into supplying what is called a datum, or reference point of great precision. It usually takes the form of a spherical ruby ground to precise tolerances.

Developers should ask themselves several questions about homing. Will homing be necessary every time power cycles on, due to loss of position information? Is it necessary to use absolute position feedback? Can other strategies be applied, such as an uninterruptible power supply for the logic circuits? A UPS normally maintains power to encoder circuits as well, so position information doesn’t go away if the plug is yanked on the rest of the machine.

Born to run
The run-time portion of the control software deals with the operating conditions of the machine. One of the appropriate questions to answer about the run-time code is whether there are times when the machine must be manually operated. What is the backup condition when everything automatic fails? Like backup systems on an airplane, should some systems be backed up mechanically so they can function if the main control system fails?

Jogging functions, indexing discrete parts one at a time, are a semiautomatic operation mode. If the programming environment allows it, manual, semiautomatic, and automatic functions can be programmed with separate enable lines so only one function executes at a time. This conserves program execution time and boosts control-system speed.

Full automatic operation may be subject to speed or other dynamic adjustments. Interestingly, many systems that must work across wide speed ranges do not behave in a linear fashion. There have been many projects where relationships between events in the machine vary slightly depending on speed. Such conditions can be extremely hard to diagnose and usually require analysis with high-speed cameras.

Fault and diagnostic information can be a big subject. As with many design issues, making decisions early in the development cycle pays dividends. Typical issues concern what events have priority and how the control system will handle them. Also defined early are the conditions requiring operator intervention and those that constitute an emergency stop.

An exhaustive diagnostic system is hard to realize in practice. It involves monitoring system performance and behavior over an extended period of time to ensure good fault coverage. This is why designers should think long and hard about how much diagnostic capability a given application really needs. For a single machine installation, it is typically impractical to invest heavily in diagnostic software. But it can be worth the effort in machinery that is manufactured for sale.

Some machine operating conditions can be defined so the control software will make appropriate changes and keep the process running. For example, many motion controllers can correct a motion profile for actual part position by using a sensor to detect the part edge as it enters the machine. In this case, software creates a position offset value for incoming parts. An operator need not enter it manually and an offset condition needn’t stop the process.

Some fault conditions require that an operator acknowledge the trouble before operation can resume. Breaking a light curtain is typically a situation that should stop the machine immediately, but operation can resume when an operator pushes an acknowledgment button. Similarly, jams should stop a machine, but operations can proceed once the operator has dealt with the problem and acknowledged the situation to the control system.

Safe not sorry
Electrical safety in the U.S. is commonly defined as removal of dangerous voltages from control equipment so service can take place without risk of injury. It is important to delineate under what conditions power should go down. For example, is an emergency stop condition one in which power will be removed?

Mechanical safety is often a strategic issue in systems that include motion control because of the potential for human injury. Of all the things that have come from the collaboration with Europe on control standards, this area has been the most productive.

What happens if power is removed from a mechanism that is in motion? In many cases, removing power creates an unsafe condition because motors may coast out of control. So emergency stop and power removal cannot be the same thing.

It may be possible to remove power from a spinning motor so long as there is a fail-safe brake. In high-speed motion, special features in the power circuits can quickly decelerate a motor as part of mechanical safety. Depending on the size of the motor and load, fail-safe brakes and controlled stop circuits can halt high-speed motion in a few milliseconds.