Motion Control and System Engineering Considerations

Motion control choices are best made in light of the whole system architecture, as the selection of system architecture will drive not only the implementation and integration stages of the project, but also manufacturing and field service, and even the ability to ship and install the final product. We will first review a quick tour of system engineering, and then go on to the motion control specifics.

System Engineering

The essence of system engineering is taming the explosion of the desired and accidental interfaces in the system, thus preventing or at least reducing undesired modes of interaction. This process is done by thoughtful system partitioning, with the careful choice of interfaces, and an eye to robustness, testability, and margins. Unwanted interactions often lurk in shared resources. Thus, it is advised to minimize the sharing of resources where possible, and where sharing is needed, use careful planning and analysis of requirements and margins. Self-monitoring of critical parameters within the shared resource can be used to verify these target design margins. Examples include providing separate processors for separate subsystems to avoid shared resources, and the use of runtime pressure monitors within a pneumatic system to verify actual margins while in operation.

The sharing of low-level power supplies across diverse systems can also result in unexpected interactions in which each subsystem separately tested shows no problems, but the combination intermittently fails. This very issue forced the return of a large fielded instrument to the factory for investigation. The problem was intermittent noise on an analog channel caused by a crushed catch diode mounted on a solenoid in a different section of the instrument. The cause was too far removed from, and indirectly coupled to, the “victim” electronics to be located by field service personnel even after replacing virtually every PCB and harness in the system. The accidental interface in this instance was a shared 12v supply.

Partitioning the System

The key step in the system engineering process involves partitioning of the system. Partitioning not only selects the types and number of interfaces, but also determines how the system is designed, debugged, integrated, manufactured, and serviced in the field. Standalone subsystems containing the mechanical, electronic, and software components needed to operate that subsystem are most easily developed in parallel, tested in manufacturing, and reused in later projects.

Physical packaging requirements — including shipping and installation — drive system partitioning and must be addressed from the very start of a design. Failure to consider packaging requirements early in the design has caused major redesign late in the process of more than one project. Ideally, the number of interfaces that cross the physical separation boundaries should be minimized to reduce packaging time and installation reassembly time and complexity at the customer site. Physically locating control electronics in close proximity to the mechanical systems they control makes this type of physical division easy, whereas the use of a centralized control system can make for many cables that must be disconnected before shipping, and then rerouted and reconnected to their proper locations at install time.

Intentional and Unintentional Interfaces

Intentional interfaces include power, communications, and mechanical system alignment methodology. Unintentional interfaces can include power system noise interaction, ground loops, and mechanical structure deflection, where the motion of one axis compromises the operations of another axis. Shared communications channels can cause system timing to change in one subsystem, causing changes in timing in another subsystem sharing the channel. Standard Ethernet may work acceptably with low loading and then randomly show large delays as the loading increases even slightly.

Shared processor resources may also have a very similar effect if adequate care is not given to prioritization and worst-case analysis considering all systems, in both normal and fault recovery modes. These timing effects become more pronounced if finer-grained, hard, real-time coordination tasks are moved to higher levels of the system. This is caused by having more items in the critical path.