We briefly touched on the connections between the points of the Pentagon Power in our discussions of sensors, amplifiers, PLCs, and PID controllers. In this chapter we are going to dig deep into the digital networks that can be used to connect the five points. There are some esoteric details in this chapter, but you don’t need to absorb them all. If you are looking for nitty gritty details, this chapter should whet your appetite. But if there is more detail than you can process in one reading, skip the sections that feel intimidating. You can come back when you need a deeper understanding. I aim to cover the physical implementations and defining characteristics of the most popular network protocols. The strengths and weaknesses of each protocol can be gleaned without becoming a networking expert.

A network is an electrical system that allows information to be distributed to many devices without dedicated wiring running from every device that needs to pass information back and forth. The need for networks is obvious: if you had to run a wire from the Operator Interface to each Controller, you would quickly build up an unmanageable bulk of wires from the automation computer. Similarly, we don’t build roads from your house to each destination. It would be ridiculous to have a supermarket road, school road, work road, and bar road, each emanating from your garage. Expand that scheme to each of your neighbors and this gets even more ridiculous. Instead, in civil engineering we build a network of shared roads that cars and bikes and buses and trucks can all use to navigate from one place to another.

In electronic engineering, we build networks where a single set of wires can carry the data from one point to another. The physical layout and design goals for different networks can be seen in the variety of standardized networking protocols, each with strengths and weaknesses for a specific task.

Bits and Bytes

Rather than moving cars around on roads, electronic networks move data from a device that is producing information to a device that wants to consume information. The information is expressed electrically as digital signals. A digital signal has two states: on and off, which represent either a 1 (on) or 0 (off). All information transmitted over the network is expressed as numbers and those numbers are expressed as a series of 1s and 0s. Each 1 or 0 is called a bit. Eight bits together make a byte. If we group those bits together into a byte, we can express a number up to 255 in binary format. In binary format, each digit doubles in value, so the decimal number 255 looks like this:

You can figure out the value in of the binary number in decimal by adding all the decimal values that have a 1 in the byte. In the example above, we can see that the value is indeed 255:

How about byte value 01101010?

Using the same method we can determine that the decimal value is 106:

To express larger numbers we need more bits.

Once the number of bits and bytes grows large, there are familiar abbreviations we can use:

Having a basic grasp of the way data is expressed will come in handy as we discuss how these bits move across a network.

Networks in General

Examining the connections between the points on the Pentagon of Power, there are some clear needs for a network, and other connections that could be networked or wired discreetly. These connections have different demands for latency: some connections demand low latency (high-speed); others can be more lackadaisical. The Operator Interface is a relatively slow-speed device that gathers information from the machinery and presents it to the operator. The Operator Interface merely needs to keep up with our ability to process information. Charged with showing position and status updates for every machine, it needs to refresh 30–60 times per second to make the updates appear to be a continuous stream of data.

If we do some rough math we can gain an approximate understanding of the needs per axis.

Even with some very rough, back-of-the-envelope approximations, we can see that a single axis worth of data can fit certainly within 256 bits for a single status update. If we update that axis 30 times per second, we’d need a network that can handle 7680 bits/second for each axis. If we had 100 axes, the number climbs to 768,000 bits/second or roughly 750 kb/s. Yes, that’s just 750 kilobits per second to present the Operator Interface with a sufficient data stream to keep you informed of the status and position of 100 axes. A slow Ethernet interface can handle 10 Mb/s, which is more than ten times the required data rate for the application so just about any network protocol will suffice for this connection.

By contrast, the Control requires a much faster connection between both the encoder and amplifier to effectively run the PID loop. A Control monitoring a 1750 RPM motor with a 2500 PPR encoder will capture 17,500,000 quadrature pulses every minute or roughly 291,667 quadrature pulses every second when the motor is spinning at nameplate speed. Remember that a quadrature encoder has two channels and four distinct states that need to be captured for each pulse. Assuming that the position data is stored as a 32-bit number, the Operator Interface would need a data stream of 960 b/s to show the encoder position, while the Control requires 292 kb/s to actually count the encoder pulses. For the same data, because of their differing purposes, the Control has 300 times the network speed requirement as the Operator Interface.

The exact numbers will shift depending on your specific implementation, but the point is that the connection speed between the Feedback and Control must be very fast, but the connection speed between the Control and Operator Interface can be hundreds of times slower. These radically different design parameters will impact how the system is architected.

A network protocol is a set of standards that govern how information is passed around a network. That information at the lowest level is a series of electrical pulses and at the highest level is a distinctly formatted message that is used by network nodes to communicate. Rather than a single network protocol that covers everything from the type of wire used to the format of the message sent between network nodes, a high-level protocol is built on top of other lower-level protocols to provide the end functionality required to solve a given problem. In the 1980s, a formalized model of seven layers was developed to describe the networking layer cake called the OSI (Open Systems Interconnection) model that defines a vocabulary for discussing networks. The lowest level is the nuts and bolts of wire connection, the highest level describes the language idioms used for meaningful conversation, and the intervening layers handle details like addressing, packet format, and other minutiae. A protocol may span several layers, but the functionality must be provided somewhere in the stack. This model is perhaps a bit too granular for our discussion, but it’s useful when identifying the various protocols to determine what task they were designed to handle. The seven layers and their abridged purposes are as follows:

The Physical Layer defines the properties of electrical pulses which transmit bits of data. Devices that are wired together on the same network must share the same electrical specifications to communicate. At the Application Layer, those bits must be formatted in a way that both the sender and receiver understand for the communication to be effective. If you and I were to correspond by sending letters back and forth, pen and paper would be our protocol’s Physical Layer. The language we use to write the contents of the letter would be Application Layer. It would be silly for you to write me on paper, and me to respond via email, if you didn’t have a computer and I didn’t have a mailbox. Once we worked out those kinks, it would be equally unproductive if you wrote to me in English and I responded in German (unless we were both bilingual). It is possible to reuse the same Application Layer protocol on different Transport, Data Link, or Physical Layer protocols. Though we wrote letters on paper, if we felt constrained by the speed of the postal service we could switch to writing English notes via email to take advantage of a faster Physical Layer. This is a theme we’ll see in several industrial application protocols that have evolved over time to leverage faster technology in modern Transport layers.

Architecturally, the networks we are interested in using for scenic automation either support a distributed model or a centralized model. In a distributed model, the high-speed processing requirements are split among many computers. The computers send information back and forth, but each is responsible for its own set of problems.

The internet is the ultimate example of a distributed network. There are millions of servers, each responsible for its own information and doing its chunk of work, but sending information back and forth to peers on the network to either further a larger chunk of work or respond to simple information requests. By contrast, a centralized system places the processing requirements in a single computer and the network exists to extend the tendrils of its input and output mechanism.

