From Wikidocs
Jump to: navigation, search

Motion control through a serial pipe

Motion control with a commodity PC has proven itself. However running multiple 50 conductor ribbon cables has proven itself too—that’s a pain. The cables are time consuming to build, the length is limited, ground isolation is non-existant. So an attractive idea is to put the interface electronics at the endpoint, connected to the host PC by a serial cable.

Continuing the Servo To Go philosophy, all calculations and control are performed on a host PC, and the endpoint is relatively "dumb." In this case there is a microprocessor in the endpoint pod, but all it does is deserialize the control data.

Consider some possibilities for a serial protocol:


With USB you can set up an isochronous data transfer which guarantees bandwidth and delays. You could even use it in simultaneously with other USB devices (in contrast with other designs, like Ethernet, where you have to create a separate network just for devices involved in the control).

USB 1.0 has a data rate of 12 Mb/s, and a frame rate of 1 mS--inadaquate for most motion control. Perhaps useful for systems that move slowly, like steering an ocean liner.

USB 2.0 has a data rate of 480 Mb/s, and a frame rate of 125 uS.--adaquate for some motion control. Consider a sampling rate of 1 KHz. On the first frame the data would be transferred, skip the next frame while you performed the control calculations, then send the results on the third frame.

|         |         |         |         |         |         |         |         |
| data in |calculate| data out|         |         |         |         |         |

Sampling rates above 1 KHz. would be difficult. Timing granularity is awkward.


The 400 Mb/s basic data rate sounds attractive. Higher rates are specified, and may see future implementation. However, like USB, cycle time for isochronous transactions is 125 uS.; so the same arguments apply.

If there are only two nodes in your network, and communications are coordinated, then it hardly matters if you use isochronous or asynchronous protocol. Using an asynchronous protocol would give more flexibility. But in that case Firewire offers little, if anything, over Ethernet. With Ethernet 2.0 competing with Firewire in terms of speed, one wonders if Firewire has a future.


The primary objection would be that Ethernet timing is not deterministic. However if we impose some constraints on top of Ethernet, we can get deterministic timing. One constraint will be a cooperative protocol where one node controls who talks when. (The phrase master/slave may be illegal in California.) Use of the connectionless protocol, UDP, eliminates the handshake needed to start a connection. And a static entry in the arp table will eliminate the need to occasionally update the arp table. Static IP addresses eliminate need for DHCP traffic on the network.

Note: point-to-point Ethernet is NOT point-to-point-PROTOCOL over Ethernet.

100 base T is commonly available, so we won't discuss anything slower. Gigabit Ethernet is on the horizon, so we note that an upgrade path is available.

So let’s look at some timing numbers. First, how much data are we sending? Start with a conservative possibility.

// IN and OUT are from the host computer’s perspective
// host --> pod is defined as OUT
// host <-- pod is defined as IN
struct stgserial
    int32  type;          // there’s only one type now
    int32  pIn-vOut[8];   // OUT voltage, IN position
    int32  analogIn[8];   // OUT unused
    int32  dio;           // digital I/O
    int32  misc;

That’s 19 bytes. So, what’s the total packet size?

26 bytes, link layer header
20 bytes, IP header
 8 bytes, UDP header
19 bytes, data
63 bytes * 8 = 504 bits

Yes, that’s a lot of overhead, but the system has seen years of use, the drivers have been debugged, cost is low, and it’s standard on most computers.

Now, what is the transmission time?

504 b / 100 Mb/s ~= 5 uS.

Probably small compared to calculation time and Ethernet driver overhead.

|-5uS-| driver | control |-5uS-|deserialization|.........
|     |overhead|algorithm|     |               |

Suppose driver overhead is 100 uS. and the control algorithm takes 100 uS., and deserialization takes 20 uS., then the total is 230 uS. It seems like we’ve gained little over USB. However, these are conservative estimates. These could be achieved on average hardware under Microsoft Windows. With a good real-time OS, times could be shrunk considerably. And gigabit Ethernet is on the horizon as well. There’s room to grow here.