STUDENT QUESTIONS, please post them here!

PLC Installation Assignment

G'day. I am currently studying syswin and OMRON CPM PLC's and have been told to prepare an installation procedure and report for the following specifications. Firstly, I am in no way asking people to do it for me. I am just unsure of a few aspects and have some questions below

-----------------------------------------------------------------
Specifications
-----------------------------------------------------------------
Water level in a tank located indoors at a soft drink bottling plant is to be maintained between two preset points as determined by two float switches. Water is pumped into the tank and gravitates out. The pump is to be turned off when water reaches the top switch and is to be failsafe.

Two extra float switches are to be provided for a High and Low alarm.

A flow switch is to be provided after the pump for monitoring flow/no flow condition.

The pump will have a stop and start pushbutton.
Control Isolating and Emergency Stop switches using an MCR are to be used.

The PLC is to be monitored in a small enclosure, within 10m of the tank.

An OMRON CPM PLC is to be used to monitor the tank levels and alarms and monitor and control the pump.

The area is subject to jets of water and an ambient temperature range of 0 to 40 degrees C.

-----------------------------------------------------------------

I have decided to use normally closed switches for failsafe operation and chosen an IP rating that coincides with the environmental conditions. I would like to have help with choosing an appropriate PLC size and specs, and how to go about doing the following diagrams:

-Process flow diagram of the installation
-Wiring diagrams of the 240V power supply to the PLC and pump
-Wiring diagramsof the inputs from the sensors
to the PLC including 24V DC, and outputs from the PLC to the motor and any other outputs
-Emergency shutdown Isolating and stop/start wiring diagram

Once again, I am not expecting people to write there answer in pages covering everything i have listed. Any contribution at all is greatly appreciated. Many Thanks

TW, You better have a bunch of fuses available. You've got the line power connected to nuetral through a n.c. contact?

jstolaruk said...
"TW, You better have a bunch of fuses available. You've got the line power connected to nuetral through a n.c. contact?"

L ---------- RED ---------- Aux-2 n.c. ------ N

RED is the Red Light... there is no "short" anywhere...

Terry Woods said:

jstolaruk said...
"TW, You better have a bunch of fuses available. You've got the line power connected to nuetral through a n.c. contact?"

L ---------- RED ---------- Aux-2 n.c. ------ N

RED is the Red Light... there is no "short" anywhere...

Click to expand...

Thanks for the clarification. I was thinking of something else (wire color DUH).

...750...

This is a pretty good approach. The thing I like most is that it says nothing about writing a program.

When I was studying "Statics" in college, the instructor spent the first week showing us nothing more than "How to Define a Problem".

Initial efforts should only involve gathering together what is known and what is desired. Notice, that does not include anything about figuring out how to get from here (known) to there (desired).

That approach is really great for getting, and keeping, all of your platypae, or kiwis, in a row. And is also great for indicating "holes" in the row.

You want to know... "...how to go about doing the following diagrams:"

-Process flow diagram of the installation
-Wiring diagrams of the 240V power supply to the PLC and pump
-Wiring diagramsof the inputs from the sensors
to the PLC including 24V DC, and outputs from the PLC to the motor and any other outputs
-Emergency shutdown Isolating and stop/start wiring diagram


First let me say, with respect to the wiring diagrams... all I can suggest is that you look in the PLC manual for examples of how to draw these... I can't think of a way to "tell you" how to do these without actually showing you how... and thankfully, you said... "I am in no way asking people to do it for me."

Now, regarding the Process Flow Diagram...
(Note: There might be some question as to what this really is...)

There is a big assumption hidden in this... the assumption is that you "know" the specs of everything that needs to exist in the system. This assumption would be wrong. You need to recognize that you have been "given" many of the particulars in this system. You also need to recognize that if you work some place and are called to design a system you will probably NOT be "given" any of the particulars... maybe.

That means, out in the real-world, you have to develop your own set of particulars.

What I mean is that you can't really specify the elements in the final process drawing until you really know what elements you need and how they need to function. All you can do at this point is provide a general indication of what the process drawing might be.

The first step is to simply draw a picture of the system indicating all of your known information (really known! NO GUESSES).

BTW, just as a procedural matter, that means it is too early for you to make a call on switch types (n.o. vs. n.c.). You will first have to determine how these particular switches operate in the particular environment.

For example, your level switches... highest to lowest...
- The level is "Too High"
- The level is "High"
- The level is "Low"
- The level is "Too Low"