A factory floor uses a network to make a single, large machine out of a process that may be composed of hundreds of sensors and actuators that are acting in unison to produce a widget. The central processor holds the entire scope of the endeavor to turn raw materials into a finished product, but the physical spans are too great, or the number of devices too many, for dedicated wiring to be practical. In this case, the network makes it appear to the programmer that the entire factory is a single, complex machine and all the actuators and sensors are directly connected to the computer even though the computer and its devices may be separated by great distances and the information is distributed over a few shared wires.

The architectural difference in the conceptual model of a network is important. There are advantages to each, and limitations that can restrict either the performance or programming efficiency of both. The connections between points of the Pentagon of Power have different demands for latency and bandwidth. The connection between feedback sensor and control requires much higher bandwidth and lower latency than the connection between control and operator interface. If we chose a centralized network, the requirements for that processor grow as we add more axes, each with encoders that need to be monitored at relatively high speed.

The capacity of the central processor will determine how many axes can be controlled, which sounds reasonable when reading a book, but is incredibly frustrating when you hit that limit standing on stage. If you have a centralized architecture that can control a maximum of 24 axes, when you want to add the 25th axis your options are to replace the central processor with something more powerful, if possible, or add a completely isolated system to control up to another 24 axes. By contrast, if the architecture is distributed and each little processor is tasked with controlling a single axis, with a relatively lightweight connection back to a coordinating operator interface, expansion is easy by adding more processors to the existing network.

There is a minor increase to the demand on the Operator Interface, but the heavy-lifting is being handled by the distributed controls. Perfect… until you need to have fast synchronized motion between multiple axes. A coordinating operator interface can handle simple coordination to make things look like they are moving at the same time, but if you need to insure that ten chain motors are hoisting at exactly the same rate and sharing the load equally, that cross-axis processing needs to happen very quickly. In that rig, a centralized processor that has immediate access to all the data from each encoder on the group of motors sounds dreamy as you struggle to get fast deterministic behavior out of a decentralized system.

Engineering is about compromise, and finding the correct balance between expansion and performance is another example of those real, impactful compromises that has been sought for decades as control engineers developed the multi-colored garden of network protocols we will survey.

Serial Communication

All the protocols we will discuss are serial protocols, therefore we will dissect the meaning and fundamental function of a serial protocol. Serially transmitted data is expressed as a stream of bits. These bits are sent through electrical voltages. A high voltage level equates to 1 and a low voltage level equates to 0. In contrast to serial data, parallel data uses multiple conductors to transmit a byte (8 bits) or multiple bytes at once.

If you are of a certain age, you may well remember that PCs used to have a small serial port and a large parallel port on the back. The serial port was used for slow-speed devices like mice and keyboards, while the parallel port was used for devices with faster needs like printers and scanners. Since parallel interfaces can produce 8, 16, or 32 times the amount of data when compared to a serial line, it seems obviously preferable. However, parallel transmission requires more cabling and each wire is susceptible to electrical interference, making it more fragile and more expensive than serial transmission. Serial interfaces have simpler wiring and cheaper cost because they require fewer conductors. Improved transmission speeds of serial protocols have eliminated the prior speed advantage of parallel transmission. Serial interfaces are now preferred in all circumstances except for fast connections between chips on circuit boards. However, even in there high-speed serial buses are gaining popularity because they allow chip designers to reduce the number of pins on chips.

As mentioned at the beginning of the chapter, each 1 or 0 is a bit of data. Bits are grouped into bytes composed of 8 bits. Bytes are then grouped together into packets. The length and format of packets vary depending on the application, but some agreement between sender and receiver of the timing of these electrical signals exists.

A clock is used to time how long the sender keeps the voltage high or low for each bit. The receiver must know the timing that was used in the transmission to accurately decode the data. One way to share the timing between the sender and receiver is to use a master clock signal that pulses in time with the rate of transmission. This is known as synchronous serial since both the sender and receiver are synchronized by the same clock. Synchronous serial communication requires an additional conductor to carry the clock pulse, but there is no question between the two devices about the rate of transmission since it drives both ends of the conversation.

On the other hand, an asynchronous serial link between two devices requires both the sender and receiver to generate their own clock signals at a preordained rate. Asynchronous serial is a more popular interface between devices that are separated by more than a few inches because of the reduced wiring and because the absence of the clock signal is one less signal to worry about getting corrupted when run over long wires. The lack of a clock signal, however, requires that both the sender and receiver are programmed to operate at the same rate and each has a crystal clock that can generate timing pulses to match the desired transmission rate.

The transmission rate is referred to as the baud rate and is measured in bits per second, kilobits (1000 bits) per second, or megabits (1,000,000 bits) per second. If you ever tried to download Donkey Kong from a BBS with a 400 bps modem, you know how magical a baud rate measured in megabits sounds.

Devices that are built to communicate over an asynchronous serial link are equipped with a UART (universal asynchronous receiver/transmitter) that is a dedicated piece of hardware, either as a separate chip or commonly built into a microprocessor, that handles coding and decoding serial data into a parallel representation for processing. UARTs operate at voltage levels to match a microprocessor and use a separate driver chip to translate those levels for cross-device cabling. UARTs can be set to operate at a wide range of baud rates either from an internal oscillator or external clock signal. A UART can be connected to an RS485 driver/receiver, or to other serial variants like RS232 and RS422. A UART can also be connected to the physical interface for higher level protocols like Ethernet.

Ultimately, these protocols break down data from a parallel representation in a microprocessor register into a stream of serial bits, sending it over some wires, and then reconstructing them at the other end back into a parallel representation to get stuffed into a different microprocessor register. Of course, the devil is in the detail about how effective each is at this task, but it’s good to consider that fundamentally that is always the goal.

A serial link facilitates communication between two devices, and that conversation can take three formats: simplex, half-duplex, or full-duplex. With a single pair of conductors, a simplex link allows for communication from a master device to a slave device, but without any allowance for the slave device to respond. In that arrangement, one wire is used to transmit data and the other is a reference, or baseline, by which the data line voltage is measured.

If the two devices take turns using the same data wire, half-duplex communication can be achieved by sending, pausing, and receiving.

Full-duplex requires another wire so that the devices can each send and receive simultaneously.

Each format has a use depending on the demands of the devices to communicate, the desired speed, and wiring complexity.

RS485

The grand-daddy of our control networks is RS485, which laid out a standard for serial data transmission in the 1980s and continues today. It is a serial protocol that can be wired as either half-duplex or full-duplex with either one twisted pair of wires or two, respectively. RS485 is similar to the well-known RS232 in that it is just an electrical protocol for transmitting bytes without enforcing a data-packet format. Unlike RS232, RS485 was designed to run long distances and provide a network bus that can be used by more than two devices and is therefore sometimes referred to as multi-drop serial.

The specification recommends that the network is laid out as a daisy chain, also described as a line or bus topology. Each device, or node, on the network is equipped with an in port and an out port to grab the signal and then feed it down the line to the next node.

