Connecting

There are really no two bigger names in industrial automation than Siemens and Rockwell. Both are great companies employing vast armies of people and generating thousands of jobs at distributors, systems integrators and customers. Both have dominated their respective markets for years and years. Both have fought each other tooth and nail for customers all over the world. In no market was the fight more intense than for the automotive customers: GM Ford, Chrysler, Fiat and all the rest.

Both have incredibly engaging stories of rags to riches. Two brothers Werner and Wilhelm von Siemens began product development in the early 19th century Germany. Their first successful product, an electrolytic method for gold and silver plating, found great success in the 1840s and 1850s. From plating they moved on to build their own telegraph. That extremely simple and reliable device led to the founding of Telegraphen-Bauanstalt von Siemens & Halske in October of 1847, the company that would later become what we know today as Siemens.

The Allen-Bradley (Rockwell) story is even more compelling. A schoolmate of Lynde Bradley in 1893, knowing of Lynde’s interest in electricity, brought the book “Electricity for Engineers” by Charles Desmond, to school one day. That book and its description of how Carbon plates could be used for variable contact resistance changed Lynde’s life and led to the founding of Allen-Bradley. From that book, Lynde created a crude rheostat which later led to his partnership with Dr. Allen and the forming of the Compression Rheostat Company in 1903. The compression Rheostat company was renamed Allen-Bradley in 1909.

After engaging in many difficult market competitions over the years, the industry has changed. No longer is there one programmable controller and one vendor for a manufacturing system. Machines have multiple sections sometimes with multiple controllers in each section. Machine sections are bought and integrated based on specific features and characteristics. And a lot of the time now, the main controllers might be from Siemens while sections of the machine might use AB Controllers. Or the reverse might be true; main machine control from Allen-Bradley controllers with sections of the machine controlled by Siemens PLCs.

This paper focuses on the different ways to make that kind of interoperability. It does a brief review of the technology as it exists in 2013, and describes the tools that connect the controllers of these two main companies.

Siemens Controllers

Overview

Trying to describe the Siemens line of controllers (SIMATIC) is like a quick summary of the birds that visit the feeders in my back yard; there are some that show up every day but you can count on something new every day too. The SIMATIC portfolio ranges from small controllers for simple logic tasks to highly complex system solutions. You can get micro controllers, classic programmable controllers, PC Controllers, integrated HMI Controllers and Embedded controllers.

Data Table Organization

One of the keys to interoperability between different controller manufacturers is the data table organization.

Every programmable controller vendor does this differently and it’s been a nightmare since day one. Every time you move from one PLC to another you have to learn the mnemonics of how the next controller structures its data table.

In the Siemens world, a data table is constructed from a set of defined types. The available types vary slightly from controller to controller while the number of data items is vastly different throughout the SIMATIC line.

Here is the list of typically supported data types for a Siemens PLC:

Elements of a data table are accessed by combining the mnemonic for the type with the offset into the data table for that type. IW502 is the 502nd Input Word in the data table while Q10 is the tenth Output Bit.

The number of data items found in a controller varies with the controller. For example, there may be no Input Double Words in one controller and 65535 in another. It all depends on the target application for that controller. A small, low cost controller for machine builders may have a lot fewer double words than a controller designed to control an entire papermaking converting line.

Connecting Siemens PLCs to Rockwell Automation Controllers is largely a matter of connecting data in the Siemens data table to the data table of the RA Controller.

Communication Interfaces – Protocols & Communication Ports

There are a number of ways to access those internal data items of a Siemens PLC. As with everything else, some PLCs will support one mechanism while others may support two or more different mechanisms. The following sections describe the communication interfaces you may find on a Siemens programmable controller.

Serial Communications

Except for one or two models, serial communications is available through an add-on module for all Siemens controllers. The port connects the Controller to barcode readers, printers, operator interfaces and other SI-MATIC Controllers. RS232, RS422 and EIA-485, formerly RS-485 can be used.

Devices can be accessed using a variety of protocols including simple ASCII, Modbus RTU master/slave, 3964, and RK512. Modbus RTU, 3964 and RK512, are binary protocols that can be used with devices that need to exchange binary device data with a controller. These protocols can also be used for Simatic Controller to Controller communication.

MPI Communications

MPI is a multi-node network used for Programming and SIMATIC Controller to Controller communication. An MPI interface is integrated on CPUs of the modular SIMATIC controllers. There are no MPI interfaces on the S7-1200 and S7-1500.

MPI Communications are proprietary communications that S7 Controllers use to exchange data between each other and other Siemens products. MPI communications use S7 Basic Communication, S7 Communication and Global Data Communication.

