There are many considerations when designing an application that includes motion control. What type of motor to be used, how to select the correct drive for the motor, how to get feedback from the system, how to synchronize movements and get different parts of the system to communicate together are all questions that need to be answered during the design of a high-performance reliable motion system.
The first choice that needs to be made in any kind of a motion application is to decide on the right kind of motor for that specific application. Some of the most common motor types are stepper motors, brushed or brushless servos and synchronous or induction AC motors. This selection is typically made based on the torque and speed characteristics of a specific motor.
For closed loop control, the feedback is important and there are a lot of sensors like encoders, resolvers, tachometers, etc. available. Relative encoders give position information relative to the initial position whereas absolute encoders hold the absolute position of the shaft and can prove useful when the position is required at the time of machine start up.
The Communication Bus is responsible for passing on the motion commands from the controller to the drive. The communication may be through analog signals, digital step and direction commands or over deterministic communication buses.
Many factors are considered while choosing the communication bus, the most significant one being the distance between the motion controller and the drive and the presence of ambient noise. For example, the communication bus like EtherCAT may be more viable than analog signals in a noisy environment. However, this selection is also highly dependent upon the compatibility between the motion controller and the drive being selected especially when they are being provided by different vendors.
It is important to evaluate the motion profile and application requirements to see whether multiple axis will need to be synchronized or coordinated. The most basic way of synchronizing multiple axes of motion would be to decide a motion vector, resolve it into components for different axes and then pass these commands synchronously to different axes of motion. Another way would be electronic gearing which allows an axis of motion to act as a slave for another axis. In those cases, the slave trajectory can be calculated by a scaling of the master set-point.
However, there can be other requirements of synchronizing motion with cameras or sensors. For example, a motion system for testing an HMI may require a pressure transducer to be the source of feedback to apply just the right pressure through the probe. In an End-Of-Line inspection and testing, a camera may be responsible for commanding the motion system.
With the hardware and synchronization requirements set, you can now decide where the control code will run. There are two main ways to set up a motion control system, either to have most of the control code be within a single target or to separate the computation among multiple nodes.
The first approach can be realized by a central system like a PC having motion control cards. These kinds of systems are easy to set up but scalability in terms of the number of PCI slots, etc. is the limitation. An alternative approach can be to have a supervisory system generating the trajectories and providing these trajectories to a set of distributed smart drives which are responsible for running the lower level torque and velocity control loops. The only limitation in these kinds of systems is that the synchronization is limited to the communication bus. A daisy chained network of smart EtherCAT drives can be a classic example of this kind of a system.
Some motion systems act on their own while others may require integration with other systems like vision. Some of the features required are modularity of the software which can allow you to change the drives (from different vendors) without much change in the code. Furthermore, being able to test the motion profiles that the software generates within the simulation environment. This is usually achieved by having the trajectory generation and to plot them or send them to a simulated drive or a model of the drive and motor. Finally, the capacity to use a model of the motor could help test most the code and some of the tuning before needing to move to a physical world. This is usually done using mechanical simulation software like SolidWorks running in tandem with the motion system.