Module 4

Instrumentation Standard Protocols: HART Protocol, frame structure, programming, implementation

examples, Benefits, Introduction, Advantages and Limitations of Fieldbus, FDS configuration, Comparison
with other fieldbus standards including Device net, Profibus, Controlnet, CAN, Industrial Ethernet, MAP
and TOP. Industrial applications of PLC, SCADA, DCS and open systems for following plants: Cement
plant, Thermal power plant, Steel Plant, Glass manufacturing plant, Paper and Pulp plant.

HART PROTOCOL

Communication Modes

1. MASTER-SLAVE MODE

2. BURST MODE

MASTER-SLAVE MODE

HART is a master-slave communication protocol, which means that during normal operation, each
slave (field device) communication is initiated by a master communication device. Two masters can connect
to each HART loop. The primary master is generally a distributed control system (DCS), programmable
logic controller (PLC), or a personal computer (PC). The secondary master can be a handheld terminal or
another PC. Slave devices include transmitters, actuators, and controllers that respond to commands from
the primary or secondary master.

BURST MODE

Some HART devices support the optional burst communication mode. Burst mode enables faster
communication (3–4 data updates per second). In burst mode, the master instructs the slave device to
continuously broadcast a standard HART reply message (e.g., the value of the process variable). The master
receives the message at the higher rate until it instructs the slave to stop bursting.

Frequency Shift Keying

The HART communication protocol is based on the Bell 202 telephone communication standard and
operates using the frequency shift keying (FSK) principle. The digital signal is made up of two
frequencies— 1,200 Hz and 2,200 Hz representing bits 1 and 0, respectively. Sine waves of these two
frequencies are superimposed on the direct current (dc) analog signal cables to provide simultaneous analog
and digital communications (Figure 1). Because the average value of the FSK signal is always zero, the 4–
20 mA analog signal is not affected. The digital communication signal has a response time of approximately
2–3 data updates per second without interrupting the analog signal. A minimum loop impedance of 230 W is
required for communication.
HART Networks

HART devices can operate in one of two network configurations—point-to point or multidrop.

1. POINT-TO-POINT

2. MULTIDROP

POINT-TO-POINT

In point-to-point mode, the traditional 4–20 mA signal is used to communicate one process variable, while
additional process variables, configuration parameters, and other device data are transferred digitally using
the HART protocol (Figure 2). The 4–20 mA analog signal is not affected by the HART signal and can be
used for control in the normal way. The HART communication digital signal gives access to secondary
variables and other data that can be used for operations, commissioning, maintenance, and diagnostic
purposes.
MULTIDROP

The multidrop mode of operation requires only a single pair of wires and, if applicable, safety barriers and
an auxiliary power supply for up to 15 field devices (Figure 3). All process values are transmitted digitally.
In multidrop mode, all field device polling addresses are >0, and the current through each device is fixed to
a minimum value (typically 4 mA). Use multidrop connection for supervisory control installations that are
widely spaced, such as pipelines, custody transfer stations, and tank farms.

universal hand-held terminal

HART Commands

The HART command set provides uniform and consistent communication for all field devices. The
command set includes three classes: universal, common practice and device specific (Table 1). Host
applications may implement any of the necessary commands for a particular application.

UNIVERSAL

All devices using the HART protocol must recognize and support the universal commands. Universal
commands provide access to information useful in normal operations (e.g., read primary variable and units).

COMMON PRACTICE

Common practice commands provide functions implemented by many, but not necessarily all, HART
communication devices.

DEVICE SPECIFIC

Device-specific commands represent functions that are unique to each field device. These commands access
setup and calibration information, as well as information about the construction of the device. Information
on device-specific commands is available from device manufacturers.

Hart communicates point-to-point, under the control of a master, e.g. a hand-held device