The S7 Protocol is a proprietary protocol that facilitates the transfer of data from one Siemens controller to an-other. The S7 Protocol is a subset of Profibus DP and uses many of the same commands as Profibus DP. In fact, some users have tried to use S7 Controllers as nodes on a Profibus network. This configuration is not supported by Siemens and may not work properly. An adapter is recommended in those applications in which you want to connect the MPI port to a Profibus network.

There are a few off-the-shelf products from third party manufacturers that allow other kinds of devices to communicate on MPI channels.

Profibus DP

Profibus was born out of a combined push by the German government, German companies, and other industry leaders in the late 1980s. Profibus defines an RS485 serial physical layer with special drivers to obtain speeds as fast as 12MB. A standard twisted-pair wiring system is typical but Profibus can also be implemented with fiber-optic and other media.

Profibus is a smart, sensor-bus technology. Slave devices on the system connect to a central controller, usually a SIMATIC S7 Programmable Logic Controller. Once connected, the S7 Controller sends outputs to these devices and receives inputs from them.

Profibus had two huge advantages over other sensor bus technologies. One is speed and the second is data size. 12Meg is really fast. Faster than most people need but generally automation engineers believe that when possible, it’s always best to go faster. Speed has its downside though and that’s cost. It costs more to go that fast. A special ASIC with the communications infrastructure on it (MAC – Media Access Controller), special transceivers, cabling and connectors all make Profibus devices significantly costlier.

The data size advantage over DeviceNet is significant. Profibus has a frame size of 244 bytes. That’s monstrous compared to 8 byte frames in CAN. Yes – DeviceNet has fragmentation but that eats up so much band-width it is hardly useable.

One of the things some people dislike about Profibus is the data representation. All Profibus devices look like a rack of I/O to the controller. That means that a device is a series of slots, each slot with a module in it and all sorts of different size modules. That’s easy for simple devices like I/O devices. You can simply decide that the first slot has a module that is a 16 bit Discrete Input device. The second is 8 bits of Discrete Output and so on. If you have Analog inputs/outputs too, you could setup the device using four slots and four modules. For other non-IO devices, that’s kind of awkward.

Profinet IO

Profinet IO is very similar to Profibus, but not really Profibus on Ethernet. While Profibus uses cyclic communications to exchange data with programmable controllers at a maximum speed of 12Meg baud, Profinet IO us-e’s cyclic data transfer to exchange data with Simatic programmable controllers over Ethernet. As with Profibus, a programmable controller and a device must both have a prior understanding of the data structure and meaning. In both systems data is organized as slots containing modules with the total number of I/O points for a system with the sum of the I/O points for the individual modules.

Profinet IO uses three different communication channels to exchange data with programmable controllers and other devices. The standard TCP/IP channel is used for parameterization, configuration and acyclic read/write operations. The RT or Real Time channel is used for standard cyclic data transfer and alarms. RT communications bypass the standard TCP/IP interface to expedite the data exchange with programmable controllers. The third channel, Isochronous Real Time (IRT) is the very high speed channel used for Motion Control applications. IRT is implemented using a custom ASIC and is not the subject of this paper.

Profinet IO classifies devices into three types; IO-Controllers, IO-Devices and IO-Supervisors. IO-Controllers are devices that execute an automation program. Controllers, functionally similar to a Profibus Class 1 master, exchange data with IO-Devices. IO-Devices are distributed sensor/actuator devices connected to the IO-Controller over Ethernet. In Profibus terms, IO-Devices are similar to Profibus slaves. IO-Supervisors are HMIs, PCs or other commissioning, monitoring or diagnostic analysis devices. These devices are similar to Class 2 Profibus masters.

IO-Controllers map IO data from Profinet IO devices into the process image of the controller. In Siemens S7 programmable controllers, I/O data, alarms and status data is mapped into the process image in much the same way it is done for Profibus devices. These data values are then available for use by the control program. IO-Controllers must support the following kinds of services:

• Cyclic Data Exchange – The exchange of data between IO-Controllers and IO-Devices
• Acyclic Data Exchange – The exchange of Configuration and Diagnostic data
• Alarms – Alarm data exchange from an IO-Device to an IO-Controller
• Context Management – Connection processing

Rockwell Controllers

Overview

Rockwell Automation provides a set of controllers similar to Siemens. Rockwell’s solutions range from the original, 1970 programmable logic controller (PLC) to controllers for large and small control systems, safety applications to very small controllers, to programmable automation controller (PAC).

Data Table Organization

Interoperability between Rockwell controllers is a bit more difficult than between Siemens controllers as Rock-well implements two different data table organizations. Traditionally, their programmable controllers organized data as files by file type. There were files for Numeric data (N Files), Floating Point files (F Files), Timer Files (T Files) and many more. Individual data items were designated by a File number and offset; N21:300 being the 300th entry in Numeric File 21.