Don't bother assigning any subsequent activity to any of these switches... not yet. For example, you might already anticipate that detecting a "Low" condition (how ever that condition might be indicated) will cause the pump to turn on...

While that might be true (to a certain extent), I can assure you that there are other issues to consider and that this is neither the time (this time in your development) nor the place (this particular drawing) to make such assumptions.

This is a very small system... however, even in this small system there is a certain degree of modularity. For example, there is...
- the MANUAL ON/OFF portion of the system
...this simply determines and controls whether the system is ON or OFF

then there is...
- the STATUS portion of the system
...this determines and indicates any alarm conditions
...this determines if the pump is "allowed" to run

then there is...
- the AUTOMATIC portion of the system
...this determines how and when the pump is "called" to run

Each of these "modules" can be easily, and completely, described in a very small K-Map. Remember, K-Maps are NOT necessarily "static" (like simple truth-tables)... they can be "dynamic" as well.

As you go through the effort of developing these K-Maps you will become more aware of how each module needs to work and what particular elements are necessary to make it work. This is the point where you determine just what kind of contact is needed to provide a "fail-safe" condition.

Note on "Fail-Safe":
Consider a limit switch that is mounted on a frame. The limit switch indicates that a particular device is in such-n-such position... or not. Now, what if the limit switch happens to fall off of the mounting bracket? If the switch is wired normally closed then the switch will never open... is that really "fail-safe"? Are there any other aspects that need to be considered to provide a truely "fail-safe" condition? Just something to consider.

Whether you use K-Maps or some other method, it is only after going through this "modularizing" effort that you can develop a complete understanding of how the process will work and thus the particulars of the Process Diagram.

Many experienced programmers can do much of this stuff in their heads... many do. However, some don't recognize these basic steps in development... some of them end up getting confused... developing spaghetti-code... hacking their way through code until they "happen to" come up with just the right kind of hack.

In general, hacking consists of grappling with two, three, four or more "wrongs" to make a "right". That's a really bad way to go.

While the normal operation of any particular process proceeds from "cause" to "effect", good design efforts proceed backwards from "effect" to "cause". And bear in mind, sometimes a particular "effect" might be produced by one of several "causes".

XXX

Terry is right but maybe a little complicated

I am a student too, so let me try to keep it simple.

OK you have the specifications for your system ie
1. what it is to do
2. also what equipment you need to get it done.

Start with simple sequence ie
1. Tank empty
2. Lower float switch starts pump (dont worry about NS or NC just yet)
3. Pump starts
4. Flow meter sends signal
5. upper float switch stops pump
6. PUMP DOES not stop
7. Top float switch sets off alarm

Now draw a block diagram and set the above phrases in it in sequential order.

Once you have the process well defined for yourself you can start on drawings.
Draw a basic motor starter THEN add the float switches you need to make the pump do what you want.

Dan Bentler

NOTE: The following is far from a complete solution... it is complete only to the extent that I make my point (I hope).

Dan,
Your explanation shows exactly the kind of development practice that I am arguing against.

"While the normal operation of any particular process proceeds from "cause" to "effect", good design efforts proceed backwards from "effect" to "cause".

Your explanation tries to develop the process from "condition" to "effect". (Notice that I said "condition", not "cause".)

You are failing to realize what you are doing in your own mind. You are not bringing to the conscious level those things that you are doing at the sub-conscious level. You are doing a heck of a lot more thinking on the sub-conscious level than your explanation seems to indicate.

For example, in your Step-2, you say, "Lower float switch starts pump"

This is a description of the process as it normally occurs. That is, while standing at the tank, if you see the Lower Float Switch drop low enough you can expect to hear the pump come on. I don't dispute this... it will occur in that manner. However, is it simply the action of the Lower Float Switch that causes the pump to come on?

That better not be so!

The TRUE "cause" for starting the pump should be "Tank is Low". (This is not to be confused with the input signal "Level is Low")
Once the pump is running, the TRUE "cause" for stopping the pump should be "Tank is Full". (This is not to be confused with the input signal "Level is High")

      Tank          Tank       OK to      Run

     is Low        is Full    Run Pump    Pump

  ----| |-------+----|/|--------| |------(     )

                |

      Run       |

      Pump      |

  ----| |-------+

If "Tank is Low" and NOT "Tank is Full" and "OK to Run Pump" (asserted by other conditions) then run the Pump and latch that signal until the "Tank is Full" or "OK to Run Pump" goes OFF.

Now, how are these "causes" determined?

