AUTOMATION (M.

TECH III SEM)

Prepared By
Dr. Sachidananda Sen
1
Asst. Professor, EEE Dept.
 SYLLABUS
UNIT V
Web based PLC
 Create Programming, Logics designing and creation of
Organization Blocks.
 Force, Rewiring, Compare blocks, Protection of Block.

 Checking PLC status on internet, diagnostics buffer,

Watch table.
 PID concept, software blocks involved and blocks
involved in analog communication,
 Configuration between 2 CPU’s and settings.

 Data transfer through MODBUS protocol.

 CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 Definition of controller
 The following definitions are used:
 A controller is a central or decentralized automation
station (station) with the components CPU, CP (optional),
CM (optional) and distributed I/O.
 Within the station, the components are connected via the
backplane bus.
 Central station:
 • contains a distributed I/O
 • communicates with distributed stations via PROFINET
IO or PROFIBUS DP
 Decentralized station:
 • contains a distributed I/O
 • communicates with the central station via PROFINET
IO or PROFIBUS DP
 CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 Models on CPU-CPU Communication
 For CPU-CPU communication, data is exchanged between
the CPUs of two controllers:
 • Controller 1: SIMATIC controller
 • Controller 2: SIMATIC controller or other controller
 Source or destination of the data is the user data area of
the CPU of the controller:
 • data block, flag, inputs, outputs, ...
 For CPU-CPU communication, the following cases are
differentiated:
 • CPUs in different central stations
 • CPUs in central and decentralized station*
 • CPUs within a central SIMATIC station
 * a decentralized station with CPU is also referred to as I-slave
(for PROFIBUS) or I-device (for PROFINET).
CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CPUs in different central stations
 The figure shows the function model for the CPU-CPU
communication between distributed stations
 Interfaces for communication:

 • Integrated interface: interface to CPU

 • External interface: interface to CP or CM

 Media for communication:

 • Network (PROFINET/Industrial Ethernet, PROFIBUS,

MPI)
 • Serial interface (*ASCII*, 3964(R), RK 512, …)
CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CPUs in central and decentralized station
 The figure shows the functional model for the CPU-CPU
communication between central and decentralized
station.
 Medium for communication:

 • Interfaces for communication:

 • Integrated interface: interface to CPU

 • External interface: interface to CP or CM

 Media for communication:

 • PROFINET/Industrial Ethernet (PROFINET IO)

 • PROFIBUS (PROFIBUS DP)

CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CONFIGURATION BETWEEN 2 CPU’S AND SETTINGS
 CPUs within a central station
 The figure shows the functional model for the CPU-CPU
communication between CPUs within a central SIMATIC
station.
 Medium for communication:

 • SIMATIC backplane bus

 DATA TRANSFER THROUGH MODBUS PROTOCOL
 Modbus is a data communications protocol originally published by
Modicon (now Schneider Electric) in 1979 for use with
its programmable logic controllers (PLCs).
 Modbus has become a de facto standard communication protocol and
is now a commonly available means of connecting
industrial electronic devices.
 Modbus is popular in industrial environments because it is openly
published and royalty-free.
 It was developed for industrial applications, is relatively easy to
deploy and maintain compared to other standards, and places
few restrictions on the format of the data to be transmitted.
 The Modbus protocol uses character serial communication
lines, Ethernet, or the Internet protocol suite as a transport layer.
 Modbus supports communication to and from multiple devices
connected to the same cable or Ethernet network.
 For example, there can be a device that measures temperature and
another device to measure humidity connected to the same cable,
both communicating measurements to the same computer.
 DATA TRANSFER THROUGH MODBUS PROTOCOL
 Modbus is often used to connect a plant/system supervisory
computer with a remote terminal unit (RTU) in supervisory
control and data acquisition (SCADA) systems in the electric
power industry.
 Many of the data types are named from industrial control of
factory devices, such as ladder logic because of its use in
driving relays: A single physical output is called a coil, and a
single physical input is called a discrete input or a contact.
 The development and update of Modbus protocols have been
managed by the Modbus Organization since April 2004, when
Schneider Electric transferred rights to that organization.
 The Modbus Organization is an association of users and
suppliers of Modbus-compliant devices that advocates for the
continued use of the technology.
 Modbus Organization, Inc. is a trade association for the
promotion and development of Modbus protocol.
 LIMITATIONS OF MODBUS PROTOCOL
 Since Modbus was designed in the late 1970s to communicate to PLC,
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 whether a register value
represents a temperature between 30 and 175 degrees.
 Since Modbus is a client/server (formerly master/slave) protocol,
