EET310 – Programmable Controllers and Robotics

Class Project

By: Brett Bloomberg

Instructor: William Routt

Online EET DepartmentECPI UniversityDate: 10/21/2016

ECPI’s Honor Pledge: I pledge to support the Honor System of ECPI. I will refrain from any form of academic dishonesty or deception, such as cheating or plagiarism. I am aware that as a member of the academic community it is my responsibility to turn in all suspected violators of the honor code. I understand that any failure on my part to support the Honor System will be turned over to a Judicial

Review Board for determination. I will report to a Judicial Review Board hearing if summoned.Brett Bloomberg

Objective:

This class project brought together 4 unique engineering students to solve and program a PLC to a specific application. We used all of our knowledge that we gained throughout the class to get the system to perform at its best with minimal errors of operation. This project helped us learn and grow from one another. We were able to bring different approaches to light to help us see if there was a better way to program this application that we were asked to do. Our team had many different talents and skill sets that made this project enjoyable, and a good learning experience. We would talk about solving different issues that our program had and come up with a better solution that we all thought was easiest to program.

Intro:

This class project asked us to create a PLC program that would complete an automated task. This lab asks us to complete a PLC program that mixes and pumps two liquids into the same tank and heats them for a certain amount of time. With this lab we used our skills and education that we gained through out term. We worked in a group to build, design, implement the ladder logic, and troubleshoot the application. This took every bit of the education that we learned and kept us thinking. We were able to understand each and every aspect of this application and lab. The class and lectures were what gave us the foundation for to be able to execute the program.

Our group went through many different application coding changes. Some of us didn’t see eye to eye at first on how the program was to be coded, and some of us went above and beyond what the application was asking for. We went through 4-5 main changes of the program and each of us I believe tackled some aspects in our own way that we thought was best. We did have some disagreements, but it wasn’t a drag out fight just explaining each side and why we programed it the way we did. Each rendition of the code changed and improved dramatically with each new version. Once we were all on the same page I believe we found a very highly functioning ladder logic code for this application. We believe it would give minimal errors that would require user intervention. We were thinking about going deeper into the project with the errors and making an error log that would pop up every time something unexpected would happen. This wasn’t in the scope of the assignment and would have taken much more interaction. Instead we just did the basic ladder logic code redundancy of making sure that the idle light isn’t on while the system is running. We could have made sure the that tank wasn’t full while being in idle, but that did require a lot more work and we thought that it would be outside the scope of the assignment.

Lab question:

The lab tells us that two ingredients a and B are to be heated and mixed together. Two pumps P1 and P2 provide the necessary pressure to send the ingredients through the lines. The procedure is as follows.

The start pushbutton is pressed to start the process and pump 1 (P1)

After 100 gallons of ingredient A is pumped into the tank, P1 turns off and stops automatically and the heater is automatically turned on.

The heater is automatically turned off after 2 seconds, and P2 is energized.

Ingredient B is pumped into the tank, by P2 until the liquid reaches the high level sensor.

The mixer motor starts automatically and runs for 10 seconds.

After the mixer motor stops P3 discharges starts automatically and runs until the low level sensor is actuated.

The process stops.

The process can be stopped at any time, by means of the stop button, without loss of the counter accumulated count or the timer accumulated time.

The idle light is energized whenever the process is stopped.

The run light is energized whenever the process is in operation.

The full light is energized whenever the tank is full.

Class project report:

This was an experience to work in a group to be able to solve and figure out the finer details of the program and how to solve the issues that would come up with them. We discussed the proper way to reset the timers and counters. With my program I was lazy I will admit, and I didn’t want to sit there and turn on and off a switch for 100 times to make the program run. I lowered each requirement to make the automation go quicker for monitoring purposes when the program was running. We also used some internal bits and latching and unlatching outputs. These were very useful to use, but required some modifications and reworks to get just right. These bits took us a while to get working properly and were one of the major concerns we had while working on the project. Another major issue we had was when to reset all the clocks and counters. Eventually we decided to reset all the counters and timers when the low level limit switch is made that is when the project is done and waiting for a user to start the program again. One of the final parts we had that took a while for us to decide on what the pilot lights. We started with some very simple ladder logic for these lights, and most of the group that that it was ok. We didn’t think about the error aspect of it until later. There were times in our program that would have the idle light and the running light on at the same time, and the full light and idle light. These combinations should never be on together at the same time. We could have used internal locking bits that would turn on and off each part of the automation process, but we decided that since the process ran one time and didn’t stop until the tank was filled up and drained we didn’t think it was necessary to stop each part if the idle was still on or if the tank was full and it was in idle mode.

In the end I believe we were able to overcome our differences and make sure the application worked as intended. We had a lot of discussions about how to go about solving each portion of the problem. We were able to build a team and work well with one another. This was a great exercise in team building, and I really enjoyed the environment that the group made by being open and communicating as best we could. It was a group experience that made us all better engineers.

Procedures:

With the project I took many different screen shots and I got complete ladder logic program. I will post all pictures again after the conclusion to make sure I didn’t forget to post any pictures, but as another reference as well. The code is as follows.

This program may seem basic but it does cover a wide range of techniques and coding that allows the application to be completed. There are many different approaches that a programmer can take to make this application work. I believe a lot of it has to do with the way the person thinks and how they handle the different tasks and the through process. At first looking at everything that the program required us to do I was a bit overwhelmed by the amount of counters and timers and how to make each input work properly. In the end I decided to code one rung at a time. My code is as follows and I believe that it works as the question and lab intended.

With this program we had many different paths that we were taking in order to complete the task. At first I was thinking about using a jump command and not even using the latches at first. It would have been a different program and still would have worked. One thing I like about programing PLC’s and in general computer programing. It is very interesting to see how you can make one automated program and have it coded and worked multiple different ways.

Our group did have issues with how the pilot lights should work. It wasn’t a big issue I guess but one where communication became somewhat difficult. It took a lot to overcome this disagreement, and I honest don’t believe that it was completely taken care of. With group projects this is going to happen, and it takes a group of individuals willing to work with one another to be able to keep the lines of communication open during a disagreement. I believe that this was a very big learning experience for me in terms of communication and working with a group that doesn’t think the same way. I have honestly never been in this type of situation. It was a good educational avenue to be able to communicate and work with the ones that weren’t communicating and putting in all the effort that they could.

This is the start of the program. Our group decided to use latches in order to start and stop the program. This basic start control setup allows us to start and stop the system and skill keep all the counter numbers. We used the stop button with the low level sensor to ensure that the system went into idle mode once that low level sensor is made. This way the system will shut down properly in case if there is an error or something doesn’t go right. The start will latch the internal bit and keep it on until the stop button is pushed, or the low level sensor is made. The internal relay also activates the MCR or master control relay which needs to remain active for the program to automate.

This next part of the program we have the main pump source the 100 gallon counter and the master reset. We decided to put the master reset that resets all the counters and timers on the low level sensor. Our reasoning for this is because once the low level sensor is made the automation is over, and it no longer needs to keep track of the gallons pumped and the time it’s mixed. At that point the process is over and the system is in idle mode waiting to be started again. Once the start button is pushed it latches on the internal bit which starts the first pump. This rung then latches onto itself to keep running until the flow sensor has completed 100 gallons filled into the tank. Once the counter has counted to 100 by the from the flow of gallons it opens up the pump which causes it to turn off. They way once it’s done pumping the first 100 gallons into the tank the pump will actually shut off.