I'll arbitrarily assume that the lower float switches are Normally Closed and the upper float switches are Normally Opened. (this is the Positive Logic form in terms of the named conditions)

This means, while the tank is empty...
- the lower inputs are ON
- the upper inputs are OFF

This means, while the tank is too full...
- the lower inputs are OFF
- the upper inputs are ON.

First stab at the "causes"...

     Level          Level    Level is     Tank

    is High        is Low    Too Low     is Full

  ----| |-------+----|/|--------|/|------(     )

      X3        |    X2         X1

   Level is     |

   Too High     |

  ----| |-------+

      X4





     Level          Level    Level is     Tank

     is Low        is High   Too High    is Low

  ----| |-------+----|/|--------|/|------(     )

       X2       |    X3          X4

   Level is     |

   Too Low      |

  ----| |-------+

      X1

 

Now, the "Tank is Full" rung presents a bit of a potential problem...
(I'm bringing my sub-counscious thoughts to the surface)

If it happens to occur that either of the lower switches fails to open when the level exceeds both of them then the "Tank is Full" signal will never go ON... the tank will overflow. So, that rung needs to be rethunk a bit...

Second stab on the "Tank is Full" signal...

     Level                                Tank

    is High                              is Full

  ----|/|-------+------------------------(     )

      X3        |                   

   Level is     |

   Too High     |

  ----|/|-------+

      X4

Now there are two chances to stop the pump. Under normal conditions the "Level is High" signal will "cause" the "Tank is Full" signal to go ON. However, if that switch fails then the "Level is Too High" is the last chance. If it gets to this point, something is wrong and there should be an alarm as well as stopping the pump. Of course, if both switches fail... ya got a mess to contend with. You can use only so much redundancy before the cost becomes prohibitive.

Now with respect to the "Tank is Low" signal...
In this case, before indicating that the "Tank is Low" one wants to be sure that there is no high-level signal... if there is, then something is wrong... if so, then that is for another piece of code to determine and indicate.

Now, if it happens to be that the "Level is Low" switch is stuck ON... then the pump will cycle everytime the level drops below "Level is High". The tank will stay full but this could be pretty hard on the pump.

If we were standing at the tank and saw this happening we would realize it right away. Can the PLC be made to realize this situation? Of course it can. While the pump is ON, when the "Level is High" signal comes ON the program should "look" at the status of the two lower switches. If either one is ON then there is a failed condition in the particular switch. This too can be "alarmed".

Likewise when the program "sees" the "Level is Low" signal come ON. If either of the upper signals is ON at that point then there is a failed condition in the particular switch.

So... the prelimanary code (far from final and without the fault detectors) looks like...

     Level                                Tank

    is High                              is Full

  ----|/|-------+------------------------(     )

      X3        |                   

   Level is     |

   Too High     |

  ----|/|-------+

      X4



     Level          Level    Level is     Tank

     is Low        is High   Too High    is Low

  ----| |-------+----|/|--------|/|------(     )

       X2       |    X3          X4

   Level is     |

   Too Low      |

  ----| |-------+

      X1



      Tank          Tank       OK to      Run

     is Low        is Full    Run Pump    Pump

  ----| |-------+----|/|--------| |------(     )

                |

      Run       |

      Pump      |

  ----| |-------+

Yes, of course, you could combine all of the code into a single rung or two... but then you would lose the clarity of "cause".

The point is to get away from driving outputs with particular "conditions" and instead use defined "causes". The "causes", of course, are ultimately defined by conditions... however, this approach recognizes that "causes" should not be driven simply by any particular "condition" but rather, by the activities leading to those "conditions".

Thinking from "cause" to "effect" is like exploring and finding yourself in a box-canyon... you have to back-up and try again... or try to hack your way out of that canyon by climbing the walls.

It's a subtle but very real, and very important distinction. In Process Control, especially in more complicated systems, it's not so much how the conditions "are", but rather, how the conditions came "to be".

I would leave the limit switches as you originally had it:

  Level            Tank

           Is Full         Is Full

           --| |-----+-------( )-

                     |

           Level Is  |

           Too Full  |

           --| |-----+

And place the fault (exception) logic seperately

Run Pump  Level Is Full  Level Is Too Full         Switch Fault

    -| |--------|/|-------------|/|------------|timer|-----( )--

           

"Switch fault" would then be conditioned in with "Ok To Run Pump"

The person that will be required to maintain your system after its installed will find the logic easier to follow. Its your responsibility as a designer to insure that it can be easily maintained even if it takes a few more rungs to make it readable.

jstolaruk...

There are only about a million different ways to do this.
You said...
I would leave the limit switches as you originally had it:

           Level            Tank

           Is Full         Is Full

           --| |-----+-------( )-

                     |

           Level Is  |

           Too Full  |

           --| |-----+

I didn't have any rung that looked like this (even taking into account your name changes).

My original rung looked like this...

     Level          Level    Level is     Tank

    is High        is Low    Too Low     is Full

  ----| |-------+----|/|--------|/|------(     )

      X3        |    X2         X1

   Level is     |

   Too High     |

  ----| |-------+

      X4

I then changed it to look like this...

     Level                                Tank

    is High                              is Full

  ----|/|-------+------------------------(     )

      X3        |                   

   Level is     |

   Too High     |

  ----|/|-------+

      X4

The reason that I excluded the low indicators is because, once the pump is running, the status of the low indicators doesn't matter. All that really matter at that point is the status of the high indicators.

I also indicated that the choice of normally open vs. normally closed was arbitrary. However, there is a certain degree of "method to this madness" where I declared that the upper switches are normally closed...

While the level is actually less than high then the "Level is High" signal and the "Level is Too High" signal should be ON.

When the tank level reaches the point where the "Level is Low" signal comes ON, then, before turning the pump on, the program should verify that the two upper signals are present. If either signal is missing then something is wrong. This could represent a failure in the "Level is Low" switch (a "short to hot" - assuming sinking inputs, or a "short to ground" - assuming sourcing inputs) or a failure in the upper switches (broken wire). In this case, an alarm should be displayed and/or sounded. Whether, or not, the pump should run anyway is a decision that should be made carefully.

Now, once the "Level is Low" signal is seen to come ON, IF neither of the high level signals are OFF, then there is a very high probability that the operation of the "Level is Low" signal is valid. This should be noted, in an additional piece of code, that the "Low Level Switch is OK". If, at any time, the "Level is Too Low" signal comes ON while the "Level is Low" signal is OFF, then the operation of the "Level is Low" switch can not be trusted! That too should be noted in a piece of code the invalidates the status of the "Level is Low" signal. In this case, the system can be directed to accept the "Too High" or "Too Low" signals as normal and valid controls... however, the exception must be indicated somehow.

As long as sensors continue to act as expected, and when expected, then their operation is to be considered valid... until such circumstances occur which negates that validity. At that point, something has to occur to indicate that the PLC has "seen" something unusual.

This is a really important concept to internalize... in process controls, to a large extent, we are dealing with "probabilities". We like to think that we are working with "Positive Indications" (that is, believing that sensors don't lie - that sensors always tell the truth), but the truth is we are hoping that the sensors are not lying to us (the PLC).

Enough... too much MGD.

Terry,

You bring up an excellent point about how to think about the process. Since taking the Logic Design course last semester, it is glaring to me now all the mistakes I was making in writing my programs. I am now using K-maps and what a difference! I am better able to understand what is happening instead of intuitively figuring it out. I will readily admit that there are times when I "hacked" my way to getting the code written. I am looking forward to the Advanced Logic Design class in the Fall.

Bob

Try explaining all that to an electrician that wants to get back to reading his paper. The last thing he wants to do is think about figuring out what some guy thought was cool and fancy. He wants the line running before the superviser comes over and asks "why is the line not running?".

You're right, too much MGD. But for good reason, two Big Ten teams in the Final Four!

Try explaining all that to an electrician that wants to get back to reading his paper. The last thing he wants to do is think about figuring out what some guy thought was cool and fancy. He wants the line running before the superviser comes over and asks "why is the line not running?".

Click to expand...

I argued this for years, they dont care. Its treated like engineering is meant for engineers only

Bob,

GOOD FOR YOU!!! EXCELLENT!!!

You have opened a door that will let you get much better at this game now!

Can I count you as one of those that see where I'm coming from and going to?

When I looked at Terry's code for first time I was a little puzzled as to why the high level switches were tied into the low level. After he explained it I can see the logic and wisdom in the design.

Yeah it is a little more complicated and it might just confuse the electrician who is more interested in his newspaper. Speaking as an electrician
1. What is he doing reading a news paper on the complany clock?
2. If he does not want to advance his ability then maybe he better stay with the newspaper or better yet the TV.
3. He seems lazy and determined to stay ignorant and incompetent.
4. I would keep him on - but for changing lite bulbs maybe.

Dan Bentler