Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Report_Monitoring & Control of Water Tank Filling System


Published on

  • Be the first to comment

Report_Monitoring & Control of Water Tank Filling System

  1. 1. I Abstract Technical Project Report Prepared By: HASSAN AKHTER MUZAMMIL EJAZ NOOR SARA FATIMA TARIQ JAMIL WASEEM AKHTER HMI BASED MONITORING AND CONTROL OF WATER TANK FILLING SYTEM The purpose of the project is to design and develop an HMI based monitoring and control of water tank filling system. The system consists of water pumps responsible to feed water to the tank. Status of level alarm switches and field switches, decides the state of the system. The field switch decides whether respective pump is available for operation or it is under maintenance. The system has two modes of operation i.e. manual and auto where each mode has its own constraints. A windows based HMI application is developed for display of system status. The final stage (PLC implementation) is achieved through step by step development of multiphase implementation.
  2. 2. II Contents ACKNOWLEDGEMENT .................................................................................................................................III PROJECT OVERVIEW ....................................................................................................................................2 Description....................................................................................................................................................2 Conditions and Limitations ......................................................................................................................2 PROJECT DEVELOPMENT & IMPLEMENTATION ..................................................................................3 1. Control System Software Implementation (Software Simulation only)................................................6 1.a) Implementation using Logic Gates Only.........................................................................................6 1.b) Implementation using Microcontroller Interfacing with Logic Gates............................................7 2. Design and Development of Windows based HMI Application...........................................................11 3. Control System Hardware Implementation .........................................................................................16 3.a Implementation using Arduino.....................................................................................................16 3.b Implementation using Programmable Logic Controller (PLC)......................................................21 PROJECT SCOPE..........................................................................................................................................26
  3. 3. III ACKNOWLEDGEMENT We are extremely thankful to Mr. Khalid Chaudhry (Managing Director) for giving us the opportunity to handle this project. We extend many thanks to the extremely cooperative staff who guided us throughout the project development. They helped us a lot in performing all the activities and in gaining the practical knowledge. They monitored all of our activities and gave us the best suggestions to accomplish the assigned tasks in an effective manner. Special thanks to the following technical personalities at UEC:  Mr. Khalid Chaudhry Managing Director  Mr. Irfan General Manager  Mr. Jawad Deputy Manager  Mr. Bilal Ahmad Senior Instrument Engineer  Mr. Irfan Instrument and Control Engineer
  4. 4. 1 EXCLUSIVE SUMMARY Before the detailed description of the report, we would like to start with the summary of the work we have done. The basic purpose of this summary is to give an idea about the contents and efforts made behind the completion of the report. This document mainly focuses on practical work performed during project development; however, theory to some extent is also explained wherever it is considered to be necessary. Please refer to respective manual or tutorial of the product for detailed description of any component used (e.g. software or hardware) in the project. We tried our best to explain functions of all the products used, however, these are not described in detail considering conciseness of the report. Only functions required to perform implementation are briefly described with sufficient information. This document gives description, hierarchically, how the project is developed to achieve the final goal.
  5. 5. 2 PROJECT OVERVIEW Description A complete system consists of pumps, level alarm switches, field switches and HMI for display of system status and control. Human Machine Interface (HMI) is a hardware with facility to display the status of all devices and operator interaction to manually send commands to the controller. The commands are based on graphical interaction and operator is unaware what is going behind this. The system has two modes of operation i.e. Manual and Auto. In Auto Mode, pumps run depending upon the priority scheme while rest of them are on standby whereas, for Manual Mode, pumps can be operated through HMI. The state of level alarm switches decides the state of the system to be held. Each pump has a dedicated field switch which decides whether respective pump is available for operation or it is under maintenance. Conditions and Limitations The perfect operation of the system has certain conditions and limitations as below: System Modes: The system can be operated in Manual Mode or Auto Mode. In Manual Mode, the operator can directly turn ON or turn OFF the respective pump from HMI while, in Auto Mode, the operator is unable to change state of any pump, however, the operator can toggle the system mode. In Auto Mode, pumps are subjected to the priority scheme i.e. maximum of two pumps will run at a time. Moreover, considering the whole system is working properly and all devices retain their state, toggling from Auto to Manual mode should not change the state of the pumps. Pumps: Pumps are responsible to feed water to the water tank. There are four pumps and running status of a pump depends upon the system mode, status of level alarm switches and respective field switch. Level Alarms Switches: Level alarm switches contribute only in Auto Mode whereas system operation is independent of their state in case of Manual Mode. There are two level alarm switches (High and Low). Pumps will start when low level alarm switch is active i.e. water level reaches its lower limit in tank and pumps should feed water to the tank. The pumps continue running until high level alarm switch becomes active, after that all pumps must stop regardless of the state of other devices. Field Switches: Field switches contribute in both modes of the system. Each pump has a dedicated field switch. The worker at site can turn ON or OFF the field switch to indicate that the pump is healthy and ready for operation or not. If field switch is ON then respective pump will be available for operation. If field switch is OFF then pump is considered to be under maintenance and it will be unable to run unless its field switch is turned ON. HMI: Manual control interaction facility (i.e. buttons etc.) is disabled when system is in Auto Mode, however, operator can toggle system state. In Manual Mode, operator can start/stop pumps directly from the control buttons on HMI.
  6. 6. 3 PROJECT DEVELOPMENT & IMPLEMENTATION Considering all constraints and functions discussed before, it is the point to describe the project in detail with dedicated tags of all devices and logic schemes as below:  There are four Pumps P1, P2, P3 and P4.  There are four Field Switches FS1, FS2, FS3 and FS4 located at field site.  There are two Level Alarm Switches labeled as Level Alarm Low (LAL) and Level Alarm High (LAH) installed at water tank.  The system has two modes of operation i.e. Auto and Manual abbreviated as A-M.  There are four local switches LC1, LC2, LC3 and LC4. These are windows GUI based control switches directly operated from HMI. In case of Manual Mode, local control switches are enabled (operable) in HMI and pumps priority scheme will be bypassed whereas LAL and LAH have no effect on the system. In this case, pumps are directly under control of the operator while in case of Auto Mode, local switches are disabled for miss-operation from the operator side and pumps are subjected to priority scheme. System Mode, LAL and LAH directly contribute to affect the state of the system. Following figure shows overview of the scenario. Fig - 01 Project Scheme Overview
  7. 7. 4 Following is pumps priority scheme subjected to status of field switches. For field switches the logic “1” represents the field switch is ON and the logic “0” represents the field switch is OFF. For pumps, the logic “1” represents the pump will run and the logic “0” represents pump will not run. Field Switches Pumps Control_RUN Status Validity FS1 FS2 FS3 FS4 Pump1 Pump2 Pump3 Pump4 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 0 1 1 0 0 1 1 0 1 0 0 0 1 0 0 0 1 0 1 0 1 0 1 0 1 1 0 0 1 1 0 0 1 1 1 0 1 1 0 1 0 0 0 1 0 0 0 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 0 1 1 0 0 1 1 1 1 1 1 0 0 In case of Pump1 & Pump2, the logic output is directly dependent only upon status of respective Field Switch. In case of Pump3 & Pump4 Boolean expression can be developed using k-map method. Moreover, level alarm switches and system mode has direct relationship with the output of the respective pump because they are independent of combination of the logics. As Pump1 and Pump2 has direct relationship with their respective Field Switch while logics for Pump3 and Pum4 require k-map method for finding Boolean expression. Thus respective k-maps for Pump3 and Pump4, along with Boolean expressions are as below: P3 FS1, FS2 Boolean Expressions00 01 11 10 FS3,FS4 00 01 P1 = FS1 11 1 1 1 10 1 1 1 P2 = FS2 P4 00 01 11 10 FS3,FS4 00 P3 = FS3 (FS1’ + FS2’) 01 1 1 1 11 1 P4 = FS1’ FS4 (FS2’ + FS3’) + FS2’ FS3’ FS4 10
  8. 8. 5 In the previous section of the document, the complete scenario of the project has been described in detail and next part of the document will cover methods of its implementation. Project is not implemented at advance professional level in a single step rather it is achieved through multiple phases i.e. from software level implementation (simulation) to small hardware level implementation (microcontroller) and then professional hardware level implementation (PLC). The purpose of multiphase implementation is not only to explore different programming languages and methods (e.g. using logic gates only, using C language and Function Block Diagram) but also help the beginners to familiarize them with different methods for sole project implementation. Following methods are used: 1. Control System Software Implementation (Software Simulation only) a. Implementation using Logic Gates Only b. Implementation using Microcontroller Interfacing with Logic Gates 2. Design and Development of Windows based HMI application 3. Control System Hardware Implementation a. Implementation using Arduino b. Implementation using Programmable Logic Controller (PLC) Following table enlist all methods chronologically along with reason of their importance: Sr. No. Development Stage Method of Implementation Method’s Importance 1a Software Simulation Using Logic Gates only Perfect development of logic is verified 1b Using Microcontroller Interfacing with Logic Gates  Conversion of logic into C Program  Duplex communication with HMI to verify controller send/receive commands 2 HMI Design Widows based Application Development Ensures perfect display update against received commands using duplex communication between HMI and controller 3a Hardware Implementation Using Arduino Controller Display on LCD: Hardware Interfacing to verify proper working of controller commands and duplex communication with HMI. Commands for display are written by the controller. Control & Display on HMI: Hardware Interfacing to verify proper working of controller and HMI. Duplex commands and responses are verified. The controller just send the status string to HMI and the HMI is responsible for display of updated system status. 3b Using PLC Professional level implementation with standard Function Block Diagram (PLC programming language).
  9. 9. 6 1. Control System Software Implementation (Software Simulation only) Commencement of the project starts from development of Boolean logic and expression described earlier. At this stage, Boolean expressions are implemented on simulation level only. Following are two different methods used for this purpose: 1.a)Implementation using Logic Gates Only This step of implementation is necessary because it ensures 100 % perfection of the logic developed for the system. At this phase, basic logic gates are used only and in case of inaccurate results, only developed Boolean logic needs to be reviewed. In short, this step is basic building block of the project. Components & Accessories: Software: Proteus with built-in simulator. Description: Referred by water tank level (Fig-01) where LAL=0 & LAH=0, this condition is ignored based on the following arguments:  LAL=0 & LAH =0 or LAL=1 & LAH=1 conditions are invalid and they can’t be true in case level switches are healthy and working properly, however, such cases may arrive due to fault in either of them.  This is ignored because only basic logic gates are used and this condition can’t be solved without using latching components like flip-flop. This situation will be considered in advance level implementation. Boolean logic is implemented using basic logic gates only i.e. AND, OR and NOT gate. Logic States are used to toggle the binary state of devices and Logic Probe are used for display of binary state of the final output i.e. water pumps. A combination of gates is used for implementation of single Boolean expression. Following figure is Proteus diagram of the whole scheme. Fig-02 Circuit Diagram of Proteus Implementation using Logic Gates only In the above figure, all logic states on the top are outputs of devices i.e. inputs to the system. The logic state with the label “PC” is the system mode which is Auto for logic “1” and Manual for logic “0”. The logic
  10. 10. 7 circuit is subdivided into two sections each dedicated to Manual and Auto mode of the system for each pump. System Mode logic state has direct effect on these sections and decides which section should be activated. Once a section is enabled, the other will be masked out independent of the logic state of all devices. Hence, only one of the inputs to final OR gate is activated at a time keeping other ineffective and masked to zero logic state. In short, the subjected output of final OR gate is the output of only one mode at a time. Result: During simulation, logic state of each input of the system was changed to observe its effect on the system. The system output was successfully achieved according to pre-described requirements. 1.b) Implementation using Microcontroller Interfacing with Logic Gates This step of implementation is required to ensure perfect duplex data transmission between HMI and Controller using RS232 protocol, keeping logic scheme unchanged as described in previous method. The health of communication ports and cable connection are also verified. Logic status of certain part of logic scheme, required by HMI, is converted into C program. HMI will be able to change state of the system through communication with the controller. Components & Accessories: Software: Proteus with built-in simulator; mikroC a micro controller programming software; communication cable with DB9 cable connection. Description: At this stage, windows based application HMI is not developed, however, UART terminal of microcontroller programming software “mikroC” is used to send and receive commands through RS232 protocol. Fig-03 shows GUI interface of UART terminal of mikroC. All we need is to establish a COM Port connection, setting of parameters and send/receive data. Fig-04 show circuit diagram for simulation in Proteus software. Authority to change state of five inputs to the controller (4 for local controls and 1 for system mode) is transferred to C Program while operation of rest of them is same as discussed in previous method. Specific characters are sent through RS232 communication and the microcontroller takes predefined action after they are received. These characters are sent through UART terminal in mikroC which is capable of sending and receiving character/string using RS232. Whenever state of any device or system is changed microcontroller update the status and send it to RS232 in form of string. The string consists of character ‘0’ & ‘1’ with limit of 15 characters and each character is dedicated to a specific status tag of the system. Position of each character in the string is predefined. For successful transmission of data between UART Terminal and Proteus, parameters of RS232 must match on both sides. Following setting for RS232 parameters is used: Baud Rate: 9600 bps Stop Bits: One Parity Bit: None Data Bits: 08 State of Level alarms and Field Switches can be changed using logic states while for state change of system mode and local control, character a, b, c, d and e are sent to controller to toggle state of A-M, LC1, LC2, LC3 and LC4 respectively. Whenever microcontroller receives the character “s”, it sends updated status string to RS232. Microcontroller scan state of all devices at inputs, in real-time and whenever state of either of them is changed the controller updates the status array and send it to RS232.
  11. 11. 8 Fig-03 GUI Interface of mikroC UART Terminal The microcontroller C-program is subdivided into four sections as below: Section - I: Initialization of parameters, status array, controller inputs, outputs and UART RS232 port. Section - II: This section of program is dedicated to HMI. The controller scans UART periodically and upon receiving character, it toggles the state of respective parameter, updates status array and sends the updated status array on UART terminal to HMI. Section - III: This is for controller section scanning of inputs and outputs. All inputs & outputs are scanned and status array is updated according to the state of respective input/output. Section - IV: The controller checks whether certain input or output has changed its state or not. In case of change in state, respective parameters is updated accordingly and updated status array is sent to HMI through UART terminal RS232.
  12. 12. 9 Following are status array indices and each represents specific state of system as described below: Array Index Status Tag Logic 0 Logic 1 0 System Mode (AM) Manual Mode enabled Auto Mode enabled 1 Level alarm Low (LAL) Inactive (Water level is above lower limit) Active (Water level is equal to or lower than lower limit) 2 Level alarm High (LAH) Inactive (Water level is below upper limit) Active (Water level is equal to or above than upper limit) 3 Field Switch (FS1) Pump1 - OFF (Unavailable and under maintenance) Pump1 - ON (Available for operations) 4 Field Switch (FS2) Pump2 - OFF (Unavailable and under maintenance) Pump2 - ON (Available for operations) 5 Field Switch (FS3) Pump3 - OFF (Unavailable and under maintenance) Pump3 - ON (Available for operations) 6 Field Switch (FS4) Pump4 -OFF (Unavailable and under maintenance) Pump4 - ON (Available for operations) 7 Local Control (LC1) Turns OFF Pump1 (Manual Mode only) Turns ON Pump1 (Manual Mode only) 8 Local Control (LC2) Turns OFF Pump2 (Manual Mode only) Turns ON Pump2 (Manual Mode only) 9 Local Control (LC3) Turns OFF Pump3 (Manual Mode only) Turns ON Pump3 (Manual Mode only) 10 Local Control (LC4) Turns OFF Pump4 (Manual Mode only) Turns ON Pump4 (Manual Mode only) 11 Pump1 Feedback (FP1) Pump1 is not running Pump1 is running 12 Pump2 Feedback (FP2) Pump2 is not running Pump2 is running 13 Pump3 Feedback (FP3) Pump3 is not running Pump3 is running 14 Pump4 Feedback (FP4) Pump4 is not running Pump4 is running During simulation, character ‘a’ is sent to microcontroller using mikroC UART terminal. This toggles system mode. Whenever system mode is changed to auto mode, pumps run according to priority scheme considering effect of Field Switches. In case of manual mode, pumps are manually turned ON and OFF by sending respective character. The contribution of all other devices is same as described in previous method. Result: During simulation, logic state of each input of the system was changed to observe its effect on the system. The system output was successfully achieved according to pre-described requirements. Data transmission was successful and system behaved to the commands as it was supposed to behave.
  13. 13. 10 Fig - 04 Proteus Circuit Diagram using Microcontroller
  14. 14. 11 2. Design and Development of Windows based HMI Application After successful development of logic and C-program, designing of logic circuit, interfacing and communication with microcontroller, it is feasible to build a windows based HMI application as per requirements. This application is similar to other GUI applications which runs under environment of Windows operating system developed by Microsoft Corporation. It is a Graphical User Interface (GUI) application containing controls in form of push buttons and status in form of LED indicators and many more features. The application is capable of receiving and sending commands through RS232 interface. Its high flexibility provides protection against miss-operation by the operator by enabling and disabling certain properties of the GUI. The operator is restricted to specific commands enabled by the application under specific conditions. Components & Accessories: Software: Microsoft Visual Studio 2010 Description: MS Visual Studio is an Integrated Development Environment (IDE) which is used to develop different types of windows based applications from simple windows forms to web applications including databases. However, scope of MS Visual Studio in HMI development is limited only to simple windows based application with little assistance of databases. Following is overview of interface of MS Visual Studio when windows based application project is created: The overview is distributed into different labeled sections and each of them has its own particular functions: 1. This is toolbox window containing various built in GUI controls. It facilitates drag and drop of controls into the design window. 2. The Solution Explorer window contains all files related to the project created. 3. The Properties window contains the properties and events associated with the selected control in the design window.
  15. 15. 12 4. There are two windows represented by tag 4 and 5. Current view of the window displayed is Design Mode. This mode of window provides GUI interaction. The developer can put GUI controls and indicators etc. in this mode of window so that operator can interact with these controls. There is program code behind this control hidden from the operator and visible only in developer mode. 5. This window contains the whole program code associated with the controls. The code can be organized into a standard programming structure i.e. classes, functions and loops etc. 6. This is tray containing all the controls associated with the system. The operator don’t need to interact with them. The developer only need them to keep the application stable and healthy. These controls are serial port, background worker and timer etc. 7. Toolbar contains all same icons associated with a general windows based GUI application, e.g. copy, paste, cut and save etc. MS Visual studio contains a few special toolbar icons linked to debugging purposes. A complete HMI GUI system is developed having the following functions and facilities for the operator: 1. After launching the HMI application, availability of serial COM Port is checked. The user is notified whether a COM port is available for connection or not. If no port is found, the user is prompted to rescan for COM Ports. 3. The user login form is displayed before final display of the HMI. This is necessary because in case of more than one operators, all events and alarms acknowledgement are recorded against the logged in user. Each user may have different access levels. 4. After login, the operator requires to connect HMI with the serial port so that data transmission can be established. Available COM Ports are enlisted in the list box. HMI controls are enabled after COM Port connection is set up.
  16. 16. 13 The HMI will send character “s” just after COM Port connection is established. The controller sends updated status string against that character. HMI decodes the status array and updates the display of all indicators accordingly with color representation of Green as device is ON and Red as device is OFF. The default color is black until no status update is received from the controller. 5. System Mode section contains a control button, indicator and a timer. System Mode button is enabled and Timer start stop buttons are visible only when COM Port connection is established. System mode can be toggled using button or the timer. After specific time period, the system mode will be toggled automatically. This option is introduced to facilitate the operator to toggle system mode while system mode needs to be toggled periodically or the operator is busy in other tasks. Timer time is set before starting it. After setting time, the start timer button is enabled. As soon as timer is started, the indicator starts blinking, the start button is disabled and stop button is enabled so that the operator can stop the timer if it is required to do so. Stopping the timer doesn’t affect the system mode. However, time set value needs to be reassigned every time before starting the timer. 6. The operator can control the pumps manually only when system is in Manual Mode. In Auto Mode, the local control buttons are disabled to give security against operator interference with Auto Mode scheme.
  17. 17. 14 7. This is indication section of the whole system. Status of all devices is represented by respective LEDs. 8. Main display contains mini active alarm window. Three most recent active alarms are displayed here. For all active alarms, an active alarm window is dedicated for operator to acknowledge alarms. 9. Alarm history window contains all the alarms including active and acknowledged. Alarms history can be deleted but this is only possible if logged in user is administrator. The delete Alarms button prompts for selection of two dates. After confirmation, all the alarms between these two dates will be deleted and they can never be recovered.
  18. 18. 15 10. User account management option is visible only when administrator is logged in. The administrator has privilege to manage accounts. He can add or delete accounts as many as required. Each added user ID is considered by the alarm management system. All alarms acknowledged by certain user are indicated by the category of “Acknowledged by”. The logged in user is responsible for consequences of all alarms and their acknowledgement.
  19. 19. 16 3. Control System Hardware Implementation Software simulation ensured perfect development and working of logic, program, HMI and communication. It means all the upcoming troubleshooting to achieve accurate and efficient working of hardware, will be considered in hardware. Hardware implementation is achieved in two steps. The first implementation is performed on Arduino microcontroller and then, in the second step implementation, a PLC is used. 3.a Implementation using Arduino Arduino implementation is further subdivided into two steps. In the first step, the controller’s inputs, outputs and commands are verified using display on LCD. In the second step, it is interfaced with GUI HMI and duplex transmission with HMI is verified as well. Components & Accessories: Software: Arduino Compiler, HMI Hardware: Arduino development board (Mega 2560), Graphical LCD LM12864DDY, RS232 cable with D9 connectors, breadboard, connection wires and USB (Type-A) to USB (Type-B) cable for Arduino interfacing with programming device (say computer). Description: Arduino development board is good for embedded system developers because it is a complete system of microcontroller interfaced with digital & analogue inputs and outputs, RS232 as well as LCD interfacing. Program is burned through RS232 (USB Type-2) interfaced with programing device using USB (Type-A) to USB (Type-B) cable. This type of interfacing provides plug and play facility to the programming device and program can be transmitted/retrieved from the controller within few seconds. A dedicated Arduino compiler is used to compile the program code. Following figure shows overview of the compiler.
  20. 20. 17 Arduino compiler provides flexibility of adding header file of the graphical LCD, in its library. The header file provides facility to read/write data from/to LCD with the help of predefined functions. These functions are ease to the programmer. All it needs is just calling the function without handling the controller’s pins selection and activation/deactivation. ClearScreen(), ReadData() and WriteData() are some of its main functions. It would be very tedious to communicate with LCD, without using these functions. The Arduino implementation is performed in two steps: 3.a.1 LCD Display: In this step, the controller is in duplex transmission mode. The controller monitors all input and output devices and update status array along with activation of outputs and then send the updated status for display on the graphical LCD. The controller receives commands from mikro-C UART Terminal instead of HMI. For LCD display, Arduino has somewhat different program code as compared to code in previous methods whereas the logic and program distribution is same. The difference lies only in syntax of the code because Arduino compiler do not follow compiling mechanism used by the compilers for PIC microcontrollers. The distribution of the program code is similar to the previous methods with the addition of code for writing data to the LCD. The graphical LCD (LM12864DDY) has display size of 128x64 pixels and it provides a great flexibility of different types of font and character sizes as well. The display is subdivided into two parts by half of the total display area. The both or either of the sections can be activated for display at a time. The data is displayed on graphical LCD referred by cursor coordinates. The cursor coordinates are used to put a character at a specific location.
  21. 21. 18 Following table shows connection pins of the LCD requires to be connected with the Arduino, along with function of each pin: Arduino Pin # LCD Pin # LCD Pin Label LCD pin Function 5V 1 +5V +5 VDC supply voltage GND 2 GND Electrical Ground N/A 3 Contrast in Wiper of contrast pot for LCD contrast 22 4 D0 Data Pins with maximum of 8-bit data carrying capacity 23 5 D1 24 6 D2 25 7 D3 26 8 D4 27 9 D5 28 10 D6 29 11 D7 33 12 CSEL1 half of the LCD Displayst Chip1 Select: Enables 1 34 13 CSEL2 Chip2 Select: Enables 2nd half of the LCD Display N/A 14 Reset Resets LCD display by supplying +5 VDC 35 15 R_W Toggles Read/Write mode of LCD 36 16 D_I Toggles Display RAM/Instruction (RS) mode of LCD data 37 17 EN Enable/Disable data read/write mode of LCD data N/A 18 Contrast out Input pin to adjust contrast of LCD display N/A 19 Backlight +5 Supply voltage to enable LCD backlight GND 20 Backlight GND Ground terminal of LCD backlight The main issue with display on LCD is bigger size of program code for writing data on LCD. This is because each character is placed in LCD using coordinates. Moreover, before putting a character at specified location, it is required to clear that area otherwise character may not look like as it should. The following figure shows the system status is displayed on LCD. Result: During simulation, logic state of each input of the system was changed to observe its effect on the system. The system output was successfully achieved according to pre-described requirements. Data transmission was successful and system behaved to the commands according to predefined requirements. A valid display of system status was achieved in an artistic way.
  22. 22. 19 3.a.2 HMI Display: In this step, the controller is in duplex transmission mode. The controller monitors all input and output devices and update status array along with activation of outputs and then it sends the updated status for display on the graphical LCD. The controller receives commands from windows based application HMI and, in return, the controller sends the updated status to the HMI through RS232. The HMI decodes the received instructions and update the display of the system status. The program code is same as in the previous method except that the code to write data on LCD is excluded and data is sent on RS232 to the HMI instead. Following figure is the overall view of HMI Result: During simulation, logic state of each input of the system was changed to observe its effect on the system. The system output was successfully achieved according to pre-described requirements. Data transmission was successful and system behaved to the commands according to predefined requirements. A valid display of system status was achieved in an artistic way. All functions of HMI were tested, debugged, verified and finalized.
  23. 23. 20 Following is flow chart of program code for Arduino and Microcontroller excluding logic gates interfacing:
  24. 24. 21 3.b Implementation using Programmable Logic Controller (PLC) This is industrial and professional level of implementation of the project. A Programmable Logic Controller is used as a central processing unit for processing instructions. A PLC is more rugged and robust to withstand industrial environments with its own Operating System (OS) whereas a microcontroller lacks such features. The working principle of PLC is similar to microcontroller. The main difference is that it has advance architecture with built-in diagnostics and troubleshooting abilities. A PLC has a dedicated configuration software according to the manufacturer’s choice. However, all PLCs have same basic working principle. The main standard languages used in PLC programming are LAD (Ladder Logic), FBD (Function Block Diagram), STL (Instruction List) and SCL (Structured Control Language). Components & Accessories: Software: TIA Portal v11 PLC Hardware: Siemens PLC CPU 313-C2 DP with 16 Digital Inputs and 16 Digital Outputs. Description: TIA Portal v11 is one of the Siemens newly released PLC configuration software with capabilities of diagnostics and troubleshooting. The software has integrated environment for PLC configuration as well as HMI designing, online monitoring and runtime simulation. Online monitoring enables the engineer to monitor status of all parameters and program block while PLC is in running condition. Simulation provides facilities to debug the program pretending as PLC is running and processing the program. The engineer can change parameters and variables to check their effect on the system output. Following is brief introduction to TIA Portal v11 and Siemens PLC: TIA Portal is a PLC configuration software developed to support PLC and HMI by Siemens. The software has advance features within single environment. Following are its main feature:  Uploading/Downloading programs through multiple communication protocols.  Integrated user friendly environment for tags management and HMI designing with runtime facility.  Easy to manage tags and their automatic update.  Instance conversion from one to another programming language.  Simulation for debugging purposes.  Online monitoring for real time analysis of the process parameters.  Advance features with trace functionality for easy diagnostics and troubleshooting.  It provides facility of migration of projects created in other versions of the software e.g. SIMATIC Manager STEP 7, TIA Portal v12 and v13. The software has user friendly environment with task oriented steps to accomplish the project design. It contains multiple views to illustrate how hardware components are linked to each other. It provides drag and drop facility for tags management and many more features. An engineer can configure hardware, write a program and design a HMI within single environment. Moreover, tags of HMI and PLC are linked in order to reduce the numbers of data tags for a program, thus, improving program processing and performance.
  25. 25. 22 Following is overview of Siemens TIA Portal v11 The above figure shows steps to accomplish the project in a user friendly environment. There are three major steps to do so i.e. (1) Configure a Device (2) Write PLC Program (3) Configure HMI. The third step is optional because the design engineer can use third party HMI software and hardware. However, the scope of the project is limited to online simulation only and TIA Portal v11 provides this facility through one of its main features i.e. Simulation for online monitoring. Following is description of each step: 1. Device Configuration In this step, the required CPU and IO hardware is selected. Addresses for communication with PLC and the addresses of tags associated with IO channels are configured and assigned to the respective IOs.
  26. 26. 23 Under flexible environment of the software, we can arrange hardware graphically in the same manner as we want arrangement of the original hardware thus this reduces time for commissioning. This is the critical part of the configuration because if addresses are not feasible then there will be mismatch in tagging and communication with the PLC and other hardware leading to no operation or malfunctioning of the system. 2. Writing a PLC Program The main focus of the project is to write a PLC program. The program is written in Function Block Diagram (FBD). Each software of a certain brand has its own rule for memory management. Moreover, a Siemens PLC program manages all this in form of Memory Blocks and Operational Blocks. Each block has its own features regarding memory management and ability to link data with other blocks. Following is brief description of them: There are three types of operational blocks and each block can have inputs and outputs for interfacing with other blocks or parameters. Inside the block these Inputs and Outputs are linked with the tags and memory locations, logically. The program code of the block behaves like a function in the C-Program with hybrid access level from local to global:  Organization Block: This block is a system block that contains functions regarding PLC Operating System (OS), diagnostics and Troubleshooting. It is responsible for execution of the program. It allows the program execution to respond to cyclic, time-based and interrupt-driven events.  Function Block: It is a code block that stores its values permanently in a dedicated instance data block, so that they remain available after the block has been executed. This is suitable for program code that read and write values to permanent memory e.g. saving parameters like set-points, counting run hours and many other features.  Function: It is a code block without dedicated memory. No data is available after its execution. This subroutine is suitable for program code that required temporary or no memory for manipulation e.g. scanning of IOs, mathematical calculation and interlocking schemes etc. There are two type of memory blocks. These blocks are similar to permanent memory locations for storing and retrieving user data:  Global Data Block: This data block contains memory areas accessible globally in the whole program of the PLC. Functions can access these memory location for storing and retrieving values of parameters used at multiple locations in the PLC program.  Instance Data Block: An instance data block is assigned to every function block call that transfers parameters. The actual parameters and the static data of the FB are saved in the instance DB. The variables declared in the FB determine the structure of the instance data block. Instance means a function block call. If, for example, a function block is called five times in the S7 user program, there are five instances of this block. In the scope of this project, no storage of permanent values is required so no function block (FB) is required which means no instance data block (Instance DB) is required as well. Only tags, global data block (global DB) and Function (FC) are required for the logic implementations.
  27. 27. 24 Dedicated tags are created for PLC IOs. A FBD language based Function (FC1) is created. The logical program in FC1 is similar to the logic of the program described in previous methods. FC1 is called in OB1 where OB1 executes itself periodically. Following are some snapshots during certain steps of programming the PLC. Fig- Overview of Tags management section
  28. 28. 25 Fig- Overview of FBD program in FC1 Fig- Overview of PLC Simulation Result: During simulation, logic state of each input of the system was changed to observe its effect on the system. The system output was successfully achieved according to pre-described requirements. Data transmission was successful and system behaved to the commands according to predefined requirements. Display of system status was updated perfectly. HMI Implementation is left as future scope of the project.
  29. 29. 26 PROJECT SCOPE The basic principle of the project is to control the outputs considering situation of its inputs. Moreover, it is related to fluid management system which keeps the fluid level within normal limits by starting and stopping the feeding pumps. Thus, this project can be implemented in chemical and food processing industries where we encounter mostly with fluid filling system. Despite industries, this project can also be implemented in building management system to fulfill the requirements of water consumption. More advance features can be added with a little modification or addition in the program e.g. calculation of run time and maintenance hours for each pump, consumption and expenses of electrical energy consumed by the system and accumulated volume of the water consumed. This all leads to the best management of energy and resources with high flexibility and reliability for the operators.