Machine Design

In sync

Where Ethernet runs out of steam, SynqNet picks up the slack.

XMP-Series controllers from Motion Engineering feature a 32-bit floating-point DSP that handles 32 axes of motion.
SynqNet is built upon openly available industry standard silicon, making it economical and simple for OEMs and drive vendors to embed. No ASICs are required, PHY and Dual-PHY are available from numerous suppliers, and the media-access controller requires an FPGA of only moderate size.
A typical multiaxis control system with SynqNet connection between each axis and the host controller.
SynqNet developer kits are available for drives, I/O, and motion-specific interfaces. These include reference designs and licensed FPGA images. SynqNet has been adopted by leading drive companies like Yaskawa, Advanced Motion Controls, Danaher Motion, Panasonic, Glentek, Sanyo Denki, and Trust Automation.

Marshall Matheson
Motion Engineering Inc.
Santa Barbara, Calif.

Not all networks are created equal. High-performance motion networks demand tightly managed timing for synchronous, real-time updates across multiple axes. Ethernet is adequate for distributed-control schemes but is generally too slow for more-demanding applications. These cases call for a fast synchronous network to connect a centralized motion processor to multiple servoaxes.

A network called SynqNet is gaining fast adoption by industry. It supports centralized control systems and offers fault tolerance, simple plug-and-play configuration, high noise immunity, and support from multiple drive vendors. SynqNet is the first commercially available 100BaseT (IEEE802.3) network that offers all the advantages of a centralized control model, together with better performance, fault tolerance, reliability, and diagnostic features.

Ethernet, or 802.3, has become the ubiquitous office network platform. It seems to be continuing its triumphant progress into industrial automation. In the early days of digital networks, the lack of bandwidth, determinism, and high latency led vendors to offer distributed processing systems. For motion equipment, the result has been intelligent servodrives that interpolate between the irregular and infrequent data points transmitted over the network. Such methods don't work for high-performance, multiaxis applications. The latter situations need a different control model with central processing.

Ethernet was designed to transmit long data packages. A data frame according to the IEEE 802.3 specification consists of 28 control and at least 46 data bytes. This protocol is oversized for typical industrial motion tasks. Usually the data needs of a node (device) are small (fewer than 46 bytes). To reduce the cycle time and latency, Synqnet has optimized the data frame on layer 2. Instead of at least 74 bytes, a SynqNet frame consists of at least 24. This is a key advantage over Ethernet that brings faster and more predictable performance.

Standard Ethernet relies upon a single pair of wires to transmit and receive data. Access to the wire is managed by a well-established mechanism known as multiple-access collision detect (MACD). As the name suggests, multiple devices on the network try to access the same piece of wire. If two devices try to talk at the same time, the resulting collision makes each device stop transmitting and retry later after some random time. Such a mechanism is inherently nondeterministic. The collision time rises almost exponentially as the number of network devices increases linearly. For office networking and general automation, the lack of determinism works just fine. But most serious motion applications need alternative ways of arbitrating traffic.

SynqNet avoids the MACD mechanism. It uses a synchronous method to transmit data on a regular time schedule to every device. Independent receive and transmit wire pairs (full-duplex) eliminate data collisions and deliver a deterministic date rate of 2 X 100 Mbits/sec. The resulting cycle times can be as short as 25 µsec for four axes. In addition, SynqNet has a configurable packet structure that allows for cycle times as low as 10 µsec.

SynqNet can be configured in either a string or a ring topology. Ring topology tolerates cable breaks and is easier to wire and better for safety and reliability. For example, if two out of five nodes fail, SynqNet is still able to control the remaining three nodes, flag the application, then execute alternative motion parameters. A closed ring ensures a redundant path for data transmitted anywhere in the ring.

If a wiring segment fails, SynqNet hardware reroutes the data path within two servo cycles without losing the network connection. Simultaneously, the application is informed of the event and its location so the machine can respond accordingly. For example, a machine can be programmed to finish a move sequence that would otherwise cause a dangerous or expensive collision of independent or interlocked machine axes.