This next section of code is broken into a few parts. Once the counter has completed its task of pumping the material into the tank it immediately begins to heat the material that was poured into the first tank. It heats this for 20 seconds. We used the TT command of the counter that way when the counter is timing the heater is also on, but once the time is done the heater will turn off. At this point in the program once it is done heating the first material a second pump turns on. This fills the tank with another fluid and fills it up until the tank is full which is indicated by the high level sensor that is being used. Once the high level sensor is made it will open up the normally closed high level sensor in series with the pump output which will in turn unmake or DE energize the pump. After this task is complete it starts to mix the two materials together. It does this for 10 seconds. When the mixing is finished pump 3 is turned on and the draining of the tank begins. Once the tank gets to a certain low point the low level sensor will be energized and turn off the drainage pump. Then next rung after that is the end classification of the MCR.

In our group this was the section that we had the most difficulty with coming to a decision on how to make it work or not. Above is how the rest of the group wanted it. Below is how I thought it should be coded. As you can see from the picture above the program has a chance to have both the run and full tank lights on. This might not be a bad thing, but if the full tank light is on and the system is in idle we have a pretty big issue. That means that the automation didn’t completely work and the tank didn’t completely empty which is something that needs to be looked at. I just changed the light outputs if I really want to do this it would have taken a much different path. Each pump would be normally closed within the other pumps rungs to make sure that two pumps weren’t running at the same time. The group didn’t think that this was a big deal and that there could never be this error or take them as concern. I just felt like since the program require the system to drain or fill in a certain order that if something didn’t happen the outputs shouldn’t be energized for that particular part of the program.

Results:

We were able to get a working program that met each and every requirement that the program asked for. We had a lot of different revisions and a lot of discussions on how to really make this program work. Below are all the screen shots and pictures that I took to show and explain the project. I put the main picture of the program up along with all the other pictures that I have taken. Although thinking about it I guess you really only need the main picture.

In week two is really when our group decided to go with this layout for the program. It seemed to be the easiest and the most legible for other programs to understand. We were able to decide on a lot of things, but not all. I was able to make some key changes to the starting control system that wasn’t working quite properly. That was my main task while working in the group. Everyone else had their own little tasks that needed to be completed in order for the group to get this programing working properly.

Everyone did pitch in and help put their own advice and knowledge of the task at hand. We did have a good group of knowledge students that knew exactly what to do and how to make the automated process work. We did agree on a lot. Some things didn’t work out as well and It was more of a confrontation that a discussion. The pilot lights were really something that one student didn’t think was necessary at all. I felt it best at that time to become more passive within the group and do my own work.

Conclusions:

This was a very good experience working in a group and trying to bring together a project that more than one person is working on at a time. It opens up to allow some of us to trouble shoot why part of the system isn’t working while the others work on the more finer details. It was an experience I will remember and I learned valuable lessons and techniques that I will bring to my next job. I enjoyed learning and working in a group that had many different ideas and talents. It was interesting and something that I will take with me. With this lab like the last lab that we did in unit 5 the requirements and assignments weren’t quite clear. It left a lot of room for question and gave the chance for error. With these assignments it all depends on the person reading them and what they think the system should be doing at the time. It is no one’s fault for thinking differently or the way they do.

With this lab I did change around the count times for the indication of flow count to make it easier on me to not have to open and close the flow sensor 100 times to simulate the gallons going into the tank. With our group I believe we all generally came up with the same code in the beginning of the first unit and then modified it into what it is today.

This was my favorite lab that we completed in this class because it was the one that I didn’t want to do the most. It wasn’t the fact of doing the lab it was the fact of working with a group and trying to get everything together and everyone communicating and agreeing on the same stuff. Like I mentioned before each student has their own background and their own training. We are all great engineers and will continue to grow and develop.

References:

Petruzella, F. (2011) Logixpro PLC lab mamual for use with programmable logic controllers ( fourth ed). New York, NY: McGraw-Hill

Petruzella, F. D. (2011). LogixPro PLC lab manual for use with programmable logic controllers. New York, NY: McGraw-Hill.

LogixPro (Version TLP) [Computer software]. (n.d.).