Industrial Protocol

ControlNet fieldbus network - technology overview

Real Time, Control Network

ControlNet is a member of the CIP (Common Industrial Protocol) network family. ControlNet offers good

real-time capabilities providing high-speed deterministic transmission for time-critical I/O data and

messaging data. ControlNet was developed by Rockwell Automation and today, it is managed by the

ControlNet International User organization. ControlNet is a very popular network for time critical

applications based on Rockwell Automation technology. ControlNet products are certified by the ControlNet

International user organization, guaranteeing worldwide compatibility

Producer/Consumer Communication

ControlNet is standardized in the European standard series EN 50170. It uses coax cables and a

transmission speed of 5 Mbit/s. The Media Access method is taking full advantage of the

Producer/Consumer model and allows multiple controllers to control I/O on the same wire.

ControlNet is highly deterministic and repeatable and thus meets critical requirements for synchronized and

coordinated real-time motion control applications. Determinism is the ability to reliably predict when data will

be delivered, and repeatability ensures that transmit times are constant and unaffected by devices

connecting to, or leaving, the network. These features are further enhanced with user selectable I/O and

controller interlocking update times to match application requirements.

Configuration with EDS-Files

During the setup phase of the ControlNet network, the Controlnet Master Scanner must be configured with

a special configuration tool such as Rockwell's RSNetWorx. The configuration process is based on

electronic device data sheets (EDS-Files) which are required for each ControlNet device. EDS-Files are

provided by the device manufacturers and contain electronic descriptions all relevant communication

parameter and objects of the ControlNet device.

CONTROLNET FACTS

Network Type: Provider/Consumer Fieldbus communication network

Topology: Flexible with line, bus, tree or star topologies

Installation: RG-6 coax cables with BNC connectors Media redundancy optional Network length

up to 1000m; with Repeaters extendible up to 25km

Data Rate : 5000 kbit/s

max. Stations : 99

Data: Data Packets with 0 - 510 byte

Downloaded From www.shailesh-instru.webs.com

Modbus protocol

Modbus Protocol is a messaging structure developed by Modicon in 1979, used to establish master-

slave/client-server communication between intelligent devices. Modbus is a de facto standard, truly open

and the most widely used network protocol in the industrial manufacturing environment. Modbus is literally

implemented by hundreds of vendors on thousands of different devices in order to transfer discrete/analog

I/O and register data between control devices using Modbus. Modbus continues to enable millions of

automation devices to communicate.

The Modbus protocol

Modbus is an application layer messaging protocol, positioned at level 7 of the OSI model that provides

client/server communication between devices connected on different types of buses or networks.

Modbus is a request/reply protocol and offers services specified by function codes. Modbus function codes

are elements of Modbus request/reply PDUs (Protocol Data Unit).

The Modbus application data unit is built by the client that initiates a Modbus transaction. The function

indicates to the server what kind of action to perform. The Modbus application protocol establishes the

format of a request initiated by a client. The function code field of a Modbus data unit is coded in one byte.

Valid codes are in the range of 1 ... 255 decimal (128 – 255 reserved for exception responses). When a

message is sent from a Client to a Server device the function code field tells the server what kind of action

to perform.

Sub-function codes are added to some function codes to define multiple actions. For example a client can

read the ON / OFF states of a group of discrete outputs or inputs or it can read/write the data contents of a

group of Modbus registers. When the server responds to the client, it uses the function code field to indicate

either a normal (error-free) response or that some kind of error occurred (called an exception response).

For a normal response, the server simply echoes to the request the original function code.

The nice thing of the Modbus standard is the flexibility, but at the same time the easy implementation of it.

Not only intelligent devices like microcontrollers, PLCs etc. are able to communicate with Modbus, also

many intelligent sensors are equiped with a Modbus interface to send their data to host systems. While

Modbus was previously mainly used on wired serial communication lines, there are also extensions to the

