Connecting Rockwell and Siemens Automation System (Part 2)

Rockwell Controllers

Overview of Rockwell Automation System

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) in Rockwell Automation System.

Data Table Organization of Rockwell Automation System

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 in Rockwell Automation System

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. They have enabled the development of many specialized applications that use PLCs for machine control in Rockwell Automation System.

Rockwell Serial Communications

Most Rockwell Controllers provide one or more serial ports in Rockwell Automation System. 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.”

Rockwell 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.

Rockwell 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.

Rockwell 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 in Rockwell Automation System.

Rockwell 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 Rockwell Automation System level.

Rockwell 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 in Rockwell Automation System.

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. It includes 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.

Features

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. This 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.

Siemens – Rockwell Automation System 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.

Two options

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 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. 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) in both Siemens and Rockwell Automation System Communications.

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. It 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.

Conclusion

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.

CTI SUPPLY – THE RIGHT INDUSTRIAL AUTOMATION SYSTEM INTEGRATOR