CH4030: Process Control Lab, July-Nov 2025
Department of Chemical Engineering, Indian Institute of Technology, Madras
Programmable Logic Controller
Experiment done on: 03/09/2025
Report submitted on: 09/09/2025
BATCH: Wednesday
GROUP: RCL 1
NAME ROLL NUMBER
Bikash Kumar Nath CH22B058
Nanditha CH22B016
Adithyan D S CH22B049
Sakshi Talapade CH22B118
Jadhav saichaitanya CH22B041
1. Aim
● To program a logic controller using ladder logic to control the level of water in a tank using
inputs from an upper-level sensor and a lower-level sensor.
● To calculate the time needed to drain the tank using a valve and fill the tank using a pump.
2. Abstract
Traditionally, we have used relays in operations such as sequential process control in batch
operations, interlocking systems, alarming and monitoring systems and so on. However, usage of
relays have their own issues such as the need to rewire the configuration whenever there is a local
issue, difficulty in trouble-shooting in large networks, less potential to add new installments to a
network which would also demand a lot of time. This is where automation comes handy and
Programmable Logic Controllers (PLC(s)) play a role. Relay logic is mostly being replaced by
PLCs in process control, sequencing, and interlocks. On implementing PLC(s) we are inherently
making the system smarter. Here are some of the areas where PLC(s) seem to have an upper hand
compared to Relay logic:
Sequence Control of Units
● Start-up and shutdown sequences (distillation columns, reactors).
● Previously done with cascades of relays; now in PLC ladder logic or function blocks.
Timers and Counters
● Relay-based timers were bulky and prone to drift.
● PLCs provide precise, flexible timers and counters
Alarming and Monitoring
● Over/under pressure, temperature alarms were once activated via relays driving sirens/lights.
● Today, PLCs handle alarm logic and drive HMIs (human–machine interfaces)
Interlocking Systems
● Pump start/stop interlocks (e.g., a compressor won’t start unless the cooling water pump is running).
● Used to be wired via relay contacts; now implemented as software interlocks inside PLCs.
In our experiment, we explore a simple Programmable Logic Controller (PLC) including the
construction of a ladder logic, the basics on how the logic is read by the controller, how to operate the
Graphical User Interface (GUI), how to combine logics or networks and implementation of the logic on a
Pump valve system based on the water levels measured with respect to two switches. We also quantified the
time required for complete draining of the tank through the valve as well as the time required to pump water
into the tank, below and above some pre-described levels respectively. This time was then qualitatively
correlated to the cross section of the pipes used in either case.
Figure 1: Rough schematic description of the tank setup during Draining process with respect to
the upper tank
Figure 2: Rough schematic description of the tank setup during Pumping/filling process with
respect the upper tank
3. Introduction / theory
● Hardware part
Here, the hardware part consists of a PC with the inbuilt software, a Programmable Logic
Controller setup, a level controller and two tanks kept one above the other. The PLC setup serves as
an actuator which communicates with the valve and the level controller while implementing the
logic stated on the software. The tank below has a pump which pumps water to the upper vessel
through a pipe of larger cross-section whereas a valve connects the two tanks which help drain the
water from the upper tank to the lower tank. Also the upper tank alone contains 2 switches which
are both considered normally closed (N/C) during filling and normally open when draining. The
two Logical networks we construct in the software are then implemented simultaneously depending
upon the water level with respect to both these switches.
Figure 3: The two tank setup whose valves and pumps are connected to the controllers.
Figure 4: Programmable Logic Controller with inbuilt microcontroller, which can communicate
with the water level controller.
Figure 5: Water level controller which is connected to the pump, valve as well as the PLC trainer
● Software part
Here we use a software which has inbuilt libraries and allows us to construct different
LOGIC from various combinations of the inbuilt blocks. The blocks stand for different components
like NC and NO switches, Pumps, Valves, Holding Contact etc. The holding contact is a
consequence of the output from the pump or the valve in our experiment. We can connect different
blocks together similar to feedback loops and vary the logic in each case. In short, the software has
a user-friendly GUI (Graphical User Interface) which just requires the user to connect blocks and
instantly build logic.
● Logic used : Height-dependent pumping and draining or “Ladder LOGIC”
Let us consider the case where the tank is filled with water entirely. Here the initial states of
both the switches can be described as both Normally-Open (N/O). At this point, Network-2 gets
active, causing the valve to open and water to drain from the upper tank to the lower tank and the
water level will progressively go down below the upper switch. Now, to keep on emptying the tank
we use something called Holding Contact (HC), which is represented by the separate branch in the
LOGIC diagram shown above. The HC is not necessarily a physical entity but arises as a result of
the output provided by the pump/valve at the time of implementation, hence it has the same tag
representation in the software as the pump/valve. Now once HC is active, the system gets the signal
to ‘continue reducing the level of water from a level between the two switches to a level lower than
the second switch’. Now once the draining process is complete, the pumping process starts and
Network-1 is activated. Both switches are now regarded as Normally-Closed when the water level
is below the lower switch. Here, as the water level starts increasing, it reaches the first switch and
then HC element comes into picture which ensures that the level keeps on increasing and does not
stop at an intermediate level. As the level matches with that of the upper switch, Network-1 gets
deactivated and the system shifts to Network-2 i.e. the draining process.
Figure 6: A simple illustration of the constructed logic for Network-1 and Network-2, along with
the direction of Logic Reading.
To summarize, the workflow is as follows :
● Sensor Input: Read water level (e.g., low-level sensor and high-level sensor).
● Control Logic:
➢ If the low-level sensor is activated (water is below a certain point), the pump is
turned on and PUMP water.
➢ If the high-level sensor is activated (water has reached the upper limit), the pump is
turned off and DRAIN water.
4. Apparatus and methods
System Components:
1. Water Tank: Stores water and has predefined minimum and maximum levels as switch
levels.
2. Sensors:
➢ Level Sensors (Float, Ultrasonic, or Pressure Sensors): Detect the water level and send data
to the PLC.
➢ Flow Sensors: Detect the rate at which water flows in or out of the tank (optional).
3. Pump/Valve:
➢ Water Pump: Controls the water flow into or out of the tank.
➢ Valves: Open or close based on water levels to regulate flow.
Procedure
1. Setting up a directory: Open the TIA Siemens software, create and open a new project.
2. Addition and configuration of hardware: Now, click on ‘Add devices’ after switching on
both the PLC and the level controller. Select the appropriate serial number and configure the
hardware part onto the software.
3. LOGIC Construction 1: Once the entire system is configured, we can proceed with the
Logic Construction:
a. We observe the rail and rung as the Y and X axis respectively. Firstly click on the
rung (horizontal line) and add two N/C switches and a Pump, by sequentially
clicking on them
b. Now drag and drop the connecting arrow to the Rail and then add the symbol
corresponding to an N/O switch for the Holding contact, to this branch.
c. Connect this branch to the end-point of the first N/C switch in the first line.
4. LOGIC Construction 2: Once step 3 is done, we have completed Network-1 which
corresponds to the pumping process. Insert a new network now and repeat Step 3 but with
N/O switches instead of N/C switches. Now we have Network-2
5. Tags and names Network-1: Now we have to tag each of the inserted blocks and specify
their names:
a. From left to right, name the first switch as ‘lower’ and the second switch as ‘upper’,
mentioning their tags as ‘GLOBAL INPUT’ in both cases. We can observe the
system giving names like ‘I0.0’ and’I0.1’ to these switches, respectively.
b. For the pump and the HC (in the other branch), name both as ‘pump’ and tag them
as ‘GLOBAL OUTPUT’. Here, the name would look like ‘O0.0’.
6. Tags and names Network-2: Now we have to tag each of the inserted blocks and specify
their names of Network-2 as we did in Step 5.
a. From left to right, name the first switch as ‘upper’ and the second switch as ‘lower’,
mentioning their tags as ‘GLOBAL INPUT’ in both cases. We can observe the
system giving names like ‘I0.1’ and’I0.0’ to these switches, in the reverse order as in
the case with Network-1.
b. For the valve and the HC (in the other branch), name both as ‘valve’ and tag them as
‘GLOBAL OUTPUT’. Here, the name would look like ‘O0.1’.
7. Starting the overall implementation: Fill the upper tank with water and start with the
draining process, simultaneously using a stopwatch to measure the total draining time.
8. Recording time for both processes: Once the draining process is complete, set a lap in the
stopwatch marking the overall draining time. At this point, Network-1 gets active and is
made of solid green lines while Network-2 instantaneously turns to dotted blue lines (The
reverse colour code is observed during the draining process). Once the pumping stops and
the next cycle starts, set the next lap. Thus we have time intervals for draining as well as
pumping.
5. Observation Tables
Note: The recorded time for draining as well as pumping is dependent on the cross sections
of the pipes used. In-fact Equipment-2 had a draining pipe of smaller cross section which
resulted in a very large draining time compared to that in Equipment-1.
Figure 7: Constructed logic in the software for Network-1 and Network-2, i.e. pumping and
draining process respectively.
Tabulated data
● Network 1: Controls the opening/closing of the pump.
Name of component used Tag in the network Corresponding code in
in the network the
network
Closed low-level sensor Tag_1 I0.0
(LLS)
Closed upper-level sensor Tag_3 I0.1
(ULS)
Pump output Tag_2 Q0.0
Open pump relay Tag_2 Q0.0
● Network 2: Controls the opening/closing of the valve.
Name of component used Tag in the network Corresponding code in
in the network the
network
Closed low-level sensor Tag_3 I0.1
(LLS)
Closed upper-level sensor Tag_1 I0.0
(ULS)
Valve output Tag_4 Q0.1
Open valve relay Tag_4 Q0.1
● Time data for Equipment no.1,
Process Time taken to complete
Draining 12 min 51 s
Pumping 19.42s
● Time data for Equipment no.2,
Process Time taken to complete
Draining 41 min 22s
Pumping 26.66s
Comments based on observation
➢ Larger the cross section lesser the time to drain: The pipe cross section in the second
equipment was significantly less than the first, hence the time taken to drain is very large,
almost three and a half times larger compared to that of equipment 1. This is a qualitative
observation as we did not measure the flow rates.
6. Result & Discussion
● Truth Table for Network-1 (Pump):
LLS (I0.0) ULS (I0.1) Pump (Q0.0)
0 0 1
1 0 1
1 1 0
● Truth Table for Network-2 (Valve):
LLS (I0.0) ULS (I0.1) Pump (Q0.1)
0 0 0
1 0 0
1 1 1
6. Precautions
● Make sure to place the correct blocks corresponding to the symbols. Errors like
placing the Pump block symbol in place of a Holding Contact instead of an N/O
switch can change the LOGIC overall.
● Make sure to fill adequate amounts of water in either of the tanks and with no
leakages in either of them.
● Make sure to tag the components right, such as interchanging the labels of the upper
and lower level switches when Network-1 and Network-2 are separately constructed.
7. Acknowledgements
We would like to express our sincere thanks to Prof. Dr. Abhijit P. Deshpande, Dr. Kallol
Roy, Dr. Rashmi Prava Mohanty, and Dr. R. Vinu for their valuable support, guidance, and
encouragement throughout the course and [Link] also like to thank our teaching assistants
for their patience, clear explanations, and practical advice during the experiments, as well as to the
laboratory staff for their assistance in preparing and maintaining the equipment. Last but not the
least, we also acknowledge the university for providing access to its facilities, resources, and
technical infrastructure, without which this work would not have been possible.
8. Appendix
The collected data has already been tabulated. No further data were required for the present
experiment.
8. References
1. Bolton, W. (2015). Programmable logic controllers (6th ed.). Newnes/Elsevier.
2. International Research Journal of Engineering and Technology. (2019). Programmable logic
controller (PLC) and its applications. International Research Journal of Engineering and
Technology (IRJET), 6(11), 151–155. The Importance of the Programmable Logic
Controller “PLC” in the Industry in the Automation Process
3. Wikipedia contributors. (2023, December 5). Programmable logic controller. In Wikipedia.
Programmable logic controller - Wikipedia
4. Process Solutions. (2022, August 31). A brief history of programmable logic controllers
(PLCs). Process Solutions. A Brief History of Programmable Logic Controllers (PLCs) |
Process Solutions, Inc.
5. Foster, M. (2010). A review of programmable logic controllers in control systems education.
American Society for Engineering Education. Retrieved from
[Link]
[Link]
6. Harchandani, R., & Bindu, R. (2014, January). Automation of kiln mill drive in cement
industry using PLC and SCADA. International Journal of Engineering Research &
Technology (IJERT), 3(1). Automation of Kiln Mill Drive in Cement Industry using PLC
and SCADA – IJERT