Maximizing Flexibility in Distributed I/O and Valve Systems

Manufacturers of automation components have long made pneumatic valve terminals with IP65 and IP67 ratings that can be mounted anywhere on a machine. This is particularly useful for connecting valves as close to pneumatic actuators as possible. Doing so shortens the length of tubing, reduces the occurrence and severity of leaks, and increases actuator performance by shortening cycle times. Decentralized valve terminals communicate with the machine controller or PLC via an industrial Ethernet network. In addition to valves, terminals are configured with input and output modules to allow for easy connection of sensors, switches, and other field-level devices to the industrial network.

Remote I/O Modules and Pneumatic Valve Terminals

A typical machine or automation cell contains a multitude of automation components that must be connected to the inputs and outputs of the central PLC or machine controller. These components include an increasingly wide array of digital, analog, and pneumatic sensors and actuators.

Many machine builders employ remote I/O modules to reduce wiring for the digital and analog devices, as well as increase reliability, provide greater flexibility in system design, and make machines more resistant to harsh environments. Remote valve terminals are used to shorten pneumatic tubing and reduce the number of bends, both of which increase the performance of pneumatic actuators by shortening cycle times and reducing the likelihood of leaks.

Remote I/O modules and valve terminals connect to the PLC via the industrial Ethernet network. Common industrial protocols are EtherNet/IP, PROFINET, EtherCAT, and Modbus TCP. Industrial Ethernet networks reduce the number of hard-wired connections in the control cabinet, increase the amount of diagnostic information that can be acquired from the machine, and pave the way for predictive maintenance programs.

The approach of connecting field-level sensors and actuators to the PLC via remote I/O modules and remote valve terminals on the industrial Ethernet network is well-adopted in industry, but some challenges remain.

Challenges with the Existing Approach

Manufacturers of remote I/O modules and valve terminals provide software tools to machine builders to ease integration efforts. These software tools include electronic data sheets and device libraries, sample code and function blocks, and configuration tools. At the beginning of the integration process, these software tools must be downloaded and installed, then the user interfaces must be learned. These steps take time and effort on the part of the machine builder or controls engineer.

Additionally, it is common to use remote I/O modules and valve terminals from different manufacturers. This compounds the problem because each manufacturer supplies a different set of configuration tools, tailored to the functionality of their devices. Controls engineers are tasked with repeating the download, install, learn, and configure steps of this process for each manufacturer’s devices.

Every remote I/O module and valve terminal that connects directly to the industrial Ethernet network requires a unique network address. Each network address in a machine incurs costs for the machine builder in two ways. First, the network hardware itself, essentially a two-port Ethernet switch in every module and terminal, has a cost to it that is hidden inside the purchase cost of the component. Second, small and medium-size PLCs that are otherwise sufficient to manage the full machine control often come with a limited number of available network addresses.

As machine builders look to increase the benefits of digitalization by increasing the number of devices that connect directly to the Ethernet network, they frequently must upgrade PLCs to more expensive versions with a greater number of available addresses.

An Improved Approach to System Design

By reducing the number of integration tools and network addresses needed to build decentralized I/O and pneumatic valve systems, machine builders can overcome these remaining challenges. An effective method to do this is to introduce a dedicated bus interface into the decentralized system architecture.

The bus interface acts as a gateway between the industrial Ethernet network and the remote I/O modules and valve terminals. The bus interface connects directly to the industrial Ethernet network. The remote I/O modules and valve terminals connect to the bus interface. The connection of the modules and terminals to the bus interface can be through a physical backplane or over shielded, high-quality cables. In both cases the communications that pass between the modules, terminals, and bus interface are backplane communications, meaning they are fast, have low overhead, and are transparent to the user.

The bus interface is the only device that connects directly to the industrial Ethernet network. This means just one set of integration tools is required, which includes a device library in the case of PROFINET and EtherCAT networks, or a data structure in the case of EtherNet/IP and Modbus TCP. A downloadable software configuration tool is available, but the bus interface also provides a webserver so that no software download is required. The webserver allows the controls engineer to directly access system information, including system health and diagnostic information for the remote modules and terminals connected to the bus interface.

In the case of EtherNet/IP, the webserver allows a system-specific data structure to be downloaded directly from the bus interface. The data structure is imported into the PLC code complete with correct data types, data lengths, and human-readable tags for all inputs and outputs in the system. In the case of PROFINET and EtherCAT networks, the user installs the available device library, connects to the bus interface, and scans the bus interface to identify the full system of remote modules from within the PLC software.