Hart frame format (character-oriented

ESTABLISHING COMMUNICATION WITH A HART DEVICE

Each HART device has a 38-bit address that consists of the manufacturer ID code, device type code, and
device-unique identifier. A unique address is encoded in each device at the time of manufacture. A HART
master must know the address of a field device in order to communicate successfully with it. A master can
learn the address of a slave device by issuing one of two commands that cause the slave device to respond
with its address:

 Command 0, Read Unique Identifier—Command 0 is the preferred method for initiating

communication with a slave device because it enables a master to learn the address of each slave
device without user interaction. Each polling address (0–15) is probed to learn the unique address for
each device.
  Command 11, Read Unique Identifier by Tag - Command 11 is useful if there are more than 15
devices in the network or if the network devices were not configured with unique polling addresses.
(Multidropping more than 15 devices is possible when the devices are individually powered and
isolated.) Command 11 requires the user to specify the tag numbers to be polled.

Hart communicates point-to-point, under the control of a master, e.g. a hand-held device

Hart frame format (character-oriented

DEVICE DESCRIPTION

Some HART host applications use device descriptions (DD) to obtain information about the variables and
functions contained in a HART field device. The DD includes all of the information needed by a host
application to fully communicate with the field device. HART Device Description Language (DDL) is used
to write the DD that combines all of the information needed by the host application into a single structured
file. The DD identifies which common practice commands are supported as well as the format and structure
of all device-specific commands. A DD for a HART field device is roughly equivalent to a printer driver for
a computer. DDs eliminate the need for host suppliers to develop and support custom interfaces and drivers.
A DD provides a picture of all parameters and functions of a device in a standardized language. HART
suppliers have the option of supplying a DD for their HART field product. If they choose to supply one, the
DD will provide information for a DD-enabled host application to read and write data according to each
device’s procedures. DD source files for HART devices resemble files written in the C programming
language. DD files are submitted to the HCF for registration in the HCF DD Library. Quality checks are
performed on each DD submitted to ensure specification compliance, to verify that there are no conflicts
with DDs already registered, and to verify operation with standard HART hosts. The HCF DD Library is the
central location for management and distribution of all HART DDs to facilitate use in host applications such
as PCs and handheld terminals. Additional information, not provided by the DD, may be required by some
host applications for screen formatting and other uses.

Benefits of HART Communication

The HART protocol is a powerful communication technology used to exploit the full potential of digital
field devices. Preserving the traditional 4–20 mA signal, the HART protocol extends system capabilities for
two-way digital communication with smart field instruments. The HART protocol offers the best solution
for smart field device communications and has the widest base of support of any field device protocol
worldwide. More instruments are available with the HART protocol than any other digital communications
technology. Almost any process application can be addressed by one of the products offered by HART
instrument suppliers. Unlike other digital communication technologies, the HART protocol provides a
unique communication solution that is backward compatible with the installed base of instrumentation in
use today. This backward compatibility ensures that investments in existing cabling and current control
strategies will remain secure well into the future. Benefits include:

 Improved plant operations

 Operational flexibility
 Instrumentation investment protection
 Digital communication
Fieldbus

Distributed Computer Controlled Systems (DCCS) communications that are used to connect various
industrial systems, or what are known as Field Buses.

Definition of a Fieldbus.

The augmented term Fieldbus is consisting of two terms, Field and Bus [Fieldbus Introduction]. To start, the
meaning of Field, as defined in industrial world, is a geographical or contextual limited area. From the
industry point of view the Field is an abstraction of the plant levels. As for the term Bus is a well-known
word in computer science as a set of common line that electrically (or even optically) connects various units
(circuits) in order to transfer the data among them. The origin of the fieldbus was to replace any point-to-
point links between the field devices (Field Devices are simply the Sensors and Actuators of the plant) and
their controllers (like PLC's, CNC's …etc.) by a digital single link on which all the information is
transmitted serially and multiplexed in time. We will see that the fieldbus transfers, in most cases, this
information in small-sized packets in serial manner. Choosing the serial transmission has many merits in
comparison with other kinds of transmission like parallel transmission. For instance, the sequential or serial
transmission reduces the total required number of the connecting lines over greater distances than that of the
point-to-point or even parallel transmissions. A set of rules must be defined in order to accomplish data
transfer between the units along the bus. This set of rules is called Communication Protocol or just the
Protocol.

Different Types of Fieldbuses

As we seen before, the fieldbus technology started at the early beginnings of the 80's of the previous century
in many countries on the national level. For examples, in France; the Factory Instrumentation Protocol
(FIP), in Germany both; the Controller Area Network (CAN), and the Process Field Bus (PROFIBUS), and
in Denmark; the Process Network (P-NET) protocol, are all appeared in the same time period at the
beginning of the 1980's [Tovar 99-2]. The standardization efforts started at the same time and on the
international level at the International Electro-technical Commission (IEC). Several new architectures were
proposed on exiting old products. For examples, the MIL 1553B (Haverty, 1986), HART (Rosemount,
1991) or BITBUS (Intel, 1984) were all either products or at least prototypes. At this stage some other
protocols were plain proposals on papers only like the FIP and PROFIBUS. Therefore, until the end of the
80’s no progress was achieved at this level. In fact, only in 1993 the first international standard has been
agreed: the physical layer with the following model information (IEC 1158-2, 1993). At the national and
regional levels, the standardization has made more progress than that of the international level. For
examples, the P-NET is a Danish national standard since 1990 (DS 21906, 1990), PROFIBUS is a German
standard since 1990 (DIN 19245, 1990), and FIP (later re-named as WorldFIP) is a French standard since
1989 (NF C46, 1989). Each protocol has addressed different technical options. As a consequence of the
difficulty to achieve a truly international fieldbus standard, in 1995 the CENELEC (European Committee
for Electrotechnical Standardization) proposed an intermediate European standard, comprising the three
national standards existing in Europe: P-NET, PROFIBUS and WorldFIP. This initiative led, in 1996, to the
standard number EN 50170. Although this European standard is a set of non-compatible profiles, it
simplifies the choice of fieldbuses in Europe, from several tens of fieldbus options down to three [Tovar 99-
2]. An additional proposal is being considered as a forth profile within the EN 50170: the Fieldbus
Foundation. Fieldbus Foundation was formed in late 1994 from a merger of WorldFIP North America and
the Interoperable Systems Project. In 1996, Fieldbus Foundation introduced its own specification (BSI DD
238, 1996), which is now being considered for the EN 50170. Other committees within international
standardization bodies have been working to define other LAN technologies for specific application
domains. Within ISO (International Organization for Standardization) and IEC, there are some of the more
relevant like: ISO TC72, for the Textile Industry, ISO/IEC-JTC1 SC25, for the Home Automation, IEC
TC9, for the Trains, ISO TC8, for the Ships and Shipbuilding, ISO TC67, for the Mineral and oil Industries,
and ISO TC82, for Mining Industry only. At the European level, some of the more relevant are CEN TC247
of the Building Automation applications and CEN TC251 which dedicated for Medical Domain and
Hospitals. Still, until this moment lots of different Fieldbus protocols are being developed and sold out.
Some are also being standardized at the international level. For instance, Interbus-S (DIN 19258, 1995) and
Actuator to Sensor Interface or ASI (ASI, 1996), among others, are being considered as new standards like
the EN 50254 for the high efficiency communications subsystems for small data packages. Also being
considered is the PROFIBUS-PA (DIN 19245-4, 1996) and the Device WorldFIP (NF C46-638, 1996)
simplified variants of PROFIBUS and WorldFIP, respectively. For instance, ASI does only aim to inter-
connect boolean-state devices and its frame only supports a reduced number of data bits. Other trials have
experienced a different direction in evolution. Take the CAN (Controller Area Network) which is a success
story. It was originally designed for use within road vehicles to solve cabling problems arising from the
growing use of microprocessor-based components in vehicles. CAN was standardized by ISO (ISO 11898,
1993) has a "Road Vehicle - Interchange of Digital Information" system and since then it is a standard for
the automotive applications, a domain area where VAN (ISO 11519, 1995) is a small contender of the CAN.
Due to its very interesting characteristics, CAN is also being considered for the automated manufacturing
and distributed process control environments, and is being used as the communication interface with other
architectures, such as DeviceNet [Tovar 99-2]. In the next section we will concentrate on the CERN fieldbus
protocols recommendations and we will spot on these protocols in brief.

The working group finally found out that recommending one fieldbus may not satisfy all the users, so
instead they had recommended three Fieldbuses. These are:

 Controller Area Network (CAN).

 Process Field Bus (PROFIBUS).
 World Factory Instrumentation Protocol (WorldFIP).

Controller Area Network (CAN):

The CAN protocol is a priority-based bus network using a Carrier Sense Multiple Access with Collision
Avoidance (CSMA/CA) medium access scheme. In this protocol any station can access the bus whenever it
becomes idle. However, unlike to the Ethernet networks, the collision resolution is non-destructive, which
means that one of the messages being transmitted will succeed. The collision resolution mechanism is very
simple and is supported by the frame structure, or more specifically by its twelve leading bits, denoted as
start bit and identifier fields. This identifier field serves for two different purposes. On one hand it is used to
identify any message stream in a CAN network. Take for example a sequence of messages concerning the
remote reading of a specific process variable. On the other hand, it is a priority field, which enables the
collision resolution mechanism to schedule the contending messages. This collision resolution mechanism
in CAN works as follows. when the bus becomes idle, every station with pending messages will start to
transmit. Due to its open-collector nature, the CAN bus acts as a big AND-gate, where each station is able to
read the bus status. During the transmission of the identifier field, if a station is transmitting a "1" and reads
a "0", it means that there was a collision with at least one higher-priority message, and this station aborts the
message transmission at once. Thus the highest-priority message being transmitted will proceed without
encountering any collision, and thus will be successfully transmitted to its destination. Obviously, each
message stream must be uniquely identified. The collision resolution mechanism that is used by the CAN
protocol imposes strict limitations to the bus length and its transmission data rate. For example, considering
a bus length of 40m, the maximum data rate is 1Mbps. The longer buses are possible but at the cost of a data
rate reduction.

Process Field Bus (PROFIBUS):

The PROFIBUS protocol is based on a token passing procedure used by master stations to grant the bus
access to each other, and a master-slave procedure used by master stations to communicate with slave
stations. The PROFIBUS token passing procedure uses a simplified version of the Timed-token protocol.
The medium access functions which are implemented at the layer-2 of the OSI reference model, is called
Fieldbus Data Link (FDL). In addition to controlling the bus access and the token cycle time, the FDL is
also responsible for the provision of data transmission services for the application layer. PROFIBUS
supports four data transmission services which are: Send Data with No-Acknowledge (SDN); Send Data
with Acknowledge (SDA); Request Data with Reply (RDR) and Send and Request Data (SRD). The SDN is
an unacknowledged service used for broadcasts from a master station to all other stations on the bus. An
important characteristic of other services is that they are immediately answered, with a response or an
acknowledgement. This feature, also called "immediate-response", is particularly important for the real-time
bus operation. In addition to these services, industrial applications sometimes require the use of periodical
transmission methods. A FDL-controlled polling method (i.e. cyclical polling) may be used to scan field
devices, such as sensors or actuators. PROFIBUS enables a poll list to be created at the FDL layer, allowing
the execution of cyclical polling services based on RDR and SDR services.

PROFIBUS encompasses several Industrial Bus Protocol Specifications, including PROFIBUS-DP,

PROFIBUSPA, PROFIBUS-FMS, PROFInet, PROFIBUS-safe, and PROFIBUS for motion control.

(a) PROFIBUS-DP. PROFIBUS-DP is the main emphasis for factory automation; it uses RS485
transmission technology, one of the DP communications protocol versions, and has widespread usage for
such items as remote I/O systems, motor control centers, and variable speed drives. PROFIBUS-DP
communicates at speeds from 9.6 kbps to 12 Mbps over distances from 100 to 1200 m. PROFIBUS-DP does
not natively support intrinsically safe installations. More than 2500 PROFIBUS-compliant products are
available from which you can select best-in-class devices to suit your individual needs, with alternative
sources usually available.
(b) PROFIBUS-PA.

PROFIBUS-PA is the main emphasis for process automation, typically with MBP-IS transmission
technology, the communications protocol version DP-V1, and the application profile PA devices.
PROFIBUS-PA is a full-function Fieldbus that is generally used for process level instrumentation.
PROFIBUS-PA communicates at 31.25 kbps and has a maximum distance of 1900 m per segment.
PROFIBUS-PA is designed to support intrinsically safe applications. PROFIBUS is also tailored to process
automation requirements. It is of modular design and comprises the communication protocol PROFIBUS-
DP, different transmission technologies, numerous application profiles, and structured device integration
tools. Typical PROFIBUS-PA applications are formed by combining modules suited for or required by the
respective applications.

(c) PROFIBUS-FMS .

PROFIBUS-FMS is designed for communication at the cell level according to Fieldbus message
specification. At this level programmable controllers (e.g., PLC and PC) communicate primarily with each
other. In this application area a high degree of functionality is more important than fast system reaction
times. FMS services are a subset of the services (MMS = Manufacturing Message Specifi cation, ISO 9506)
which have been optimized for Fieldbus applications and to which functions for communication object
administration and network management have been added. Execution of the FMS services via the bus is
described by service sequences consisting of several interactions which are called service primitives.
Service primitives describe the interaction between requester and responder.

(d) PROFInet.

PROFInet is the leading Industrial Ethernet standard for automation that includes plant-wide Fieldbus
communication and plant-to-offi ce communication. PROFInet is designed to work from I/O to MES and
hence can simultaneously handle standard Ethernet transmissions and real-time transmissions at 1 ms
speeds. PROFInet embraces industry standards like TCP/IP, XML, OPC, and ActiveX. Because of the
integrated proxy technology it connects other Fieldbuses in addition to PROFIBUS, thus protecting the
existing investmentin plant equipment and networks (whether that is PROFIBUS or another Fieldbus).

(e) Motion control with PROFIBUS .

Motion control with PROFIBUS is the main emphasis for drive technology using RS485 transmission
technology, the communications protocol version DP V2, and the application profi le PROFI drive. The
demands of motion control propelled the implementation of functionalities such as clock cycle
synchronization or slave-to-slave communication. Decentralized drive applications can be realized
economically by means of intelligent drives, since PROFIBUS now also permits the highly dynamic
distribution of the technological signals among the drives.
f) PROFI-safe.

PROFI-safe is the main emphasis for safety relevant applications (universal use for almost all industries),
using RS485 or MBP-IS transmission technology, one of the available DP versions for communication, and
the application profile PROFI-safe. PROFIBUS is the very first Fieldbus in merging standard automation
and safety automation in one technology, running on the same bus, using the same communication
mechanisms, and thus providing highest efficiency to the user. This supports simple and cost-effective
installation and operation.

Industrial Ethernet.

Recognizing that Ethernet is the leading networking solution, many industry organizations are porting the
traditional Fieldbus architectures to Industrial Ethernet. Industrial Ethernet applies the Ethernet standards
developed for data communication to manufacturing control networks ( Fig. 3.20 ).

Using IEEE standards-based equipment, organizations can migrate all or part of their factory operations to
an Ethernet environment at the pace they wish. Instead of using architectures composed of multiple separate
networks, Industrial Ethernet can unite a company ’ s administrative, control-level, and device-level
networks to run over a single network infrastructure. In an Industrial Ethernet network, Fieldbus-specific
information that is used to control I/O devices and other manufacturing components are embedded into
Ethernet frames. Because the technology is based on industry standards rather than on custom or proprietary
standards, it is more interoperable with other network equipment and networks. Although Industrial
Ethernet is based on the same industry standards as traditional Ethernet technology, the implementation of
the two solutions is not always identical. Industrial Ethernet usually requires more robust equipment and a
very high level of traffic prioritization when compared with traditional Ethernet networks in a corporate data
network.
The primary difference between Industrial Ethernet and traditional Ethernet is the type of hardware used.
Industrial Ethernet equipment is designed to operate in harsh environments. It includes industrial-grade
components, convection cooling, and relay output signaling. And it is designed to operate at extreme
temperatures and under extreme vibration and shock. Power requirements for industrial environments differ
from data networks, so the equipment runs using 24 V of DC power. To maximize network availability, it
also includes fault-tolerant features such as redundant power supplies. Industrial Ethernet environments also
differ from traditional Ethernet networks in their use of multicasting by hosts for certain applications.
Industrial applications often use producer – consumer communication, where information ― produced ‖ by
one device can be ― consumed ‖ by a group of other devices. In a producer – consumer environment, the
most important priority for a multicast application is to guarantee that all hosts receive data at the same
time. A traditional Ethernet network, on the other hand, focuses more on the efficient utilization of
bandwidth in general, and less on synchronous data access. To help optimize synchronous data access,
Industrial Ethernet equipment must include the intelligence and Quality of Services (QoS) features needed
to enable organizations to appropriately prioritize multicast transmissions.

Ethernet technology can provide not only excellent performance for manufacturing applications, but a wide
range of network security measures to provide both confidentiality and data integrity. Confidentiality helps
ensure that data cannot be accessed by unauthorized users. Data integrity protects data from intentional or
accidental alteration. These network security advantages protect manufacturing devices like programmable
logic controllers (PLCs) as well as PCs, and apply to both equipment and data security. Manufacturers can
use many methods to help ensure network confidentiality and integrity. These network security measures
can be grouped into several categories, including access control and authentication, and secure connectivity
and management. Access control is commonly implemented using firewalls or network-based controls
protecting access to critical applications, devices, and data so that only legitimate users and information can
pass through the network. However, access-control technology is not limited to dedicated firewall devices.
Any device that can make decisions to permit or deny network traffic, such as an intelligent switch, is part
of an integrated access-control solution. When designing an access-control solution, network administrators
can set up filtering decisions based on a variety of criteria, such as an IP address or TCP/UDP port number.
Intelligent switches can provide support for this advanced filtering to limit network access to authorized
users. At the same time, they can enable organizations to enforce policy decisions based on the IP or MAC
address of a laptop or PLC. Virtual LANs (VLANs) are another access-control solution, providing the
ability to create multiple IP subnets within an Ethernet switch. VLANs provide network security and
isolation by virtually segmenting factory floor data from other data and users. VLANs can also be used to
enhance network performance, separating low-priority end devices from high-priority devices. Access
controls can also include a variety of device or user authentication services. Authentication services
determine who may access a network and what services they are authorized to use. For example, the 802.1x
authentication protocol provides port-based authentication so that only legitimate devices can connect to
switch ports.
Authentication services are an effective complement to other network security measures in a manufacturing
environment. To provide additional protection for manufacturing networks, organizations can take several
approaches to authenticate and encrypt network traffic. Using virtual private network (VPN) technology,
Secure Sockets Layer (SSL) encryption can be applied to application-layer data in an IP network.
Organizations can also use IP Security (IPSec) technology to encrypt and authenticate network packets to
thwart network attacks such as sniffing and spoofing. VPN client software, together with dedicated VPN
network hardware, can be used to encrypt device monitoring and programming sessions, and to support
strong authentication. Manufacturers can also use Secure Shell (SSH) Protocol encryption for remote
terminal logins to network devices. Version 3 of Simple Network Management Protocol (SNMP) also offers
support for encryption and authentication of management commands and data.

World Factory Instrumentation Protocol (WorldFIP):

A WorldFIP network interconnects stations with two types; either a bus arbitration station or
production/consumption stations. At any given time instant, only one station can be the bus arbitration
station. Hence, in WorldFIP, the medium access control is centralized, and performed by the active bus
arbitrator or what is known as the BA. WorldFIP supports two basic types of transmission services:
exchange of identified variables and exchange of messages. In this sub-section we will address the exchange
of identified variables only, since they are the basis of the WorldFIP real-time services. The exchange of
messages is used to support manufacturing message services. In WorldFIP, the exchange of identified
variables is based on a Producer/Consumer model, which relates producers and consumers within a
distributed system. In this model, for each process variable there is only one producer, and one or several
consumers. For instance, consider the variable associated with a process sensor. The station that provides

the variable value will act as the variable producer and its value will be provided to all the consumers of the
variable (e.g., the station that acts as process controller for that process variable, the station that is
responsible for building an historical database, or even a supervisory node that monitors this variable
value).In order to manage any transactions associated with a single variable, a unique identifier is associated
with each variable. The WorldFIP Data Link Layer (DLL) is made up of a set of produced and consumed
buffers, which can be locally accessed (through application layer services) or remotely accessed through
network services. In WorldFIP networks, the bus arbitrator table (BAT) regulates the scheduling of all
buffer transfers. There are two types of buffer transfers that can be considered in WorldFIP. These are:
periodic and aperiodic (sporadic). The BAT imposes the schedule of the periodic buffer transfers, and also
regulates the aperiodic buffer transfers in the times that there are no periodic buffer transactions.

Comparison between different types of Field Buses:

PLC Safety Rules

• Use a fail-safe design.

• Make the program inaccessible to unauthorized persons.

• Use predictable, non-configurable programs.

• Use redundancy in hardware.

• Directly connect emergency stops to the PLC, or the main power supply.

• Check for system OK at start-up.

• Provide training for new users and engineers to reduce careless and uninformed mistakes.

• Use PLC built in functions for error and failure detection.

Troubleshooting

1. Look at the process and see if it is in a normal state. i.e. no jammed actuators, broken parts, etc. If there
are visible problems, fix them and restart the process.

2. Look at the PLC to see which error lights are on. Each PLC vendor will provide documents that indicate
which problems correspond to the error lights. Common error lights are given below. If any off the warning
lights are on, look for electrical supply problems to the PLC.

HALT - something has stopped the CPU

RUN - the PLC thinks it is OK (and probably is)

ERROR - a physical problem has occurred with the PLC

3. Check indicator lights on I/O cards to see if they match the system. i.e., look at sensors that are on/off,
and actuators on/off, check to see that the lights on the PLC I/O cards agree. If any of the light disagree with
the physical reality, then interface electronics/mechanics need inspection.

4. Turn the PLC off and on again. If this fixes the problem it could be a programming mistake, or a
grounding problem. Programming mistakes often happen the same way each time. Grounding problems are
often random, and have no pattern.

5. Consult the manuals or use software if available. If no obvious problems exist, the problem is not simple
and requires a technically skilled approach.

6. If all else fails call the vendor (or the contractor) for help.
Fault Detection and Interrupts

• The PLC can be set up to run programs automatically. This is normally done for a few reasons,

- to deal with errors that occur (eg. divide by zero)

- to run a program at a regular timed interval (eg. SPC calculations)

- to respond when a long instruction is complete (eg. analog input)

- when a certain input changed (eg. panic button)

• Two types of errors will occur - terminal (critical) and warnings (non-critical). A critical failure will
normally stop the PLC.

• In some applications faults and failures must be dealt with in logic if possible, if not the system must be
shut down.

• There are some memory locations that store indications of warning and fatal errors that have occurred. The
routine in program file [S:29] needs to be able to detect and clear the fault.

S:29 - program file number to run when a fault occurs

• To set a timed interrupt we will set values in the status memory as indicated below. The program in file
[S:31] will be run every [S:30]ms.

S:30 - timed delay between program execution - an integer number of ms

S:31 - the program number to be run

• To cause an interrupt when a bit changes the following bits can be set.

S:46 - the program file to run when the input bit changes

S:47 - the rack and group number (eg. if in the main rack it is 000)

S:48 - mask for the input address (eg. 0000000000000100 watches 02)

S:49 - for positive edge triggered =1 for negative edge triggered = 0

S:50 - the number of counts before the interrupt occurs 1 = always up to 32767
Shielding and Grounding

• In any sort of control system, wire still carries most inputs/outputs/communications

• We transmit signals along wires by pushing/pulling electrons in one end of the metal wires. Based upon
the push/pull that shows up at the other end, we determine the input/output/communications. *** The key
idea is that a signal propagates along the wire.

• There are two problems that occur in these systems.

1. Different power sources in the same system can cause different power supply voltages at opposite ends of
a wire. As a result, a current will flow and an unwanted voltage appears. This can destroy components and
create false signal levels.

2. Magnetic fields crossing the long conductors or in conductor loops can induce currents, destroy
equipment, give false readings, or add unwanted noise to analog data signals.

• General design points

- Choose a good shielding cabinet

- Avoid ―noisy‖ equipment when possible

- Separate voltage levels, and AC/DC wires from each other when possible.

• typical sources of grounding problems are:

- Electrostatic

- Magnetic

- Electromagnetic

- Resistance coupled circuits

- Ground loops

• Shielded wire is one good approach to reducing electrostatic/magnetic interference. The conductors are
housed in a conducting jacket or the circuitry in housed in a conducting metal cabinet.

• Resistance coupled devices can have interference through a common power source, such as power spikes
or brownouts caused by other devices in a factory.

• Ground loops are caused when too many separate connections to ground are made creating loops of wire
that become excellent receivers for magnetic interference that induces differences in voltage between
grounds on different machines. The common solution is to use a common ground bar.