standard for wireless communications and TCP/IP networks.


Modbus message structure

The Modbus communication interface is built around messages. The format of these Modbus messages is

independent of the type of physical interface used. On plain old RS232 are the same messages used as on

Modbus/TCP over ethernet. This gives the Modbus interface definition a very long lifetime. The same

protocol can be used regardless of the connection type. Because of this, Modbus gives the possibility to

easily upgrade the hardware structure of an industrial network, without the need for large changes in the

software. A device can also communicate with several Modbus nodes at once, even if they are connected

with different interface types, without the need to use a different protocol for every connection.

On simple interfaces like RS485 or RS232, the Modbus messages are sent in plain form over the network.

In this case the network is dedicated to Modbus. When using more versatile network systems like TCP/IP

over ethernet, the Modbus messages are embedded in packets with the format necessary for the physical

interface. In that case Modbus and other types of connections can co-exist at the same physical interface at

the same time. Although the main Modbus message structure is peer-to-peer, Modbus is able to function on

both point-to-point and multidrop networks.

Each Modbus message has the same structure. Four basic elements are present in each message. The

sequence of these elements is the same for all messages, to make it easy to parse the content of the

Modbus message. A conversation is always started by a master in the Modbus network. A Modbus master

sends a message and—depending of the contents of the message—a slave takes action and responds to

it. There can be more masters in a Modbus network. Addressing in the message header is used to define

which device should respond to a message. All other nodes on the Modbus network ignore the message if

the address field doesn't match their own address.

Modbus serial transmission modes: Modbus/ASCII and Modbus/RTU

Serial Modbus connections can use two basic transmission modes, ASCII or RTU, remote terminal unit.

The transmission mode in serial communications defines the way the Modbus messages are coded. With

Modbus/ASCII, the messages are in a readable ASCII format. The Modbus/RTU format uses binary coding

which makes the message unreadable when monitoring, but reduces the size of each message which

allows for more data exchange in the same time span. All nodes on one Modbus network segment must

use the same serial transmission mode. A device configured to use Modbus/ASCII cannot understand

messages in Modbus/RTU and vice versa.

When using Modbus/ASCII, all messages are coded in hexadecimal values, represented with readable

ASCII characters. Only the characters 0...9 and A...F are used for coding. For every byte of information, two


communication-bytes are needed, because every communication-byte can only define 4 bits in the

hexadecimal system. With Modbus/RTU the data is exchanged in a binary format, where each byte of

information is coded in one communication-byte.

Modbus messages on serial connections are not sent in a plain format. They are framed to give receivers

an easy way to detect the beginning and end of a message. When using Modbus/ASCII, characters are

used to start and end a frame. The colon ':' is used to flag the start of a message and each message is

ended with a CR/LF combination. Modbus/RTU on the other hand uses time gaps of silence on the

communication line for the framing. Each message must be preceded by a time gap with a minimum length

of 3.5 characters. If a receiver detects a gap of at least 1.5 characters, it assumes that a new message is

comming and the receive buffer is cleared. The main advantage of Modbus/ASCII is, that it allowes gaps

between the bytes of a message with a maximum length of 1 second. With Modbus/RTU it is necessary to

send each message as a continuous stream.

Modbus addressing

The first information in each Modbus message is the address of the receiver. This parameter contains one

byte of information. In Modbus/ASCII it is coded with two hexadecimal characters, in Modbus/RTU one byte

is used. Valid addresses are in the range 0..247. The values 1..247 are assigned to individual Modbus

devices and 0 is used as a broadcast address. Messages sent to the latter address will be accepted by all

slaves. A slave always responds to a Modbus message. When responding it uses the same address as the

master in the request. In this way the master can see that the device is actually responding to the request.

Within a Modbus device, the holding registers, inputs and outputs are assigned a number between 1 and

10000. One would expect, that the same addresses are used in the Modbus messages to read or set