In between the in and out ports, a short network stub is wired from the bus wires to the internal driver/receiver in the device. With a single pair of wires, one device can transmit at a time in half-duplex mode, or two pairs can be employed for full-duplex communication, allowing simultaneously transmission from two devices. The signal voltages are transmitted over twisted pair wires as a differential signal, meaning that it doesn’t require a reference line. Instead, the voltage is measured between the signal pairs. The data on the wire pair is transmitted as an inverting signal. The two wires are labeled A and B, or D+ and D-. A is the non-inverted signal line, and B is the inverted signal of A. When A is high, B is low. When A is low, B is high. To transmit signals, a node must have a driver that produces the differential signal. To listen for signals, a node must have a receiver that can decipher the differential signal. The use of driver/receiver chips and twisted pair wire give the signal greater immunity to electrical interference than a single wire interface which makes it possible for RS485 to run long distances in relatively noisy environments such as factories and theatres.

Astute readers will notice that this signal sounds similar to a quadrature encoder with differential line drivers. In fact, those signals are electrically identical. The most prevalent use of RS485 in theatre is DMX512, used as the ubiquitous lighting standard. This range of uses showcases the flexibility of RS485. That flexibility results from the lack of specification for data formatting, or addressing, or error-checking. RS485 specifies only the electrical characteristics of the drivers and receivers that can be used for a balanced transmission line that connects multiple nodes.

The key features of the RS485 specification are:

The data rate at short distances is quite good, but the transmission rate drops considerably as the distance increases. For slower demands of an automation system, for instance links between the Operator Interface and Controllers, RS485 is perfectly suitable. Depending on the distance, it could also be used for fast communication between Feedback and Controllers, or Controller to Amplifier. To leverage it in any situation, however, you must either develop an application protocol, or use an existing one. RS485 can transmit the bits and bytes, but it doesn’t provide any guidance for what the bits represent so that nodes can communicate effectively – that is left to you. Having two devices that both have an RS485 serial link does not guarantee that they can communicate since there isn’t a common language. Unsurprisingly, you can’t plug an incremental encoder into a DMX circuit and see encoder data on your light board. Those two devices don’t understand each other. Instead, RS485 is employed as a foundation on which other, richer protocols are constructed.

Just as the RS485 specification doesn’t dictate a data packet format, it also doesn’t call out a common cabling format. You are free to wire RS485 however you please, and yet you also can’t leverage commodity cabling that is pre-built for RS485. Various higher level protocols have standardized cabling, but raw RS485 is the Wild West of cabling.

If you’d like to connect a PC to an RS485 device, there are USB to RS485 adapters that will do the trick. A commodity serial terminal program, or Unix shell, can give you access to the serial link and allow you to send raw bytes over the communication link, but you will need to understand the details of the application protocol the device at the other end of the wire is expecting in order to have a meaningful conversation.

Ethernet

Like much of modern-day computer technology, such as the mouse, laser printer, graphical user interface, and Unix, Ethernet was developed in the 1970s at Xerox’s famed Palo Alto Research Center, more commonly called Xerox PARC. In the networking dog fights of the 1980s, Ethernet emerged as the dominant technology, beating IBM’s Token-Ring and Token-Bus in the contest to create a ubiquitous connection between computers. Ethernet can transmit data between large numbers of computers with shared wiring in full-duplex mode to achieve very high data throughput rates. The most common data rates are 10 Mbs, 100 Mbs, and 1 Gbs, referred to as 10 BASE-T, 100 BASE-TX, and 1000 BASE-T, or Ethernet, Fast Ethernet, and Gigabit Ethernet.

Every Ethernet device is equipped with specialized hardware to encode and decode the serial data on the network. The hardware, known as a PHY, implements the circuitry necessary to send and receive data over two twisted pairs of wires. One pair is used to transmit data, one pair is used to receive data, and the PHY is a transceiver that interfaces between the network and the microprocessor that needs to communicate with other nodes on the network. Much like full-duplex RS485, Ethernet uses differential signals to transmit long distances with good noise immunity. The voltage levels for the data lines are +/-2.5V. Each network interface has a Media Access Control (MAC) address permanently assigned to the hardware. The MAC address is either a 48-bit or 64-bit number that uniquely identifies each network interface.

The Ethernet protocol transmits data from one network interface to another in a data packet that contains an Ethernet frame. The Ethernet frame contains the MAC address of the sender, the MAC address of the receiver, the data to be sent, and then an error checking code.

This foundational format makes guarantees that RS485 does not. The use of hardware addresses guarantees that a common format is used to identify all devices on the network and that every device can detect if the message is to be read or ignored. However, because any device can transmit packets to another device at any time over shared electrical conductors, packets can be corrupted when two devices transmit simultaneously on a shared link.

Simultaneous transmission creates a collision on the network. The error-checking code embedded in the Ethernet frame guarantees that corrupted data is detectable and thrown away, though it is up to higher level protocols to ask for retransmission.

Ethernet is physically connected in a star topology, where each device is the tip of a star, the center of each star is a network switch or hub, and the connection from tip to center is a cable.

The cabling is most commonly a Category-5 or Category-6 cable with four twisted pairs of conductors terminated into an RJ45 plug. The Cat5/6 distinction is based on transmission speeds. Cat5 cabling is rated for up to 100 BASE-TX transmission speeds; Cat6 has a heartier construction that can be used for Gigabit Ethernet. Standard cabling uses UTP cabling, or Unshielded Twisted Pair, but shielded cabling can be used for better noise immunity. Backstage, we’ve also found shielded cabling holds up better to the physical abuse of being dragged across the floor and dumped into cabling bins. The slight increase in cost can be a worthwhile investment because of the increased lifespan.

The pinout of a Cat5/Cat6 cable is:

Cabling can be made from bulk UTP and RJ45 plugs or purchased in pre-made lengths. There are some reasons why you may want to build the cabling yourself, though given the high quality and low price of commodity pre-made cables, those reasons should be scrutinized. Ethernet is robust, but no network can tolerate poorly made cables. The electricity must flow unimpeded from one connection point to the next, or even the best engineered protocol won’t be able to keep a reliable stream of data. We have flown technicians across the country to troubleshoot networking issues in theatres only to discover that cables made by stagehands, theatrical carpenters, and stage electricians were to blame. Poorly made cables are a scourge of networking and frustratingly unreliable. If, despite those hard-won words of warning, you really want to build your own cables, invest in a high-quality network cable tester that can identify mis-wired or poorly made connections.

Old networks may use a coaxial cable and high-speed networks may use a fiber optic link for transmission, though neither is common in backstage automation.

The centers of the network stars are switches, or, less commonly, hubs. Though spoken of interchangeably, and identical in appearance, the two devices are mightily different. The devices both look like unimpressive slim boxes with a row or two of RJ45 jacks and a power inlet.

