Machine Design

FireWire jumps from consumer applications to factory automation

FireWire, also knows as IEEE-1394, could help engineers build better motion-control systems.

Edison Hudson
MetaControl Technologies
Morrisville, N.C.

Engineers are being asked to design industrial automation systems that are faster and capable of handling complex, simultaneous tasks. And they're being asked to do it using cost-effective electronics and robust software. Taking a page from consumer technology, several companies are looking at adapting IEEE-1394 or FireWire to tackle the higher performance needs and lower systems costs demanded in advanced machinery. Combining FireWire's high-speed serial bus with today's ever-faster embedded processors should open the door to an economical, high-performance architecture for real-time automation.

FireWire, also known as IEEE-1394 in version A and B, eliminates backplane controls, allowing distributed computing power linked by synchronized, high-bandwidth messages. Adding distributed embedded processor nodes and intelligent digital cameras can make FireWire the preferred method of automation control.

FireWire basics

Though originally intended for consumer-oriented applications such as high-speed video, many of FireWire's features are well suited to advanced motion-control systems.

High speed: 1394-A can handle 400 Mbits/sec, three orders of magnitude faster than nearly every industrial distributed-control system serial bus. And 1394-B competes in absolute speed with parallel bus backplanes, offering speeds only a few costly, high-performance backplanes match. FireWire's bandwidth meets the majority of machine control and instrumentation needs where there are frequent messages that are typically short in data length.

Machine vision, which needs a fast bus, is one area that could benefit from FireWire. Until now, it has not been easy to handle machine vision on distributed-control architectures. But FireWire is fast enough to permit digital acquisition of videos from several cameras and could replace backplane-based framegrabbers.

Isochronous mode: Most serial communication schemes cannot guarantee time-based delivery and the delivery order of data packets. FireWire can, which helps closed-loop servo controls, data acquisition from analog sources, and machine vision using digital video.

Asynchronous mode: Control systems commonly need to respond to instantaneous events. With FireWire, asynchronous event messages can be generated every bus clock cycle by any node, letting high-priority messages propagate with a known latency. The 1394-A asynchronous window of 125 µsec, for example, is enough for most control applications. 1394-B drops the interval to 62.5 µsec, and will eventually get it down to under 16 µsec.

Peer-to-peer mode: This lets FireWire nodes communicate without sending each message through a host. This decreases the latency associated with host-centric networks such as USB and Ethernet. Peer-to-peer communication is important when a change in state at one node needs to be passed to another as quickly as possible and with great determinism. Host-centric networks often suffer from varying delays in message propagation depending on the processing load at the host. Peer to peer, however, lets designers implement schemes in which messages are sent just to effected nodes. It also offers the possibility of embedded controls without PCs.

Broadcast mode: FireWire can send the same message to all nodes simultaneously. This is useful when many nodes need to start or stop a process in synchronization or all nodes need to know about safety conditions affecting the entire system. It is also a powerful feature for synchronization and control of multiaxis control over distributed networks. Early versions of FireWire had a few glaring limitations for machine control:

  • Galvanic isolation: Earlier versions of 1394 sometime experienced unintended "unplug" potential data corruption due to system-level ground fluctuations affecting electrical isolation. These grounding issues could be resolved with system engineering, but earlier versions of FireWire are less robust than some industrial norms.
  • Distance between nodes: For most intramachine applications, the 4.3 meter limit on cabling between 1394-A nodes is not important. But it does prevent FireWire from being used in larger systems where nodes are tens of meters apart.
  • RFI interference: In factory and machine environments, electrical noise can be much higher than in consumer environments. In high-power applications, such as large motor systems, radiated noise could be a problem for machines built to earlier 1394 standards.

Each of these concerns can be mitigated by careful electrical design and strict attention to system grounding. Distributed-control systems based on the earlier 1394-A standard have proven to be robust and reliable, but usually at the cost of added components. The distance issue has been overcome in earlier systems by using long-haul adapters that convert 1394 twisted pair into plastic or optical signals for long distances, then convert back to 1394 at the other end.

And the 1394-B standard eliminates all of the above concerns, making the new standard ever more compatible with control-system design needs. The simplified electrical isolation scheme adopted by 1394-B also costs less than the magnetic approach taken by other buses.

Compared to Ethernet