values. Unfortunately this is not the case. In the Modbus messages addresses are used with a value Downloaded From www.shailesh-instru.webs.com

between 0 and 9999. If you want to read the value of output (coil) 18 for example, you have to specify the

value 17 in the Modbus query message. More confusing is even, that for input and holding registers an

offset must be substracted from the device address to get the proper address to put in the Modbus

message structure. This leads to common mistakes and should be taken care of when designing

applications with Modbus. The following table shows the address ranges for coils, inputs and holding

registers and the way the address in the Modbus message is calculated given the actual address of the

item in the slave device.

Modbus function codes

The second parameter in each Modbus message is the function code. This defines the message type and

the type of action required by the slave. The parameter contains one byte of information. In Modbus/ASCII

this is coded with two hexadecimal characters, in Modbus/RTU one byte is used. Valid function codes are

in the range 1 to 255. Not all Modbus devices recognize the same set of function codes. The most common

codes are discussed here.

Normally, when a Modbus slave answers a response, it uses

the same function code as in the request. However, when an

error is detected, the highest bit of the function code is

turned on. In that way the master can see the difference

between success and failure responses.

Modbus was designed in the late 1970s to

communicate to programmable logic controllers, the number of data types is limited to those

understood by PLCs at the time. Large binary objects are not supported.

No standard way exists for a node to find the description of a data object, for example, to determine

if a register value represents a temperature between 30 and 175 degrees.

Since Modbus is a master/slave protocol, there is no way for a field device to "report by exception"

(except over Ethernet TCP/IP, called open-mbus)- the master node must routinely poll each field

device, and look for changes in the data. This consumes bandwidth and network time in applications

where bandwidth may be expensive, such as over a low-bit-rate radio link.

Modbus is restricted to addressing 247 devices on one data link, which limits the number of field

devices that may be connected to a master station (once again Ethernet TCP/IP proving the

exception).

Modbus transmissions must be contiguous which limits the types of remote communications devices

to those that can buffer data to avoid gaps in the transmission.

Modbus mix hardware, transport and application concepts in a messy manner. This makes the

documentation hard to read. Downloaded From www.shailesh-instru.webs.com

OPC Advantages & Disadvantages

Advantages:

• Data from a wide variety of sources is available using the same data access standards

• No knowledge of subsystem internals is required

• Advanced tools for implementation of calculations

• Advanced test and debug environment

• Provides a structure to keep calculations organized

• High maintainability

• Allows those with process knowledge to implement calculations and logic without requiring special skills

• Rich set of calculation and data manipulation functions available

• Plentiful and inexpensive computing resources

• Can easily integrate with special purpose third party calculation modules such as Steam Tables, API

Methods, Web Services and relational databases.

• Results can be directed to a variety of destinations

• Calculations are system independent and transportable

• Scheduling can be time or event-based. Individual equations may be execute or not based on the result of

other equations.

• Calculations may be used to easily move data between systems

Disadvantages

• Depends on quality OPC servers for connection to data sources

• Not typically suitable for sub-second calculation rates

• Not as reliable as PLC or DCS

DCS (distributed control system) or PLC (programmable logic controller)

Advantages:

• High reliability

• High speed

• Results available within the control system/PLC

Disadvantages

• Expensive real estate

• Complex calculations are not easily implemented

• Limited visibility of equations and logic

• Not easily maintained

• Limited data availability

• Limited or no historical data access

• May require special skills to implement

• Limited test and debug environment

• Difficult to change/edit

• Limited access to other systems (LIMS, Enterprise, RDBMS)


SCADA (Supervisory Control and Data Acquisition) or Process Historian

Advantages:

• Access to real-time and possibly historical data

• Advanced implementation tools

• Easier test and debug environments

• Relatively good maintainability

• Relatively inexpensive computing resources (PC)

Disadvantages

• Only process data within the system is available

• May require special skills to implement