Internally, an Ethernet Hub will broadcast every transmission sent from one device to all connected devices. The Hub leaves it up to each network node to determine whether the network packet is relevant. By contrast, an Ethernet Switch examines the packet traffic and determines what MAC address is connected to each RJ45 jack. Once the switch has a table of data that maps MAC addresses to physical jacks, it can efficiently route packet traffic so that packets are only sent to the intended recipient, rather than flooding all nodes with irrelevant traffic that may slow down throughput. These days, hubs are rare and any new purchase will be an Ethernet switch.

Ethernet switches come in a variety of sizes with physical port counts ranging from four to over 50. Switches can connect to other switches to distribute networking signals across a large number of devices. For small networks with fewer than a few hundred devices, unmanaged switches are plug-and-play devices that conduct network traffic without any configuration. For larger networks, or networks that require isolation or monitoring of packets, a managed switch can be used. Rarely necessary in the small networks backstage, managed switches can give you some granular control over which IP ports take priority on the network (more on IP ports soon).

When connecting just two devices over Ethernet, you can forgo using a switch. To directly connect between two network devices, the transmit wires on the first device need to connect with the receive wires on the second, and the receive wires on the first device need to connect with the transmit wires on the second. A network switch will correctly transpose these signals and many modern computers will auto-negotiate a direct connection. If you have an older computer that cannot negotiate a direct connection, or a small device that doesn’t support direct connection, a crossover cable that has the wire pairs flipped on one RJ45 plug can be used for a direct connection.

Ethernet’s ubiquity as the backbone of both local networks in homes and offices, and the internet, has made the hardware cheap and easy to buy. The affordable price of the network components has made the interface available in devices of all sizes. Because of the billions of devices relying on Ethernet for communication, the engineering effort placed into this network protocol has made it unbelievably stable. This rock-solid foundation is an attractive base upon which higher level protocols can be built to tailor fit it for different uses.

TCP/IP

TCP/IP are a suite of protocols that sit atop Ethernet and leverage the existing structure to build more functionality into the network. The three protocols of the TCP/IP suite are TCP, or Transmission Control Protocol, IP, or Internet Protocol, and UDP, or User Datagram Protocol. IP adds another addressing scheme on top of Ethernet, the familiar IP Address. You may be thinking, But Ethernet already has addressing, why do we need another addressing scheme? While it’s true that Ethernet uses MAC addresses for routing packets at the link layer, a logical address is a useful abstraction for the destination of an information stream to a host that is independent of the physical hardware. Put simply, if a computer breaks, it is convenient to swap in a new computer with a different MAC address but assign it the same IP address as its predecessor so it can assume the role.

IP addresses come in two flavors: IPv4 and IPv6. IPv4 address are 32-bit numbers, most commonly represented in dotted decimal notation such as 192.168.10.1 or 10.0.1.25. Each segment of the address is a byte with a valid range from 0 to 255. The number is broken into octets for easy human readability. As a 32-bit value, there are a possible 4,294,967,296 unique addresses, minus some that are reserved for special meaning. This seems like a lot of addresses, but with a growing number of computers, personal devices, and appliances on the internet requiring unique addresses, space is running out. IPv6 brings 128-bit addressing, which allows for 2¹²⁸ addresses (a lot!). I won’t say more about IPv6 since it is not necessary in the small internal networks we use on stage. IPv6’s real value is in connecting hosts on the internet that handle traffic and pass it along to smaller networks.

Since IP addresses are used for both local networks and the internet, there are ranges of addresses reserved for private use. The private network ranges are not routed over the internet and are intended to be used inside local networks. The ranges are:

Given the small size of our networks, we usually stick to the smallest range of 192.168.0.0 to 192.168.255.255. These addresses can either be manually set, called a Static IP Address, or assigned dynamically by a DHCP server that exists on the network. A router can act as the DHCP server on small networks (though in practice static addressing causes fewer headaches in automation networks). A router is a network device that sits between a private network and the internet. Its job is to present a single IP address to the internet while transferring data back and forth across the boundary to all the computers on the private network. Each computer on the private network that wants information from the internet sends the request through the router, the router wraps the request in a datagram with its IP address and remembers which computer should get the response when it comes back over the internet.

The IP packet is contained inside an Ethernet frame as its payload. The IP packet contains the IP address of the sender and destination host. The IP packet can travel across network boundaries to find the destination. The path taken to get to the host is not guaranteed to be the same from one packet to the next. Oddly, it is also not guaranteed to arrive in the same order as sent, or to arrive at all. It is referred to as a “best effort” protocol but without delivery guarantee. This seems pretty disturbing, but another protocol can be layered on top to correct for those deficiencies.

TCP uses the IP addressing scheme and datagram format to transmit a stream of data that guarantees proper ordering and delivery. Data delivery is confirmed to the sender, transmissions will be automatically resent if packets are dropped; if the transmission is undeliverable a failure is reported so that the host that sent the data can take appropriate action. Corrupted data is detected and automatically resent so that an application program built using TCP does not need to worry about data integrity, that is guaranteed by the protocol. The cost for this integrity is time. It takes additional time for the protocol to provide error correction and retransmit however many applications value data integrity over absolute speed. The Web, email, and FTP are common examples of applications that rely on TCP since the data integrity is paramount.

Ethernet and IP addresses deliver bytes from one device to another. However, it is applications that require the transport of data and there may be many different applications running on a device that need access to the network facilities. TCP introduces the concept of a port that is used in conjunction with the IP address to designate a communication channel to the specific application on the device that is requesting network data. The combination of an IP address and port is called a socket. An application opens a socket by specifying the port number to be used for communication with another device.

Port number are 16-bit values that range from 0 to 65,535 with certain values reserved for well-known protocols. Port 80 is used for HTTP traffic, FTP uses ports 20 and 21, SSH uses port 22, etc. On Unix systems ports below 1024 are reserved for root privileges.

Sockets are designed for client/server applications. A server socket listens for incoming requests and will respond once received, a client socket will send a request to a server. Beyond that initial state, a server awaits requests and a client initiates the conversation with a request, the difference between client and server is semantic. Once the sockets connect, both ends of the connection have each other’s IP address and either can initiate the next message. The client/server rules only govern how the conversation starts but once the sockets connect the data can flow either way depending on the application protocol. It’s tempting to think of servers as being large rack-mounted PC’s, but a server can be a tiny little 8-bit microcontroller listening on a TCP port to serve up a few bytes of data from a single sensor to any interested client.

UDP

User Datagram Protocol, or UDP, shares the same IP addresses and port numbers as TCP but does away with the data integrity features to obtain the fastest transmission speeds. Applications where a little bit of corrupt or missing data isn’t a problem can take advantage of the higher speed to get better performance. Streaming video and audio are good examples of cases where getting data transmitted quickly trumps the need for data integrity. A few dropped audio samples will produce better sound than a stuttering feed. The rate of transmission is more important than guaranteeing that all the data is received. This stands in contrast to a network file transfer where getting the bytes out of order, or missing the middle few bits renders the process useless.

