With the vast range of motion control applications, no one-size-fits-all approach to selecting a motion control networks exists. However, there are a few key factors to consider when deciding on which network to select for a given application.

1. Reaction time and precision

When selecting a motion network, closely evaluate the scan rate, how the scan is done and how fast the system can react.

At a minimum, a network for motion should be able to close motion loops back at the controller to each drive. This is an extremely important criterion for motion. This is especially true if the application has any level of coordinated motion, as each axis needs to receive its own unique commands. Some network protocol promoters will insist that slave-to-slave communication is a substitute for closed-loop control, but this is only true in the simplest of applications such as conveyor drive applications where there is only one master command and the remainder of the drives simply follow that same command or some constant offset from it. Any application where there needs to be independent control should have a robust, relatively fast scan rate to each slave. Also, if you wish to use a single network for motion, I/O and data, the ability to react system-wide to an input in a timely fashion should also be a priority. This is the reaction time, which is directly related to network scan rate.

2. Motion-network determinism

Determinism is not related to network speed or raw scan rate. Many industrial Ethernet fieldbus systems available today actually have a poor scan rate, but the vendors behind each will promote their system as “deterministic,” which may be true. However, a very slow, yet temporal network is not a very useful network for motion, because the user is typically looking for quick reactions to external events in addition to controlling the application in a predictable (deterministic) way, or tight coordination of axes.

3. Motion-controller requirements

Some users may have special or specific controller requirements, such as already having an embedded PC hardware platform specified, or requirements around a particular Real Time OS (RTOS). They may also use a closed system, such as one of the popular rack-based PLCs with connectivity options that can only be supplemented via add-on cards from the PLC vendor.

These difficulties may restrict how or (in the case of some rack-based systems) if a particular protocol can be used in a system.

4. Third-party motion-controller device support

The number of “third-party” master controllers and slave devices on the market are available for completing motion networks. This shows how well the technology is accepted outside of the main promoting company that developed the protocol. This typically means that a wider range of devices are available to fit more applications than what could come from a single supplier such as industry-specific devices, or niche technologies that are not in the portfolio of a single company. This also should give users a certain level of comfort knowing that devices from another company could be substituted in the system if needed. In this case, the user is therefore not locked into a single vendor.

5. Diagnostics

In the past, some widely used protocols had minimal diagnostics capabilities. Users were in the dark about what nodes were communicating, which ones were not communicating, whether any problems involved cabling, connectors, device errors, master faults, etc. Modern industrial Ethernet systems such as EtherCAT provide a wealth of built-in diagnostics functionality to help users know more about their network’s status and can help point personnel in a clear direction if any maintenance is required. The ability to pinpoint and diagnose issues down to the exact location and identify the cause increases reliability, decreases downtime, and facilitates smoother commissioning, resulting in easier initial setup.

6. Cost of system

In the area of cost, Ethernet-based motion networks have some advantages through the use of standard Ethernet media and hardware. You can also eliminate expensive switches, hubs and routers if you select the right industrial Ethernet system. EtherCAT can work with, but does not require any hubs, switches, or routers in the network, nor are there any built into EtherCAT devices, eliminating a huge cost center in the system. In addition, the control enclosures can become smaller as the system designer no longer has to add a 120 VAC outlet to the enclosure in order to power yet another power supply for these devices, or upsize existing 24 VDC power supplies.

7. IT involvement and ownership required

This is a key area where not all industrial Ethernet systems are created equal. IP addresses can be a sore point for companies integrating an Ethernet-based motion bus, so be sure to find out if the network you’re evaluating can operate without them. Keep in mind that a fieldbus that requires IT involvement to set up and run will also require IT support when there is a ‘machine down’ condition. Make sure your company is okay with IT ownership and on-call support response of factory floor equipment. If not, it’s imperative to select an industrial Ethernet system that can maintain the separation of IT and engineering.