• Often highly dependent on SCADA or Process Historian vendor software versions

Can ERP learn from DCS?

Enterprise Resource Planning: An integrated information system that serves all departments within an

enterprise. Evolving out of the manufacturing industry, ERP implies the use of packaged software rather

than proprietary software written by or for one customer.

Many companies have been swept away by "ERP systems" without really understanding the purpose or

consequences of such a move. To begin with, enterprise resource planning is a business philosophy, not a

software package. ERP is a natural evolution from manufacturing resource planning which evolved from

material requirements planning.

To efficiently address these business philosophies, companies must install appropriate business systems.

Unfortunately, many firms have been sold on the need to roll out a single, all encompassing software

package on a single server as the "solution."

The same "integration dream" was prevalent in the early days of process control. Mills attempted to

implement all encompassing control systems. The whole facility was to be controlled by one central

computer, from one central control room, by one operator. Unfortunately, as processes became more

complex and plants became physically larger, even the biggest control computers were unable to manage

effectively. Networks ran out of bandwidth. Humans ran out of coping skills. Systems became un-

maintainable.

Modern distributed control systems (DCS) are modular and hence more effective. They are designed to

achieve specified levels of repeatability, reliability and repair ability. They consist of a number of linked

components, such as smart transmitters, distributed control modules, plant historians, analysis tools, and

model-based decision support systems. They work together as an integrated system.

The approach to "plant control" has evolved. Functions such as local control, inter-area control, and data

analysis are clearly distinguished and architected appropriately. No attempt is made to do all things in one

system or in a group of modules. There is focus. The result is an "integrated system" with components that

do a number of tasks well.


System features that address repeatability

Measurement devices are self-tuning) assuring performance

Data is maintained where it is used and stored only as long as needed, reducing network traffic

Software tracks valid data ranges, and the system completes data reconciliation through

sophisticated numerical methods maintaining data integrity

Bad or suspect information is flagged, to control its use

Numeric and textual information is linked, to add clarity to data

Simulators are used to train operators and staff to achieve consistent responses System features

that address reliability

Redundant components are installed to maintain critical data values

Systems are designed for 24 hour, seven day a week performance to ensure continuous operations

Computing "horsepower" is applied where required to manage performance

Alarm managers and process simulation are used to focus control actions

Data for control operations ale maintained separately to ensure performance

Data required for business records and analysis are extracted into a separate historian system

where they can be manipulated, charted, alarmed, and reported without interrupting plant processes

Components from different vendors are assembled and tested against high fidelity

System features that address repairability

Levels of decision support are standardized to aid troubleshooting

Integration is managed to control complexity

Control functions share data only as required to reduce complexity

Inter-systems communication hooks are defined.

Integration software and, it necessary, specific integration hardware, are purchased as catalog part

numbers, reducing potential variability.

RS485 is a standard defining the electrical characteristics of drivers and receivers for use in balanced

digital multipoint systems. The standard is published by the ANSI

The graph below shows potentials of the '+' and ' ' pins of an EIA-485 line during transmission of one

byte (0xD3, least significant bit first) of data using an asynchronous start-stop method.

EIA-485 only specifies

electrical characteristics of

the driver and the receiver. It

does not specify or

recommend any data

protocol. EIA-485 enables the

configuration of inexpensive

local networks and multidrop communications links. It offers high data transmission speeds (35 Mbit/s up to

10 m and 100 kbit/s at 1200 m).


Master-slave arrangement (RS485)

Often in a master-slave arrangement when one device dubbed "the master" initiates all communication

activity, the master device itself provides the bias and not the slave devices. In this configuration, the

master device is typically centrally located along the set of EIA-485 wires, so it would be two slave devices

located at the physical end of the wires that would provide the termination. The master device itself would

provide termination if it were located at a physical end of the wires, but that is often a bad design[3] as the

master would be better located at a halfway point between the slave devices. Note that it is not a good idea