Depending on the application, TCP or UDP can be chosen to satisfy the design goals and it is usually pretty clear which choice makes more sense. For example, the Spikemark^TM automation software uses TCP to communicate with all motion controllers because it is important to make sure the correct data is sent in the correct order when commanding motors to move. However, Spikemark^TM uses UDP to stream motor information to media servers that want to map projections onto moving scenery since the speed of transmission is important to keep the video moving smoothly and dropping a frame or two isn’t catastrophic.

To get a glimpse of the networking details on your computer, open up a terminal window and run a simple program to see what network interfaces are installed, the MAC address and the IP address of each interface. On Windows, run CMD.exe and then type:

The report that is created shows the MAC address under the heading “Physical Address” and the IPv4 and IPv6 addresses for the network adapter.

On the Mac, open Terminal and type:

ifconfig

The report shows the MAC address under the heading “ether” and the IPv4 and IPv6 addresses for the network adapter listed under the heading “inet” and “inet6” respectively.

Industrial Network Protocols

Ethernet, TCP/IP, and UDP were developed to connect computers in client/server applications to exchange data for information processing across many computers that were separated by feet or miles. Industrial protocols were developed to connect processing controllers to sensors or slave controllers in supervisory control and data acquisition (SCADA). Manufacturing plants and remote equipment monitoring are common examples where an industrial protocols are used. Industrial protocols have been evolving since the 1970s to solve the problem of making a large, distributed network of sensors and actuators appear as one unified machine to a central processor.

Modbus/Modbus-TCP

Modicon developed the PLC in the 1970s and along with it developed a serial protocol to communicate from a master control device to slave devices in 1979. The Modbus protocol makes it possible for a Modbus Master to read and write values in the memory locations of Modbus Slaves. The original protocol was designed in two parts: an application protocol (layer 7), and a serial protocol using RS485 for data link layer (layer 2). As Ethernet became more prevalent and less expensive, the Modbus TCP protocol was developed in 1999 to address some of the original transmission limitations while keeping the application protocol intact. Though the Modbus TCP protocol is more expandable and faster than its legacy serial counterpart, both are still in wide use even in new equipment.

The Modbus application protocol is built for master/slave communication. The master is a computer or PLC that oversees all processing and collects information from the slave devices as needed.

The slaves respond to a request for data, or a command to alter their output, but otherwise stay silent on the network. Every direct request to an individual slave warrants a response so the conversation takes place in lock-step: request, response, request, response, etc. This is referred to as unicast mode, a direct conversation between the Modbus master and one slave device. In broadcast mode, the master will send a single request that is received by all slaves, but without any response. There isn’t any provision for a slave to initiate a communication upstream to the master. For instance, if a limit switch was detected by a slave control it cannot poke the master cue control to inform it of the event. Instead, the master must continuously poll the slaves to get status updates.

The message of a Modbus command is contained inside a Protocol Data Unit, or PDU for TLA (three-letter acronym) compliance. The PDU is limited to 253 bytes because of the historical implementation on RS485.

It starts with a function code (1 byte) and then the data for the function (0 to 252 bytes), we’ll discuss the missing 3 bytes later. Showing its roots as a PLC protocol, Modbus describes all data in terms of Coils, Contacts, and Registers. There are four tables of data: discrete output coils, discrete input contacts, input registers, analog output holding registers. Coils and Discrete Inputs are single bit values: on or off. Coils represent an output switch, while Discrete Inputs represent input switch. Registers hold 16-bit words that can be used to set a value range from 0 to 65,535. These values could represent an analog sensor input, or an analog output like a speed command. Output coils and output holding registers are meant to be set by the master, so their state can be both written to alter state and read to check state. Input contacts and input registers are meant to read the status of external sensors, so their value can only be read. Each value in the data tables has a numeric label that is distinct in the device and a memory location that is relative to its table. The map of labels and memory locations in the traditional protocol is defined in the specification.

The current Modbus specification actually defines addresses up to 0xFFFF, but in practice some devices still limit the address range to 0x270E. The documentation for your specific Modbus device will clarify what are valid addresses for that piece of gear.

The address values in the table above are given in hexadecimal notation. You’ll find hex notation is used often in code documentation because it can express a byte in two characters. Hexadecimal is base 16, which means that each digit in a number can represent values from 0 to 15. Since we run out of decimal values after 9, the letters a–f are used. If that sounds a bit confusing, let’s map hex values to decimal values to make it a little clearer.

If you continue counting the value 255, one byte, can be written as ff in hexadecimal notation. Why is it worth the confusion of mixing letters and numbers? Consider the decimal value 23,367. How many bytes are required to hold this value? It’s not immediately obvious when formatted in decimal notation. However, when viewed as the hex value 5B47 we can see immediately that it requires two bytes since each pair of hex values define a byte. In code, and documentation, to clarify that a number is represented as a hex value it is preceded with 0x, or sometimes followed with a “H.” So the value 0x10 is the hex notation for the decimal value 16. If you want to convert values, open up the calculator app on Windows or Mac OSX and switch to programmer view. Type in a number and flip between hex and decimal modes.

The Modbus serial protocol comes in two flavors: Remote Terminal Unit (RTU) or ASCII. RTU represents all information as binary data sent in two-byte pairs so the hex values are transmitted in their pure binary representation. For instance the value 0xFFFF would be sent as 111111 111111. The ASCII version transmits the data as string representations of the hex value. Since each ASCII character requires a byte of binary data, a two-character hex requires four bytes to transmit. Rather than transmitting 0xFFFF as two binary bytes, it is transmitted as the literal letters “FFFF” in ASCII code. The ASCII code for the letter “F” is 0x46, so the value transmitted for “FFFF” is 0x46464646. Since the ASCII version takes double the data to transmit each value it is naturally less efficient, however it has looser timing requirements than the RTU version so it’s used in devices that have less processing power where keeping up with the tight timing of RTU is too burdensome.

There are a handful of functions defined in the Modbus specification to read and write values into the four tables of data. Each function is described with a single byte (represented in hex below) that precedes the data in the PDU.

As an example, if we wanted to turn on the third output on a PLC, the PDU would be constructed as such: 0x050002FF00. Modbus uses ‘big-Endian’ representation, meaning the most-significant byte (leftmost) is transmitted first. The first byte, 0x05, is the function code. The next two bytes, 0x0002, are the address. We want to turn on the third output which is address 2 (0, 1, 2…). The last two bytes, 0xFF00, is the format specified to mean ON. If we wanted to turn the output off we would use the value 0x0000. The Modbus specification has the PDU format for all of the functions.

The PDU is wrapped by the Application Data Unit, or ADU. The ADU adds addressing and error checking to the PDU. The format of the ADU varies depending on the transmission method. RS485 serial does not provide any address service or error checking for data integrity, therefore the serial Modbus protocol adds those features in the ADU packet format.