With the introduction of the ControlLogix^® series of programmable controllers Rockwell changed the data representation. Instead of File numbers, data was organized simply by Tag Name. A tag named “EWGF” or any-thing else you wanted could now be used to represent any data type from a binary to a numeric to a string or anything else.

The change in data representation presented several difficulties for data communications across the Rockwell PLC line. For older PLC models, SLCs and PLCs, nothing changed. They communicated as they did before by exchanging files. But for the Logix controllers just communicating among themselves become more complex. In the old style of data organization, messages could request 100 registers beginning with the 200th entry of File N7 (N7:200). That efficiency was for the most part lost in the new organization unless data was grouped into arrays or UDF (User Defined Fields).

To send data between controllers of one style of data organization to another one of a different style required mapping from a Tag name (EWGF) to file based data name (N7:101). Not impossible but more complex and difficult than in prior versions.

Communication Interfaces – Protocols & Communication Ports

Rockwell provides a number of ways to access internal data items. These interfaces are much easier to use than any of the interfaces that Siemens provides and have enabled the development of many specialized applications that use PLCs for machine control.

Serial Communications

Most Rockwell Controllers provide one or more serial ports. These ports use 9-pin or 25-pin D Sub connectors with RS232, RS422 or RS485 communications.

Communications over these serial ports use the PCCC (programmable controller Communication Commands) command set. This is an application layer protocol that has commands for reading and writing the data files in the PLC. Using PCCC you can send commands to read 20 integers from Numeric File 7 or write two Floating Point Registers in Floating Point Register File 11.

The PCCC application layer is wrapped in a link layer protocol named DF/1. This protocol just moves the PCCC application layer message from one place to the other. It does the error checking, message acknowledgements and manages the addressing for multi-drop applications. That’s why serial communications on Rockwell PLCS are mistakenly referred to as a “DF1 Communications.”

USB Communications

For some time now the trend in laptops has been to eliminate serial ports. That presents a problem for the control engineers that really like to setup their laptop out at the machine and plug a cable in to the machine. That’s attractive to a lot of people because it’s really secure. Unauthorized people have to get physical access to the machine to make programming changes.

One of the things Rockwell did on its newest controllers is to add a USB port to take over as the programming port. Many people thought that this meant the PLC would have the kind of functionality that a USB has on a PC but that’s not the case. The USB port is just there for programming. You can’t plug data stick in, you can’t plug in devices like printers and card readers and you can’t communicate to USB devices with that port.

DH+ and RIO Communications

DH+ is the famous “Blue Hose” communications used by the older Rockwell PLCs and some of the newer Logix line. In early days of automation, there were a lot of switches, some early Motor Controls, a few valves and some photoeyes. All of those tied directly over wires to a controller. This is the environment where Allen-Bradley (prior to Rockwell) introduced DH+ and RIO and literally created industrial networking!

DH+ is technology that is proprietary to Rockwell that implements a peer network with a floating master. The bus master floats between different nodes. When a node gets mastership it can send messages. The physical layer is proprietary with differential signaling. You can do a network with a lot of nodes and up to 10,000 feet long. Each drop can be up to 100 feet so you can cover a huge area with it.

Just like DF/1, DH+ is another way to transfer PCCC messages between programmable controllers.

So, why do we need to bother with these antiques? Can’t we just forget them and go on? No, the answer is an EMPHATIC NO. There are hundreds and hundreds if not thousands of miles of DH+ and RIO networks around the US and in other places. These networks aren’t going to be ripped out just because of the gray hair and pearl handled, coffee stained cane. People need to keep these things running.

DeviceNet Communications

DeviceNet is one of the application layer protocols that is based on CIP (Common Industrial Protocol). It uses CAN (Controller Area Networking) as its transport layer. DeviceNet is a master – slave protocol. Rockwell Controllers implement the master side of DeviceNet communications.

Controller Area Networking, or CAN is a worldwide, heavily used communications standard created by Bosch in Germany in March of 1985. It is a high speed serial communications standard used by intelligent devices to communicate with each other. Unlike many other communication standards that provide fast data rates with thousands or millions of data bytes in a single frame, CAN has a bit rate that max’s out at a pretty slow 1 mega baud. But where speed and capacity are strengths for many of the other standards, CAN’s strength is its low overhead and simple physical interface. With its small packet size, even at 500K baud, a frame with eight bytes of data is only on the network wire for a quarter of a millisecond. For many control applications, this is plenty fast.

