Network protocol is more than a port

Controls engineers are surrounded by protocols. Proprietary protocols are less common today than before, but they are still around. Many of the protocols being implemented today are non-proprietary and people confuse that with “open.”

Regardless of the label or whether it’s proprietary or not, controls engineers need to understand protocols when instruments or systems fail, or when you are putting a system together. Which protocols are being used is paramount for future expansion or integrating with an older system. Integration, after all is the hardest part on startup, if a device and controller will not talk.

Communication is key between engineers, as well. For instance, if you ask for the specification sheet on a linear variable differential transformer (LVDT) and get handed the specification sheet with the synchronous serial interface (SSI) protocol and not the Ethernet industrial protocol (Ethernet), and no one wrote a controls functional specification, so there is no roadmap as to how the control system is being developed or programmed, then it is easy to think the LVDT with the SSI spec sheet is wrong, not because it’s the wrong LVDT to choose, but because the systems engineer might have thought that all the LVDTs in use would be Ethernet. If an engineer browses the protocols available for LVDTs, it’s possible to find LVDTs with four different options for protocols.

How does choosing a protocol affect the engineering process flow or maintenance? It is easy to get the wrong hardware installed because of the connector on the end, based on the protocol chosen. The differences might affect design, operations and maintenance.

SSI is used to provide fast, direct, reliable position feedback. It is synchronous and unidirectional, while Ethernet is bidirectional and is a bus/network system. Like any protocol, SSI’s speed is subject to cable length. Lower speeds allow for longer cables. SSI can support longer cable lengths.

SSI typically operates at 10 Mb for short distances. SSI is going to transmit the position data and nothing else. Ethernet will send detailed diagnostics including temperature, velocity and multi-turn position data. SSI utilizes four to six wires for a single encoder and Ethernet is eight wires. Ethernet is networkable and addressable. SSI is direct wire, requiring an RS-422 (TIA/EIA-422) wiring scheme connector. Both can utilize an M12 connector, so they can be used in harsh environments.

Thus, is there a real difference between SSI and Ethernet? Diehard traditionalists will use SSI because it’s historically stable for encoder data, and SSI can provide a granularity that is 0.1 micrometers and Ethernet is 1.0 micrometer. Ethernet has been stable for the past 20 years. SSI will require specific cards to read SSI in the controller rack for each circuit. Ethernet components can come in on your network card. But which network?

Get your subscription to Control Design’s daily newsletter.

For instance, putting servo feedback on the same network as a bunch of drive traffic or HMI data is not advisable. This is why the SSI circuit may be more precise, due to its isolation.

In general, the protocol chosen is not an isolated decision. The engineer needs to consider the application, look at the distances and the environment and consider the speeds, flexibility and cost of the proposed protocol with the application. Security and network architecture may also be factors. Is the infrastructure in place, for instance? Maintenance should be considered also based on changing out cables and understanding spares and availability. The Temposonics R-Series absolute linear position sensors, for example, utilize the common industrial protocol (CIP) over standard Ethernet for high-speed, robust, real-time position feedback in automation. These sensors are used for precise measurement in harsh environments. In this example, the Temposonics sensor may have everything relatively the same, except the last digits on the part number and the card in the housing that the cable connects to. The signals coming in may also be different. Do you have the drivers available in the PLC software application to delineate?

How do you tabulate protocols and wiring configurations and the drivers required? The controls technical specification should describe the hardware and the protocols used to build a system—that is, components, architecture and code. The functional specification should detail the control strategy, sequences and I/O mapping. The operations specification would be how the operator uses the machine.

If a controls engineer wants to decrease commissioning time before programming, then they will understand the system hardware, which protocol it’s communicating with, why it was chosen and how to implement it in the system and test it, before commissioning. It’s important to have the hardware, code and necessary test devices and test steps in advance of commissioning to alleviate confusion during startup.