The first byte of the packet contains the destination address. The serial version of Modbus supports a single Master and up to 247 Slaves addressed from 1 to 247. The address 0 is reserved for the Master and used to broadcast a message to all Slaves on the network. Addresses 248–255 are reserved and can’t be used. The address byte is sent first so that every slave on the network can discern whether or not it needs to listen to the rest of the message. If the packet is not bound for a slave, it can disregard the packet and not waste any processing time decoding the rest of it.

Directly after the address byte, the PDU is sent with the function code and data. Following the PDU is a CRC error check code. The sender calculates the CRC code, and the receiver analyzes the data to calculate a CRC and compares it to the code sent. If the codes match, the data is good; if the codes differ the data is garbage and discarded. Since every request gets a response, if the Master does not receive a response after a specified time it can assume a transmission error and resend.

The more modern Modbus TCP protocol keeps the same application protocol, but uses TCP/IP over Ethernet for transport. Since TCP/IP provides addressing and error checking with automatic retransmission, those features of the older serial Modbus protocol are not needed. Instead, Modbus TCP utilizes the underlying protocol which both simplifies and expands its capabilities. Rather than being limited to 247 slaves, the IP address space is practically unlimited giving Modbus huge new capacity. The PDU portion of the protocol packet remains unchanged, but the ADU is changed to reflect the new transport layer. Rather than preceding the PDU with an address byte, the PDU comes after a Modbus Application Protocol header, or the catchy MBAP abbreviation.

The MBAP header as the following pieces of information:

The terms used for devices in Modbus TCP changes to client/server from master/slave. The devices that await incoming requests are servers, and the devices making requests are clients. Unlike the serial protocol, a server may accept multiple requests before returning a response. To identify the request, the Transaction ID should be sent as a unique identifier for each request the client makes, and the server should echo it back. The Protocol ID confirms that this packet, which may be on an Ethernet network shared by other fieldbuses, is a Modbus transaction. The length field specifies how many bytes follow in the message. Lastly the Unit ID is used in case the Modbus server is acting as a gateway, or bridge, from Modbus TCP to Modbus serial. When acting as a gateway, slave devices are attached to the server and relay their transactions through the gateway over RS485 links.

Modbus has a long history and is well established in automation equipment. The standard is free to implement, and the serial version is often included in amplifiers and PLCs at no extra cost. The serial version is limited in speed and expansion, both of which are improved in the Modbus TCP protocol. The application layer is designed only to transmit requests from the master to the slave, it lacks the ability for the slave to interrupt the master with important event information relying instead on the master to poll frequently enough to capture the event. This fundamental limitation is addressed in other protocols.

CAN/CANopen

The Controller Area Network, or CAN, was first developed in the 1980s by Bosch as an in-vehicle network to facilitate communication between the menagerie of microcontrollers and sensors used in cars and trucks. From its inception, it focused on high-reliability and quick, short communication packets because of its use in timing critical vehicle systems. The CAN bus is a 2-wire, differential signal, terminated with resistors, where short stubs connect device nodes on the network.

The basic electrical layout is very similar to RS485. Each node requires a dedicated CAN transceiver that handles getting bits onto, and off of, the bus. The CAN controller chips take care of error detection within hardware making it possible for very low-power microcontrollers/microprocessors to communicate over the bus being relieved of the burden of insuring data integrity. The CAN bus specification is merely hardware-oriented, filling in the responsibilities of lower layers in the OSI network model.

The CAN bus is capable of speeds of up to 1 Mbps when the length of the bus wire pair is limited to 25-meters. Lowering the transmission speed will allow for longer lengths, up to 5 kilometers at 10 kbps. The messages passed over the bus are relatively short, up to 8 bytes of data with an 11-bit ID header and additional bits for error checking.

The bus is intended to be used as a multi-master network, where any node can initiate a transmission to another node. Data collisions and corruptions are handled efficiently in hardware with resending of lost or damaged packets occurring automatically.

The CAN in Automation group (CiA) was formed in 1992 to create standards that promoted the use of the CAN network. CANopen is one of several application protocols built atop CAN that adds significant structure to the electrical format. CANopen is, as the name suggests, an open protocol that has been widely adopted in automation and embedded control systems. Unlike Modbus which treats every device as a bank of memory and leaves the logical meaning of those memory locations up to the manufacturer, CANopen describes rich models of different devices used in common automation applications such as motion controllers, sensors, and encoders. Each type of device has a specification that describes common behavior and a standardized protocol for operation, while still allowing for additional customization for manufacturer-specific features. For example, every motion controller operates by taking a target position, velocity, and acceleration, but each manufacturer has a slightly different syntax to program these values. To be CANopen-compliant with the motion controller spec (CiA 402), the motion controller must implement a standard command structure that is manufacturer agnostic. This way two CANopen motion controllers from different manufacturers could be swapped out without altering communication software. This philosophical goal permeates the CANopen protocol establishing a generic interface for a wide range of devices. Here are just a few of the existing specifications:

To accomplish this fabulous feat of automation abstraction, CANopen introduced the concept of an Object Dictionary. Every device type has an Object Dictionary that describes its basic properties such as manufacturer and device name along with configurable parameters like the network node id and communication bit rate. The memory location map for all of these parameters are well defined and discoverable by reading the Electronic Data Sheet, or EDS, as described in CiA-306-1. The EDS may be stored on device, or published separately via URL.

To send information between nodes on a CANopen network, messages adhere to the CAN format.

An 11-bit ID field followed by 0 to 8 bytes of data payload make up the meat of the message. The 11-bit ID field is divided into a 4-bit function code and a 7-bit node id. There are 15 functions defined for reading and writing data, configuring the network, synchronization, and emergency errors. The 7-bit node id allows for 127 devices to exist on the network with a node id of ‘0’ reserved for broadcast messages. CAN prioritizes packets with lower identification values, so time sensitive functions, such as reporting encoder position or executing the start of a movement, are given lower function codes than configuration commands, insuring that timing needs of the system are met.

Data is delivered either through a Service Data Object (SDO), or a Process Data Object (PDO), depending on the timing requirements for the data delivery. SDOs are used to set configuration parameters in the device’s Object Dictionary. This format can handle data that exceeds the 8-byte limit of the CAN frame, but requires more time to segment the message from the sender, and more time to reassemble the message once received. PDOs are used to transmit real-time data either needed by device, or produced by the device. For instance, when using a CANopen absolute encoder the bitrate and node-id is set by SDO messages since the message isn’t timing critical and could require more than the 8-byte data limit, but the encoder position generated as the shaft spins is sent by PDO messages since the timing is critical for proper operation of other components that are relying on this data, such as a motion controller.

As a multi-master network, CANopen is not limited to Master/Slave communication of Modbus, though it can execute in that model when convenient. The network devices can also operate in Client/Server mode where a node answers requests from multiple clients. A device can also be a Producer that generates messages read by multiple Consumers. Imagine a single positioning encoder that is pumping out position data. That data could be consumed by a nearby motion controller that is dedicated to keeping an amplifier on target with a PID loop for a single machine. At the same time, another supervisory controller that is synchronizing motion between multiple machines could consume data from several encoders and manage the group of motion controllers.