Another benefit of using a bus interface is the reduction in the number of network addresses required for the various remote I/O modules and valve terminals on the machine. The bus interface requires one network address, regardless of the number of remote modules and terminals connected to it. If there is just one module/terminal or 50 of them (some systems can support up to 80 devices per bus interface), only one network address is required.

Compare a hypothetical machine with four remote I/O modules — a mix of digital and analog input modules and three remote valve terminals — each controlling a group of pneumatic actuators. In the conventional decentralized approach, this machine would require seven network addresses, one for each of the modules and terminals. In the new approach, only one network address is required for the bus interface, which connects to the network via its industrial Ethernet connection (M12, D-coded) and to the seven total modules and valve terminals via physical backplane connections or cables.

The speed of communications used between the bus interface and the remote modules and terminals is such that there is no bottleneck in data rates between the PLC and the field-level sensors and actuators. The same amount of data passes between them, including cyclic process data and acyclic configuration data. Diagnostic data is provided for every device, which can be applied to predictive maintenance programs and machine learning applications.

Additional Benefits for Machine Builders

System implementations that connect fewer devices to the Ethernet network are easier to switch from one industrial protocol to another. This is particularly useful for machine builders who provide solutions to a range of end-use customers. Many end users standardize on a particular protocol with several to choose from, including EtherNet/IP, PROFINET, EtherCAT, and Modbus TCP. A machine builder can provide a solution to an end user of EtherNet/IP one day and a similar solution to an end user of PROFINET the next. The easier it is for this machine builder to switch from one protocol to another the better.

Most remote I/O modules and valve terminals that connect directly to the Ethernet network support only one protocol, or sometimes two in the case of EtherNet/IP and Modbus TCP. When switching to another protocol the machine builder must replace each of the I/O modules and valve terminals with a similar device that supports the new protocol. When using the bus interface approach, only the bus interface must be replaced. The remote I/O modules and valve terminals connected to the bus interface remain the same, without having to be replaced.

With the bus interface approach to system design, the remote I/O modules and valve terminals form a single system with the bus interface, and therefore, all these devices come from the same manufacturer. This does not mean, however, that all field-level devices must also come from the same manufacturer. On the contrary, all digital and analog sensors and actuators are supported in this approach, regardless of manufacturer.

In addition to standard sensors and actuators, IO-Link technology is an increasingly popular option for smart sensors and actuators, with a growing list of manufacturers that support the open specification. IO-Link technology turns basic sensors and actuators into smart sensors and actuators. To support IO-Link technology, manufacturers of bus interface solutions provide IO-Link master modules that fit into the decentralized system alongside the remote I/O modules and valve terminals. IO-Link master modules support any third-party IO-Link devices. In this way the bus interface approach is completely compatible with any third-party sensors and actuators.

As described earlier, the bus interface connects to the remote I/O modules and valve terminals with a physical backplane or via cables. In both cases, the high-speed communications passing between the bus interface, modules, and terminals is the same. The communications are fast with low overhead, and support auto-recognition of all connected devices.

The bus interface automatically recognizes all modules and terminals that are connected to it. At power-up of the system, the bus interface is immediately ready to pass data between the Ethernet network and the connected devices. The bus interface makes the decentralized topology of modules and terminals appear to the PLC as a single, smart system of inputs, outputs, and pneumatic valves.

Place I/O and Valves Where You Need Them

Whether connected via physical backplane or over cables, the communications between modules and terminals are the same. This means that machine builders can use a mix of decentralized, individual modules and centralized valve manifolds with on-board I/O. This is referred to as a hybrid approach to system design because of the mix of centralized and decentralized devices. Cable lengths between distributed modules and terminals can be up to 50 meters, allowing very large machines with heavily decentralized I/O and valve needs to be addressed.

The ability to mix modules and terminals together in the system means that machine builders can install I/O and valves in the physical locations and orientations that make most sense to the overall machine design. The machine builder has more freedom and flexibility when placing I/O modules and valve terminals around the machine. All modules and terminals are IP65 and IP67 rated, which means they can be mounted outside of the control cabinet.

The technology that supports the bus interface approach to decentralized, remote I/O and valve systems has been in development for many years and is based on decades of experience in the development of smart pneumatic control and I/O systems. A bus interface approach, such as the Festo Automation Platform (AP), provides greater flexibility, easier integration, lower maintenance costs, and higher productivity for today’s machine builders.

This article was written by Eric Rice, Product Market Manager – Electric Automation, Festo Corporation (Islandia, NY). For more information, visit here  .

---