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 auto-motive 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. In this week’s blog, we’re focusing on Siemens Controllers and associated technologies.
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 microcontrollers, classic Programmable Controllers, PC Controllers, integrated HMI Controllers, and Embedded controllers.
Data Table Organization
One of the keys to interoperability between different controller manufacturers in 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.
Except for one or two models, serial communications are 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 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 another. 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 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 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 bandwidth 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 set up the device using four slots and four modules. For other non-IO devices, that’s kind of awkward.
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 another 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
The next blog in this series will focus on Rockwell Automation Controllers and associated technologies