to apply the bias at multiple node locations, because, by doing so, the effective bias resistance is lowered,

which could possibly cause a violation of the EIA-485 specification and cause communications to

malfunction. By keeping the biasing with the master, slave device design is simplified and this situation is

avoided.

The Device Level Network

DeviceNet was originally developed by Rockwell Automation and today, It is managed by the Open

Devicenet User organization (ODVA). Devicenet is among the worlds leading device level networks for

industrial automation. DeviceNet is a very popular network for time critical applications based on Rockwell

Automation technology. DeviceNet offers robust, efficient data handling because it is based on

Producer/Consumer model. DeviceNet is standardized in the international standard series IEC 61158.

DeviceNet devices are certified for interoperability and conformance to the DeviceNet standard by ODVA.

Provider/Consumer Communication

DeviceNet is a digital, multi-drop network that connects and serves as a communication network between

industrial controllers and I/O devices. Each device and/or controller is a node on the network. DeviceNet is

a producer-consumer network that supports multiple communication hierarchies and message prioritization.

DeviceNet systems can be configured to operate in a master-slave or a distributed control architecture

using peer-to-peer communication. DeviceNet systems offer a single point of connection for configuration

and control by supporting both I/O and explicit messaging. DeviceNet also has the unique feature of having

power on the network. This allows devices with limited power requirements to be powered directly from the

network, reducing connection points and physical size.

DeviceNet uses a trunk-line/drop-line

topology that provides separate wire

pairs for both signal and power

distribution. End-to-end network length

varies with data rate and cable

thickness.

DeviceNet uses the Common Industrial Protocol, called CIP, for its upper protocol layers. CIP is strictly

object oriented. Each object has attributes (data) and services (commands) and behavior (reaction to

events). Two different types of objects are defined in the CIP specification: communication objects and

application-specific objects.


PROcess Field BUS

Profibus is the leading industrial communication system for manufacturing automation in Europe with strong

growth in many other markets. Profibus is supported by Siemens and is promoted by the Profibus User

Organization. Profibus products are certified by the Profibus User Organization (PNO), guaranteeing

worldwide compatibility.

Profibus was originally defined 15 years ago under the German standard DIN 19245 and is today part of

the international standard series IEC 61158. Based on the initial functionality, many new features have

been added and today, Profibus consists of a family of 3 protocol variations (DP, DPV1, DPV2) that can be

used with different physical transmission media.

Device Profile improve interoperability

In addition to the protocol definitions, Profibus defines many Application Profiles for specific device types

and industries i.e. ProfiDrive for Drives, Profibus-PA for Process Automation and ProfiSafe for Safety

Applications.

Profibus Protocol Family

Profibus is a Multi Master

Network. Depending on the

selected protocol variation, it

supports Master/Slave,

Master/Master and Slave/Slave

communications. Profibus is

optimized to transmit cyclic

process data very fast and

efficient between Master and

Slaves but can also handle

acyclic Parameter data and iso

synchronous Real time transmissions.

Version DP-V0: Provides the basic functionality of DP, including cyclic data exchange, station, module and

channel-specific diagnostics and four different interrupt types for diagnostics and process interrupts, and for

the pulling and plugging of stations.

Version DP-V1: Contains enhancements geared towards process automation, in particular acyclic data

communication for parameter assignment, operation, visualization and interrupt control of intelligent field

devices, parallel to cyclic user data communication. This permits online access to stations using

engineering tools. In addition, DP-V1 has three additional interrupt types: status interrupt, update interrupt

and a manufacturer-specific interrupt.

Version DP-V2: Contains further enhancements and is geared primarily towards the demands of drive

technology. Due to additional functionalities, such as isochronous slave mode and lateral slave

communication (DXB) etc., the DP-V2 can also be implemented as a drive bus for controlling fast

movement sequences in drive axes


Industrial Protocol

Documents

Transcript of Industrial Protocol