there is no way for a field device to "report an exception"
(except over Ethernet TCP/IP, called open-mbus) – the client 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 Parent station (once again, Ethernet TCP/IP is an 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 protocol itself provides no security against unauthorized
commands or interception of data.
 MODBUS PROTOCOL VERSIONS
 Versions of the Modbus protocol exist for serial port and for Ethernet and
other protocols that support the Internet protocol suite. There are
many variants of Modbus protocols:
 Modbus RTU (Remote Terminal Unit) — This is used in serial
communication and is the most common implementation available for
Modbus. Modbus RTU makes use of a compact, binary representation of
the data for protocol communication.
 The RTU format follows the commands/data with a cyclic redundancy
check checksum as an error check mechanism to ensure the reliability of
data. A Modbus RTU message must be transmitted continuously
without inter-character hesitations. Modbus messages are framed
(separated) by idle (silent) periods.
 Modbus ASCII — This is used in serial communication and makes use
of ASCII characters for protocol communication. The ASCII format uses
a longitudinal redundancy check checksum. Modbus ASCII messages are
framed by leading colon (":") and trailing newline (CR/LF).
 Modbus TCP/IP or Modbus TCP — This is a Modbus variant used for
communications over TCP/IP networks, connecting over port 502. It does
not require a checksum calculation, as lower layers already
provide checksum protection.
 Modbus over TCP/IP or Modbus over TCP or Modbus RTU/IP —
This is a Modbus variant that differs from Modbus TCP in that a
checksum is included in the payload as with Modbus RTU.
 MODBUS PROTOCOL VERSIONS
 Modbus Plus (Modbus+, MB+ or MBP) — Modbus Plus is
proprietary to Schneider Electric and unlike the other variants, it
supports peer-to-peer communications between multiple clients.
 It requires a dedicated co-processor to handle fast HDLC-like
token rotation. It uses twisted pair at 1 Mbit/s and includes
transformer isolation at each node, which makes it transition/edge-
triggered instead of voltage/level-triggered.
 Special hardware is required to connect Modbus Plus to a computer,
typically a card made for the ISA, PCI or PCMCIA bus.
 Pemex Modbus — This is an extension of standard Modbus with
support for historical and flow data. It was designed for
the Pemex oil and gas company for use in process control and never
gained widespread adoption.
 Enron Modbus — This is another extension of standard Modbus
developed by Enron Corporation with support for 32-bit integer
and floating-point variables and historical and flow data.
Data types are mapped using standard addresses.
 The historical data serves to meet an American Petroleum
Institute (API) industry standard for how data should be stored.
 Data model and function calls are identical for the first 4 variants of
protocols; only the encapsulation is different. However, the variants
are not interoperable, nor are the frame formats.
 MODBUS PROTOCOL
 Communications and devices
 Each device communicating (i.e., transferring data) on a Modbus
is given a unique address.
 On Modbus RTU, Modbus ASCII and Modbus Plus (which are all RS-
485 single cable multi-drop networks), only the node assigned as
the Client may initiate a command. All other devices are servers
and respond to requests and commands.
 For the protocols using Ethernet such as Modbus TCP, any device
can send out a Modbus command thus all can act as a client,
although normally only one device acts as a Client.
 There are many modems and gateways that support Modbus, as it is
a very simple and often copied protocol.
 Some of them were specifically designed for this protocol.
 Different implementations use wireline, wireless communication,
such as in the ISM band, and even Short Message Service (SMS)
or General Packet Radio Service (GPRS).
 One of the more common designs of wireless networks makes
use of mesh networking.
 Typical problems that designers have to overcome include high
latency and timing issues.
 MODBUS PROTOCOL
 Commands
 Modbus commands can instruct a Modbus device to:
 1. Change the value in one of its registers, that is written to
Coil and Holding registers.
 2. Read an I/O port: Read data from a Discrete and Coil ports,
 3. Command the device to send back one or more values
contained in its Coil and Holding registers.
 A Modbus command contains the Modbus address of the device
it is intended for (1 to 247).
 Only the addressed device will respond and act on the
command, even though other devices might receive it (an
exception is specific broadcastable commands sent to node 0,
which are acted on but not acknowledged).
 All Modbus commands contain checksum information to allow
the recipient to detect transmission errors.
 MODBUS PROTOCOL
 Frame formats
 A Modbus "frame" consists of an Application Data Unit (ADU),
which encapsulates a Protocol Data Unit (PDU):
 ADU = Address + PDU + Error check,
 PDU = Function code + Data.
 The byte order for values in Modbus data frames is most
significant byte of a multi-byte value is sent before the others.
 All Modbus variants use one of the following frame formats.
 Functions and commands
 Prominent conceptual entities in a Modbus server include the
following:
 Coils: readable and writable, 1 bit (off/on)
 Discrete Inputs: read only, 1 bit (off/on)
 Input Registers: read only measurements and statuses, 16
bits (0–65,535)
 Holding Registers: readable and writable configuration
values, 16 bits (0–65,535).
 INTERNET/WEB BASED PLC
 The web server provides a direct connection from the PLC to internet.
 A real-time operating system in the Web server controls the
interaction of the various system components in addition to
allocating tasks to the CPU.
 An Ethernet driver provides the connection to the Transmission
Control Protocol/Internet Protocol (TCP/IP) network.
 Security in the form of a firewall is generally a part of the user's
network infrastructure.
 In the past, remote monitoring and control of industrial
systems and processes took many forms.
 Dedicated lines were at one time the most common form of
communication between a control system and a remote location.
 This had limited application because the control system was not
accessible from multiple locations.
 Modems made it possible to access the control system from
different locations, but they are generally restricted to down-
loading and uploading data files and require a customized interface
to access the control system.
 Also, providing any type of control function between locations is
rather limited.
 INTERNET/WEB BASED PLC
 The Internet and the World Wide Web offer a common and easily
accessible way to deliver data through hypertext links.
 A client server system gives each end user the same interface with
universal access to services on the Web.
 Combining a Web browser and a PLC gives users a simple, graphical
means to access data and reset parameters from any PC tied to the World
Wide Web.
 This makes it easier for users dependent on the graphic interfaces
available for their desktop PC applications to simplify the frustrating
task of extracting useable information from windowless PLCs.
 The Web interface on the M1E runs Web pages on the PLC CPU and
includes an HTTP (Hyper Text Transfer Protocol) interpreter, a TCP/IP
stack, and the normal PLC kernel and language support.
 The Web interface provides access to the PLC by a user at a
remote location through the Internet.
 The interface translates the industry standard Ethernet, TCP/IP, and
HTTP protocols used on Internet into data recognizable to the PLC.
 Using this interface, the user can retrieve data such as PLC
configuration, I/O and register status, operating statistics, diagnostics,
and distributed I/O configurations.
 Updates to the operating software can also be down-loaded through the
Internet.
 INTERNET/WEB BASED PLC
 There is a distinct advantage in retrieving the information
directly from the PLC instead of through a PC network.
 PC-based Web servers require information travel between
the PLC and the PC through the multiple networks in
factories and plants.
 For instance, a typical SCADA package polls numerous points
in a PLC to retrieve live factory data.
 The polling involves executing the protocol stacks on
both the PC and the PLC network board.
 Data is then retrieved from the PLC memory across the
backplane and sent back through the same protocol levels.
 This makes it unsuitable for time-sensitive information.
 Embedding the Web server in the PLC ensures the timely flow
of information required on the factory floor.
 A Web server in the PLC has direct access to this information.
 At the same time, the built-in Ethernet interface allows this
information to be easily shared across the enterprise for faster
decision making.
 INTERNET/WEB BASED PLC
 Web-enabled PLCs can significantly change the way plants are
run, reducing downtime, and increasing productivity.
 A device equipped with an embedded Web server can communicate
proactively.
 If it breaks, or reaches certain preset parameters that indicate it is about
to break, it can send a message to the Original Equipment
Manufacturer (OEM) or maintenance department, describing the
specific problem, and requesting service.
 When breakdowns do occur, Web-enabled equipment allows the OEMs
who built it to remotely monitor and even re-pair their machines,
reducing response time and expenses that ultimately are passed to the
user, including staff time and travel expenses.
 Plant engineers can now fix problems within a factory over the
Web from their office or even from home, eliminating those late-
night trips to the plant.
 This same technology allows plant engineers to simultaneously monitor
multiple plants, making it possible to back up colleagues when they are
out, or even to manage multiple plants from a single location.
 Collecting plant data centrally also permits business managers to assign
new orders based on which plant can deliver the quickest response time
or the lowest cost of production at a particular point in time due to
variations in utility rates, labor costs or other factors.
 INTERNET/WEB BASED PLC
 Enough has been written during the past couple years to convince
most plant managers of the benefits of connecting plant floor
equipment and processes to the Internet or Intranet.
 So, now that we're all convinced of the benefits of web-enabled
automation, what pieces and parts are required to put this
technology to work?
 Basic parts required for web-based data acquisition and control are:
 an interface to the machine or process to be monitored or controlled
via the web (network) connection;
 a web server to make the desired display and/or control pages
available to the remote browser or client;
 a data service or interface to handle exchanging data between the
local machine/process (server) and the remote system (client).
 For remote viewing of the data and/or web pages, the only
requirement is a standard browser interface.
 For applications requiring SPC, optimization, or enterprise level
software to exchange real time data with the machine/process, a
remote server PC and a compatible data exchange service are
required.