CAN is a somewhat unassuming data link protocol, but the CANopen application protocol builds on the underlying robust data transmission with a rich model of abstract automation devices. These standardized descriptions of components make it simpler for the end-user to integrate pieces without relying on a single-vendor automation solution. This end-user simplicity is facilitated by a much more complex series of specifications that each manufacturer must implement to achieve standards compliance. Those specifications are beyond the scope of this book, but worthwhile of your time if you are interested in using CANopen devices. The two most severe limitations of CANopen are the 127-node limit and the 1 Mbps transmission speed at short distance (and worse at longer distances). These limitations are serious detractions if you were planning to build an entire stage automation system on CANopen, but it still has use for building small, self-contained networks inside a larger architecture. For instance, a motion controller may communicate with the VFD and encoder via CANopen, but relay information to the Operator Interface over TCP/IP.

PROFIBUS/PROFINET

After the introduction of Modbus by Modicon in the late 1970s, in the 1980s 21 German companies and institutes banded together with the singular purpose – to create a richer fieldbus for connecting controllers and devices. The resulting protocol, PROFIBUS, shares some of the same foundational philosophy of Modbus, such as master/slave architecture and remote I/O mapping, but adds significant improvements with device profiles that standardize behavior for families of devices. The device profile standards in PROFIBUS appear to be a conceptual ancestor to the CANopen object dictionaries and both address the same shortcoming of Modbus which does not make an effort to standardize device mappings.

Fundamentally, PROFIBUS is a master/slave protocol. A single master controller has an array of slave devices that are dormant until commanded to respond. Slave devices cannot initiate a conversation, instead the master device must poll constantly to catch changes in each device. Several PROFIBUS masters may exist on the same network. Control of the data bus is negotiated by passing a token packet from one master to the next. Whichever master holds the token commands the bus. When one master is done, the token is passed to the next master controller.

Slaves must have a unique network ID to figure out if a data message is intended for them, or if the data is meant for another device on the network. A maximum of 126 devices, including the master, can be addressed with values from 1 to 126. Typically, device IDs are set with thumbwheels or rotary DIP switches. Most commonly, PROFIBUS is transmitted over RS485, although the standard specifies several other data link options. The RS485 topology is the same as Modbus: line with stub connections. A maximum of 32 nodes per line segment is allowed. To expand beyond 32 nodes, repeaters are required. The end of each segment must terminate the balanced transmission lines with a resistor. Maximum transmission speed over RS485 is 12 Mbs. By now, this physical network layout should sound terribly familiar.

At the base of the application protocol stack is PROFIBUS DP, which stands for Decentralized Peripherals. PROFIBUS DP describes the data exchange between master and slave devices. The DP protocol allows the master to map remote devices into its own logical processing space, making the physical distance melt away. The system programmer can pretend that the network of remote devices is directly connected to the master and instantly addressable. Unlike Modbus, where these remote devices appear as nondescript memory locations, each PROFIBUS device includes an application-specific profile. This profile is documented in a general station description file, or GSD. The GSD file can be downloaded from the manufacturer’s site and then analyzed by the PROFIBUS master configuration software to map remote devices. A PROFIBUS master (PLC) requires a configuration utility that can be run by a PROFIBUS supervisor (PC) for initial setup and diagnostics. Upon power-up, the master will attempt to communicate with the remote devices that were previously configured.

Once all devices are up and running, the PROFIBUS begins polling each node in order for status updates of all input and setting any output data. Nodes respond in succession, each taking turn, dutifully responding to the master’s request. In addition to cyclical polling, PROFIBUS DP has allowance for acyclic messages, or event-driven messages, sent from the master to the slave. These acyclic messages can be used to set configuration parameters on slave devices.

To meet the needs of more sophisticated devices, the PROFIBUS DP protocol has evolved into three versions. Devices must support at least the lowest version, and additional features of the protocol are available at successively higher implementation levels.

Building on the communication protocol of PROFIBUS DP, application-specific profiles exist for common device types to establish a standard language and data format for the uniform functionality shared between devices of the same family, regardless of manufacturer. Here’s a sampling of those profiles:

Note that the PROFIsafe profile makes it possible for safety systems up to SIL3, such as Emergency Stops and interlocks, to be connected over the same network bus as the rest of the system. This functionality is not available in other protocols we’ve reviewed so far and represents a sizable advantage. Attaching safety systems to the main network reduces cabling and makes it easier to show safety status in the operator interface using the same programming tools.

To take advantage of the expanded addressing and ubiquitous Ethernet hardware, PROFINET was introduced early this century. It builds upon many of the ideas of PROFIBUS but engineered to run on Ethernet and take advantage of standard Ethernet higher level protocols such as TCP/IP and UDP. For addressing, PROFINET requires a distinct name for each device in addition to the MAC address and IP address. Another change from PROFIBUS is the adoption of XML for the format of the GSD, which is a more modern, idiomatic format in IT networks. PROFINET leverages TCP/IP for non-real-time tasks, but for timing-critical operations, such as motion control and input capture, it uses the PROFINET-RT protocol embedded standard Ethernet frames.

PROFINET has only a fraction of the installed base of PROFIBUS, but it seems likely that the advantages of Ethernet will gain momentum with each passing year. Siemens is deeply engaged in the development and evangelizing of both PROFIBUS and PROFINET. As a powerful leader in automation technology, their backing will surely continue to spread both technologies.

EtherCAT

Beckhoff Automation was formed in 1980 and began building PC-based control systems with hardened components that could out-perform traditional PLCs in their speed of operation and unmatched programming flexibility. Early in this century, they began focusing on the creation of an Ethernet fieldbus that would have very fast, predictable timing characteristics with practically limitless expansion. Their EtherCAT protocol was introduced in 2003 and made into an open, international standard in 2007.

EtherCAT is a master/slave protocol. All bus timing is controlled by a single master that sends data packets to network nodes. Focused on speed, the EtherCAT protocol uses raw Ethernet frames but eschews existing TCP/IP and UDP protocols in favor of its own datagram format. Most data passed between nodes is relatively small – in some cases just a single bit or byte to report the status of a simple input. Rather than sending individual Ethernet frames to each node, a single mega-packet is sent serially through the entire network with all of the data for every node. Each node analyzes the packet and passes it on byte by byte without stopping the transmission. If there is a pertinent datagram, the node acts on the instruction and inserts the response midstream. When the end of the network is detected, the packet is returned to the master so it can pull out any data ready for retrieval. The protocol operates like a train rolling through stations but never stopping, passengers just jump on and off the cars. It is stunningly efficient, able to process 1000 digital I/O points in 30 us.