In addition, each node has its own watchdog timer. So even if the host or whole network fails, each node can react in a predictable and safe way for a smooth and controlled shut down. To predict possible network failures, SynqNet includes transmission error counters at every node. Any abnormal increase in error count can alert the application software and localize the potential problem before it becomes a catastrophic failure. SynqNet utilizes 100BaseT CRC error checking. It is the only commercially available network that offers this level of safety and reliability. Fault tolerance is important in all digital network systems, especially for high value tasks and medical applications where redundancy is crucial.

Both SynqNet and FireWire (IEEE 1394) networks are designed to handle a large number of nodes. Nodes distributed around a machine or plant are often referenced to different electrical grounds, which introduce ground noise and circulating currents. FireWire cables provide a dc connection between these grounds and can cause a ground loop. The resulting ground currents will degrade the reliability of FireWire networks. Data signals can degrade and there can be excessive EMI from the cable. These effects can cause conditions that can be dangerous or which harm motion equipment, or cause a system shut down. Ground currents that are high enough can damage components as well as create shock hazards.

FireWire is designed to source and/or sink power to/from remote nodes. This lets nodes without their own power function on the network. This feature coupled with the high-speed signaling rate required in a FireWire system makes dc cable isolation unfeasible. In contrast, industry-standard network systems like 100BaseT (IEEE802.3) and others employ dc cable isolation using transformers or optical couplers. Since SynqNet is based on 100BaseT, it avoids the EMI problems inherent in 1394 networks.

The interoperability of networks is often misunderstood and misrepresented. For example, the IEEE 1394 standard defines an interface at the network device driver level. It does not define the software interface to a motion-control application and today there's no FireWire automation standard to resolve multivendor interoperability problems. As a result, 1394 is available from multiple vendors, yet there is no common software API, making multivendor interoperability impractical if not impossible. The machine designer is effectively locked into a specific vendor offering closed 1394 drives and controls. Sercos adopts a different approach, using some standard or mandatory elements, and some proprietary elements. As a result, designers need to intimately know the proprietary elements of every networked component to devise truly interoperable systems.

In contrast, SynqNet was designed with a common software API for all network devices from multiple vendors. SynqNet products are now commercially available from U.S. and Japanese suppliers offering both standard and custom motion products. The API is available as a set of powerful C/C++ or Active X motion libraries.

High-performance motion-control systems depend on several key components working together seamlessly. A control system must transmit the desired motion profile into the movements of one or more servoaxes. Doing this often requires translation from XYZ space coordinates to machine or joint coordinates using some form of kinematic model. The model helps compensate for mechanical imperfections such as nonlinearity or the effects of axis cross coupling to optimize machine performance.

Kinematic models and compensation techniques rely upon a central motion processor to perform fast, accurate matrix computations based upon multiple inputs generating multiple outputs. The term MIMO (multiple in multiple out) is often used to describe this generic class of control system and the software control model. The exact type of inputs, outputs, and matrix computations will vary by application and the proprietary know-how of the machine builder.

Whatever the final software control model, it is important to minimize total servo cycle time. The shorter the cycle time, the tighter the control system and the higher the performance of the machine mechanism. Cycle time becomes a significant factor in machine performance for fast point-to-point moves or accurate path motion.

Modern control systems take multiple demand inputs and multiple feedback inputs, such as the actual torque and velocity, from each axis to compute new target data for each motor. High performance levies the request that demand data and feedback data transmit synchronously, with short cycle times and low latencies. Any transmission delay represents a phase delay in the control system, limiting gain and machine response time.

Cycle time includes time to acquire feedback data, perform matrix computation, and transmit new target data. A fast synchronous network and a fast processing engine are key in getting cycle time under control. MIMO control cannot take place on distributed systems that have decentralized processing and relatively slow connections between network devices.