DeviceNet implements the Communications and Information Protocol (CIP) as its communications protocol for transferring automation data between two devices. DeviceNet is a combination of the CIP protocol and the CAN Physical Layer. In the CIP protocol, every network device represents itself as a series of objects. Each object is simply a grouping of the related data values in a device. DeviceNet (and all CIP devices) allow for individual access to attributes (values) in Objects or cyclic movement of I/O data.

PCCC Ethernet Communications

One of the least understood mechanisms for talking to Rockwell Controllers is PCCC over Ethernet. This works the same way as Ethernet over serial except that the PCCC application layer isn’t in a DF/1 packet, it’s in an Ethernet TCP packet.

This mechanism is used by many system level applications that use Rockwell PLCs to execute automation tasks configured at the system level.

EtherNet/IP Communications

EtherNet/IP is another one of the application layer protocols that is based on CIP. EtherNet/IP is a Client – Server technology which is referred to in the EtherNet/IP world as Scanner – Adapter. Rockwell Controllers implement the Scanner side of EtherNet/IP communications.

Instead of CAN, EtherNet/IP uses the tools and technologies of traditional Ethernet. EtherNet/IP uses all the transport and control protocols used in traditional Ethernet including the Transport Control Protocol (TCP), the Internet Protocol (IP) and the media access and signaling technologies found in off-the-shelf Ethernet interface cards. Building on these standard PC technologies means that EtherNet/IP works transparently with all the standard off-the-shelf Ethernet devices found in today’s marketplace. It also means that EtherNet/IP can be easily supported on standard PCs and all their derivatives. Even more importantly, basing EtherNet/IP on a standard technology platform ensures that EtherNet/IP will move forward as the base technologies evolve in the future.

EtherNet/IP is a certifiable standard. The groups supporting EtherNet/IP plan to ensure a comprehensive, consistent standard by careful, multi-vendor attention to the specification and through certified test labs as has been done with DeviceNet and ControlNet. Certification programs modeled after the programs for DeviceNet and ControlNet will ensure the consistency and quality of field devices.

EtherNet/IP is built on a widely accepted protocol layer. EtherNet/IP is constructed from a very widely implemented standard used in DeviceNet and ControlNet called the Control and Information Protocol (CIP) and is illustrated on the attached drawing. This standard organizes networked devices as a collection of objects. It defines the access, object behavior and extensions which allow widely disparate devices to be accessed using a common mechanism. Hundreds of vendors now support the CIP protocol in present day products. Using this technology in EtherNet/IP means that it is based on a widely understood, widely implemented standard that does not require a new technology shakedown period.

Rockwell – Siemens Communications

Now that the description of all the communication mechanisms is complete (or as complete as it can be given that new controllers and add-on modules are introduced daily), we can start to think about the various ways of linking Rockwell PLCs to Siemens.

Siemens PLC to Rockwell PLC over Serial – Given the complexity of electrical conversion, protocol conversion, limited baud rates on the Rockwell side and cable distance issues this isn’t really even worth talking about.

Siemens PLC to Rockwell PLC using Sensor Buses (Profibus DP and DeviceNet) – This does make some sense in a limited sort of way. There are two options here.

1. Use a master-slave converter to map I/Os from one network to another. Use a protocol converter with a DeviceNet master on one side and a Profibus DP slave on the other. That kind of device makes the DeviceNet I/O look like Profibus I/O. Or you can reverse it, a Profibus DP master collecting Profibus DP I/O points and providing them to a DeviceNet master as DeviceNet I/O. This works fine if all you want is to map I/O from one network but they don’t map PLC to PLC.
2. Use a slave-slave converter to map I/Os from one controller to another. If you can find a device with Profibus DP slave on one side and DeviceNet slave on the other then you can easily move I/O data between the controllers. Unfortunately there aren’t many of these around and the ones that you can find really don’t provide anything more than I/O data transfer.

Siemens PLC to Rockwell PLC using Only Industrial Ethernet (Profinet IO and EtherNet/IP) – This is the exact same issue as with the Sensor buses. These protocols do nothing more than move I/O data around. They are not a good way to transfer more than I/O (Data and Information).

Siemens PLC to Rockwell PLC using Industrial Ethernet and Ethernet TCP – The most generic and adaptable way to communicate between a Siemens PLC and a Rockwell PLC is a converter that can be a Profinet IO Device (slave) on one side and a PCCC master on the other. When data moves from the Siemens PLC to the Rockwell PLC the converter takes data off of Profinet IO and writes it into the PLC using PCCC. In the other direction data is read from the Rockwell PLC and placed in Profinet IO Input blocks. It’s not perfect but it gets the job done in a more generic and friendly way than any other mechanism I’ve found.

It’s not easy getting the two biggest names in Automation to communicate. They both have a lot of options and a lot of ways to communicate, but none that really facilitate simple, easy information transfer.