To support this midstream packet manipulation, EtherCAT devices require special hardware. Each node is equipped with an input RJ45 jack and an output RJ45 jack that are managed by a dedicated EtherCAT control chip. This specialty hardware relieves the node processor of transmission duties and replaces the need for extra networking gear. EtherCAT supports just about every network topology, but if the network is laid out in a line, or bus, you can daisy-chain from one node to the next without any more networking gear. EtherCAT switches can be used to create branch and star topologies, which can be intermingled with line segments.

EtherCAT can support up to 65,535 devices. EtherCAT does not use IP addressing, instead each device has a network identifier that is either assigned by the EtherCAT master, or explicitly configured in the node. If using implicit addressing, the EtherCAT master will assign network IDs based on the node’s location in the network. Hot Swap addressing makes it possible to remove and add network devices as well as manually configure network IDs.

System configuration is specified in a configuration tool for the EtherCAT master. When using a PC from Beckhoff, their TwinCAT development tool is most commonly leveraged to lay out the system. In addition to mapping device locations on the network, device profiles are used to determine what features are available. The CiA object dictionaries are used just as in CANopen, to load the feature set of drives, encoders, etc.

EtherCAT was designed from the outset as a protocol for high-precision, synchronized motion control. In a complex system, whether in a factory or on stage, the motors used in synchronous motion may be separated by hundreds of feet. The length of copper wire between devices makes a single clock signal impractical since the propagation delay and possible interference become problematic. EtherCAT instead uses distributed clocks in each motion device that are calibrated with each packet. Timestamps are imprinted on the packet by the first slave clock and subsequent slaves downstream adjust their clocks to match. Since there is a propagation delay as the packet winds its way through the network, the EtherCAT master measures the delay at system startup and informs each slave how to adjust for the timing difference. This mechanism makes it possible to achieve synchronization between axes of 1 microsecond or less.

Safety over EtherCAT makes it possible to network Emergency Stops and safety interlocks over the same network as the rest of the system devices.

EtherCAT’s efficiency makes it possible to transmit other protocols over the network without impacting core performance. TCP/IP, CANopen, and Sercos datagrams can be sent simultaneously. Hardware gateways can also bridge between EtherCAT networks and PROFIBUS, PROFINET, DeviceNET, and others. It is an impressively robust fieldbus and is making substantial in-roads in our industry.

Proprietary Application Protocols

In 2016, I was on a USITT panel that presented a session discussing industrial control networks. The other two folks on the panel were Michael Lichter of ETC Rigging and Joe Jeremy of Niscon. In preparation for the session, the three of us got together to chat about what protocols our respective systems used. Laughably, it turned out that we all had developed proprietary protocols years ago instead of building our systems around an existing protocol. Creative Conners and Niscon both chose to implement custom application protocols on top of TCP/IP and UDP, while ETC Rigging built a protocol on top of RS485. Having spent so many pages discussing industrial fieldbus protocols, you might wonder why none of us would have adopted an existing technology.

First, a disclaimer: all of the Ethernet-based fieldbus options have become significantly more mature since Niscon and Creative Conners were developing systems, and some of those design decisions might be different if starting over today with a blank slate and no installed user-base to support. However, even excepting historical inertia, there are some challenges adapting industrial protocols to theatre automation.

The industrial protocols we have reviewed conceptually imagine the facility as one large machine with a single control brain. When building a production line in a factory that will be in service for years, this makes a lot of sense. Spending the time for a detailed configuration that maps each remote device into the logical processing space of the controller makes sense. Furthermore, the heterogeneous mix of sensors and actuators used in the automation of a brewery and bottling plant benefits from the flexibility afforded from device profiles in PROFIBUS or EtherCAT. By contrast, theatrical automation requires rapid setup and reconfiguration. An overwrought configuration process that requires specialty software is burdensome. If a winch is added during tech, reconfiguring the network shouldn’t require more than a few clicks that can be handled by the automation operator. Though we need to be able to add and remove and rearrange machinery, our arsenal is homogenous. Each hoist has a motion controller, amplifier, encoder, and limits.

That Lego-brick of stage mechanization is repeated dozens, or hundreds, of times for a production but it’s all the same basic stuff. When something exceptional is required, the system needs to be capable of handling it, but not at the expense of ease of use.

The Creative Conners Stagehand protocol is built on top of TCP/IP. It is a client/server architecture. Each Stagehand acts as a server awaiting a client request to either perform a movement or report status information. The messages are sent in ASCII text, delimited with a special character to indicate end of transmission. There is no provision for the Stagehand to push data up to the client; instead, the client must poll to for updates. However, all high-speed operations are handled locally in the Stagehand with discrete wired connections. Limit switch detection, encoder capture, and PID loop are not managed by the client. The client is typically just commanding the start of motion when cues are run, and then requesting status updates fast enough to refresh the Operator Interface. By pushing the high-speed processing into the network node, the Stagehand is reasonably autonomous whether connected to the network or not.

Leveraging the existing Ethernet protocols, the Stagehand addressing is done with static IP addresses. Data error detection is handled by TCP/IP. UDP is also used to facilitate over-the-network firmware upgrades. The entire protocol description fits on a couple of pages and is tuned to do just the work we require. It is expanded as needed, and altered when limitations become painful. That level of control is attractive and I know it also played a role in my peers’ decision to roll their own protocols. The downside is primarily that all the engineering to develop and maintain the protocols, as well as the custom hardware and software that use the protocols, must be done by much smaller teams than are available in the industrial automation companies. Engineering is all about compromise, and custom protocols trade effort for control.

Tower of Babel

When considering what protocol should be employed to solve an automation problem, it is important to realize that often multiple interface protocols are used within a system to achieve the desired result. For example, in 2016 Creative Conners set out to build a lower-cost Stagehand motor controller named Stagehand Apprentice. The Stagehand Apprentice uses Ethernet with TCP/IP to communicate with the Operator Interface. For speed control during cues, while running a PID loop, it describes the speed command signal with discrete wires directly to the VFD. To retrieve VFD status information, it uses a Modbus link over RS485 and packages that data up for transmission over TCP/IP.

If you peel back the layers on other systems, you may find that CANopen is used for speed control between motion controller and amplifier, but data exchange between controller and operator interface is passed over UDP. Using different protocols either because one is a better fit, or simply because one is available, is a practical way to build a system.

Final Thoughts on Networks

Understandably, you may wonder how to pick the right protocol for a task. The unsatisfying answer is, “It depends.” If you already have a system, or are buying a new turn-key system, then that question is answered already and you should read up more on that protocol. If you are buying components to integrate yourself, then hopefully the survey provided in this chapter shows you that there isn’t a bad choice until you hit the extreme limits of any of them. I think these days, if you are developing either a new system or a mildly complex standalone effect, you would need a justification to use something other than EtherCAT. The protocol is impressive and it is rapidly being adopted by most manufacturers of controls, sensors, and amplifiers. Beckhoff’s TwinCAT environment is an enjoyable blend of PLC programming and Windows development. The next decade will be an exciting time in automation, and I bet EtherCAT will become much more popular on stage.