All networks rely on data sampling at some discrete time based upon a clock reference. When independent systems with independent clocks are connected together, as with a network, the natural and random variances in clock frequency can present a challenge. Many engineers are familiar with the concept of "beating" when two high-frequency sources, closely matched but slightly out of phase, beat at the difference frequency. In an aircraft with multiple engines, such beating is audible as a throbbing noise. Digital-control systems are no different and in a collision-free network, the beating ("jitter" in networking parlance) arises primarily from differences between the local clocks at the master and slave nodes. Electromagnetic interference can also contribute to jitter in a real-world network. This jitter transmits directly to the path motion. Thus accurate path motion demands minimum jitter.

Skew is a constant delay of a data transmission between transmitter and receiver or between network nodes. It's caused by the propagation delay of the cable (approximately 1 µsec/100 m) and delays in internal logic circuitry. Skew becomes relevant for high-performance motion and the network must be capable of measuring and compensating for it. In a single axis, jitter causes erratic control behavior such as variation of velocity or oscillatory final position error. The results are more severe for multiaxis systems.

Skew introduces a constant phase shift between network nodes. Thus coordinated axes do not receive a simultaneous set of command values. For example, consider a fast circular interpolation with two coordinated axes (e.g., material cutting). In this case, one axis receives a sinusoidal and the second axis a cosinusoidal command profile. Skew (constant phase shift) will mutate the circle into an ellipse. Additional jitter would also add some distortion to the shape.

SynqNet limits the jitter to less than 1 µsec by using phase-locked-loop techniques to synchronize the independent clocks of each network slave to the network master. This provides superior performance to other nonsynchronized networks such as TCP/IP or IP/UDP-based Ethernet networks that can keep jitter to only 20 µsec using time stamps. Ethernet protocols introduce additional overhead that limits typical cycle times and latencies to 1 µsec or longer. While this level of performance may be adequate for general automation, it falls short for high-performance motion-control. SynqNet limits skew to ±20 ns using algorithms that measure the system skew and compensate for it in hardware. Jitter and skew are guaranteed for any number of nodes or network traffic conditions.

SynqNet tools work with networked motion systems that contain components from multiple vendors. Tools for real-time data graphing, network configuration and management, mechanical characterization, and optimization are available for windows platforms and also work across any TCP/IP socket connection.

SynqNet can interrogate firmware revisions and perform firmware downloads to every device on the network. This simplifies the process of configuration management of software, firmware, even FPGA images. It also is an efficient method for upgrading machine upgrade packages or installing spare components of unknown configuration status in the field.

Real-time node information supports predictive maintenance, remote diagnosis and repair. For example, if the node is a SynqNet amplifier, the user application can remotely access parameters such as temperature, fault and warning conditions, configuration, drive motor, and encoder information. Moreover, access is in real time.

Make contact:

Motion Engineering Inc., Santa Barbara, Calif., 805-681-3300,

Comparison of various network protocols

  SynqNet Ethernet
(IEEE 1394)
Sercos Can
EM immunity High, transformer
High, transformer
twisted pair
High, fiber
regular photocoupler
Maximum internode distance 100 m 100 m 4.5 m 40 m 40 m total
Minimum cycle time/latency <25 µsec 1 to 2 msec 125 to 250 µsec 250 µsec 1 msec
Bandwidth 100 + 100 Mbits/sec 100 Mbits/sec 800 Mbits/sec 16 Mbits/sec 1 Mbits/sec
Next generation 1 + 1 Gbits/sec 1 Gbits/sec 1.6 Gbits/sec - -
Transfer mode Full duplex Half duplex Half duplex Half duplex Half duplex
Maximum jitter <1 µsec 20 µsec <1 µsec 1 µsec 1 to 120 µsec
Fault tolerance Yes No No No No
Need of switches/hubs No Yes No No No
Maximum number of nodes 254 No limit 63 254 2,032
A comparison of network protocols shows SynqNet with the minimum cycle time and jitter.
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.