Many designers expect Ethernet's pervasiveness to be decisive in deciding on what most distributed-control networks will be based. There is already wide availability of Ethernet ports on PCs and most companies have some prewired infrastructure support for it. But because of the value put on performance in machine design, technical factors are arrayed against Ethernet as the logical choice for high-performance real-time control.

The main control problem with Ethernet is its Collision Sense, Multiple Access, Collision Detection scheme. It makes access nondeterministic. An Ethernet controller connected to a thin Ethernet or hub cannot send a packet as long as the network is sending another packet. The controller can send its packet only if the network is idle.

There is also a latency problem inherent in nonswitch-based Ethernet. Latency in control systems reduces phase margin and the bandwidth of control. When latency is high or variable, many processes cannot not be controlled in a stable way, especially not when traditional proportional integral derivative (PID) control loops are used. Non-PID type controls are rare, and control schemes that allow variable latency are complex to implement. Several designs have been developed to overcome Ethernet's latency deficiencies. Most focus on reducing traffic and implementing known performance switch nodes.

But even after upgrading existing "office-grade" Ethernet to make it industrial strength and configuring it to provide some determinism, network performance in closed-loop, real-time control is still worse than 1394 standard consumer technology. Most "deterministic" Ethernet schemes strongly recommend keeping network utilization below 30%. But this turns a 100-Mbits/sec Ethernet into a mere 30-Mbits/sec network, slower than other methods of real-time control and makes machine vision and closed-loop servo synchronization on a single network unworkable.

There is also confusion regarding the cost of Ethernet relative to 1394. With the broadening acceptance of FireWire for consumer appliances and PC's, it could eventually gain the upper hand in terms of absolute volume, since Ethernet volume is primarily driven by corporate levels of demand. With the advent of Windows XP and Mac OS, nearly every home PC will have a 1394 port, (required by all PCs officially called "Windows XP Ready").

The 1394 Trade Assoc. estimates that node hardware for 1394-B will drop to around $5, substantially below that of most Ethernet-node designs. Regardless of actual volumes and designs, the relative difference in component cost to implement 1394 relative to Ethernet will be negligible in the near future. Because 1394-B also uses the same transmission mediums, CAT-5 and fiber cable, total system costs should be the same.

It should also be noted that many industrial Ethernet standards groups are proposing changes that will render the industrial versions almost incompatible with the current infrastructure. For example, several groups advocate abandoning TCP-based protocols at the host level in favor of a more controls-oriented protocol such as UDP. And the German-based Profibus group recently called for implementation of an industrial Ethernet which abandons the RJ-45 connector in favor of a DIN-type connector.

These changes could hurt the usefulness and economics of Ethernet as a well-defined communication network. Imposing nonstandard protocols and hardware modifications to force it into a better vehicle for industrial controls will likely result in costly, proprietary, and narrowly supported niche products that are Ethernet in name only.

For intramachine controls, the technical features of FireWire, and its cost parity with Ethernet, make it well suited to high-performance applications. By technical rights, the 1394-B version should also win a significant portion of the general DCS markets, but incumbency is always a tough competitor.

Both systems control a six-axis vision systems, but one uses FireWire. In the system using traditional architecture, specialized backplanes implement various control functions. Motion control is typically handled by a specialized controller or board, machine vision by another, and digital and analog I/O functions add yet an additional subsystem. Bus-to-bus communication between subsystems is often through RS-232/422/485 serial channels or with bus converters. Cabling these systems is complex and represents a major constraint on complexity. The centralized approach also limits reliability and configurability because it takes hundreds of conductors, many traversing moving axes, routing signals to the central control chassis. FireWire simplifies wiring and lets a PC handle control.

Comparing FireWire and Ethernet

Data ratesS200/400/800S10/100
Bit error rate (1/errors)10-1210-9
Topologies supportedTree, Daisy, Star, HubStar
Maximum length between hubs100 meter75 meter
Isochronous modeYesNo
Peer-to-peer modeYesNo
ProtocolsMany, six standardTCP/IP, UDP
Media supportedTP, plastic, Glass, CAT5Glass, CAT5
Universal plug-and-playYesNo

Network latencies

 Fundamental latency
Closed-loop domain latency
1394-A, 400 Mbits/sec125250
1394-B, 800 Mbits/sec62.5125
Switched Ethernet228456
TAGS: Technologies
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.