truth tables...do you use them?

Hey guys, I'm working on a pretty simple project (yes I'm a rookie), and I used some knowledge from my digital logic class to help me design my ladder logic, but I'm wondering if this made things more complicated.

I need to fill four chemical tanks, there is one pump that pumps the chemical to each tank at the same time. In line motorized valves allow the plc to divert the chemical to each tank. So in short I have 4 inputs, to indicate if the tank has reached a high level (T#). And 4 outputs to control the motorized valves (V#).

These tanks are just for storage, the intent is to fill tank 1, then tank 2, then tank, 3, then 4, back to tank 1. The tanks are emptied manually in no particular order.

So I made a truth table:

Tank ____Valve
4 3 2 1 | 4 3 2 1
-------------------
0 0 0 0 | 0 0 0 1
0 0 0 1 | 0 0 1 0
0 0 1 0 | 0 1 0 0
0 0 1 1 | 0 1 0 0
0 1 0 0 | 1 0 0 0
0 1 0 1 | 1 0 0 0
0 1 1 0 | 1 0 0 0
0 1 1 1 | 1 0 0 0
1 0 0 0 | 0 0 0 1
1 0 0 1 | 0 0 1 0
1 0 1 0 | 0 1 0 0
1 0 1 1 | 0 1 0 0
1 1 0 0 | 0 0 0 1
1 1 0 1 | 0 0 1 0
1 1 1 0 | 0 0 0 1
1 1 1 1 | 0 0 0 0

This table accounts for every state the tanks could be in as a result of not knowing what tank will get emptied.

From here I reduced my logic (yay karnaugh maps!) to:

T4T2'T1' + T3'T2'T1' + T4T3T1' = V1

T3'T2'T1 + T4T2'T1 = V2

T3'T2 = V3

T4'F3 = V4

Then I used corresponding contacts to trigger my coils in my ladder logic. I know this will do what I need it to, but I can't
help but think there is a simpiler way. I could probably use a sequencer, but at the same time using just contacts and coils
may make it easier for the next person to understand it.

I wonder if I could simplify my contacts even more (because this tank sequence seems like it should be simpler), but I can't picture in my mind what I really need, and what I possibly don't. Using the truth table allows me to picture in my mind what is going on, and what needs to be done.

So, to sum it up, how does everyone go about designing new logic? Where do you start? Using the truth table in my example, I'm very confident that I could
download it, and the system will work as intended. I know if I just sat, stared at my screen, programmed what I *think* is the correct
logic, that I would be debugging the system for a few hours until I was confident it was doing what I wanted. Hope I made some sense.

Just looking for some insight into your minds, how you all start to design/program your logic.

the approach that I used in the program from this post might be interesting ... notice that the layout follows along with the 7-step sequence specified in the text ... the rung comments should help keep you oriented as to what's going on ... I've attached a .PDF copy below in case you don't have a copy of RSLinx500 handy ...

For something with the number of states as what you describe, I usually use a truth table. Its fast, easy, and mistake-resistant. When I get the most reduced functional relationships, I can often factor out more common terms for the simplest ladder logic implementation. I've never had something so complicated that I need a Karnaugh Map.

I'd use a sequencer with 8 or more functions.



$

I often use a truth table just like you've posted at the beginning of a project when I have a lot of inputs into one section of a machine. It helps organize the layout of the logic also.

Personally, I haven't found any value in sequencers and fancy shortcuts. The logic may look like its not fully minimzed/reduced but thats intended for maintenance personnel to get a better understanding of the program and minimizing phone calls (to me!).

Truth tables are a useful tool and I am an advocate of them. They can help you develop sound logic. However care should be exercised as it can be taken too far.



When I was a newbie PLC programmer on my first couple of projects I took the time to create truth tables, k-map the entire project, and apply every Boolean reduction tool I had been taught in school. The result was efficient well developed programs – programs that to this day I am proud of, except for one thing – when I had to go back to one of those projects a couple of years later. I found that the program lacked clarity and the over use of k-maps in developing the logic had obfuscated some of the functions. Since I no longer had my handwritten notes I found myself reverse engineering the program to refresh my own memory – despite the fact that the program was documented (who embeds the k-maps in the rung comments?) It was then that I asked myself why I was doing that - the PLC has a fixed memory, I’m not using it all, and the impact on scan time is negligible – so I was wasting time as well as making life difficult for whoever needed to read the program in the future.



Now I often embed extra information on the rung (which may be redundant) if I think it provides extra information to whoever may be troubleshooting. A few middle of the night phone calls is all it takes to change the way you view program efficiency.

Alaric, it sounds like you are downplaying the most holy k-map. Terry Woods will have your hide for that!!

I think Terry can learn fom this guy.

Good show. That looks good to me.

kamenges said:

Alaric, it sounds like you are downplaying the most holy k-map. Terry Woods will have your hide for that!!

Click to expand...

Yea, I realize there is some occupational hazard in saying that.
K-maps and boolean algebra have their place but not at the expense of clairity or when their use consumes time. With modern processors and memory its not necessary. At rare times tables and k-maps can really be a help with difficult logic - when to use them and when not to is something that I think becomes somewhat intuitive with experience.

However in no case should good top down design principles be abandoned. A good solution begins with a good understanding of the problem.

I don't understand the original specification coupled with the truth table.

From truth table:
All tanks are full, no valves
Tank 1 becomes not full so valve 1 comes on
Tank 3 becomes not full as well now valve 1 is off and valve is 3 on

So, tank 1 started to fill but it was stopped by tank 3 becoming not full.

(NB: truth table defines combination logic, what use would a sequencer would be ?)

Can more than 1 valve be turned on at a time ?

SimonGoldsworthy said:

I don't understand the original specification coupled with the truth table.

From truth table:
All tanks are full, no valves
Tank 1 becomes not full so valve 1 comes on
Tank 3 becomes not full as well now valve 1 is off and valve is 3 on

So, tank 1 started to fill but it was stopped by tank 3 becoming not full.

(NB: truth table defines combination logic, what use would a sequencer would be ?)

Can more than 1 valve be turned on at a time ?

Click to expand...

All tanks are full, no valves
When all the tanks are full, this is an alarm situation, the valves close and the pump that is pumping the chemical will get shut off.

Tank 1 becomes not full so valve 1 comes on
This is not always the case, just because Tank 1 gets emptied, I do not want tank one to fill back up again. I want tanks 2,3,4 to get filled before I come back to tank one.

Tank 3 becomes not full as well now valve 1 is off and valve is 3 on
Not sure which state your looking at.

Basically when the tanks are emptied, Tank 1 gets filled first. Once tank 1 is filled, I then start to fill tank 2. Now, during the filling process of tank 2,if tank 1 gets emptied, or if it stays full, I still want to fill tank 3 next. During the filling process of tank 3, if tank 1 or 2 gets emptied...I don't care, take 4 is next in line. It is basically a sequence, I could probably do something with a sequencer or a bit shift as well. I'm sure there are many ways to do this.

Right now the system is spec'd to only fill one tank at a time, therefore only one valve will be on and any given time.

Alaric said:

Yea, I realize there is some occupational hazard in saying that.
K-maps and boolean algebra have their place but not at the expense of clairity or when their use consumes time. With modern processors and memory its not necessary. At rare times tables and k-maps can really be a help with difficult logic - when to use them and when not to is something that I think becomes somewhat intuitive with experience.

However in no case should good top down design principles be abandoned. A good solution begins with a good understanding of the problem.

Click to expand...

So in my example, you would put rungs with all 16 states as they are directly into your logic? (Of course grouping the states that have the same output together)

My scenario highlighted below:

Tank ____Valve
4 3 2 1 | 4 3 2 1
-------------------
0 0 0 0 | 0 0 0 1
0 0 0 1 | 0 0 1 0
0 0 1 0 | 0 1 0 0
0 0 1 1 | 0 1 0 0
0 1 0 0 | 1 0 0 0
0 1 0 1 | 1 0 0 0
0 1 1 0 | 1 0 0 0
0 1 1 1 | 1 0 0 0
1 0 0 0 | 0 0 0 1
1 0 0 1 | 0 0 1 0
1 0 1 0 | 0 1 0 0
1 0 1 1 | 0 1 0 0
1 1 0 0 | 0 0 0 1
1 1 0 1 | 0 0 1 0
1 1 1 0 | 0 0 0 1
1 1 1 1 | 0 0 0 0


If this a truth table stating which valves operate according to the tank states, then I can't see what use it will have in helping you to implement the sequence you describe. You need a sequential function chart or similar.

Thats where my "sequence" in my truth table really isn't a sequence. Because I have no control over which tank gets emptied first, I used the truth table to identify every possible state the tanks could be in. From there I made a "sequence" of when the tanks would turn on based on the state they "could" be in.

In the instance you pointed out, I looked at it as being the state when tank 4 was full, tank 1 WAS full (then got emptied) and tank 2 was full, thus leaving tank 3 to be the next tank in line to get filled. So tank 3 was filling, while tank 1 was being emptied. Hard to see since a tank isn't exactlly full at 1 or empty at 0, which means I should look at my other states closer for similar situations.

A GE 90-30 is the PLC that is controlling this system. Using Proficy 5.5 to program it. I'll look into the sequential function chart to see if thats a way to go. Plus it's another chance to learn.

As ou've presented it, there is nothing that forces the valves to operate sequentially. The state of the valves is determined solely by the state of four switches.

Take a simple case: T1, T2, and T3 are all TRUE. T4 is FALSE.

Of your four Boolean expressions, only the fourth evaluates as TRUE, therefore V4 will be TRUE.

Now, if Tank 3 drains to the point where T3 becomes FALSE (T3 remains FALSE), V4 will go FALSE and V3 will become TRUE, stopping the filling of T4 and going back to filling T3.

Peter...

No one is going to learn ANYTHING from this guy, especially in terms of how he is proceeding. If YOU think that I, or anyone else, can learn from this guy... then maybe YOU should pay attention... and learn something.

I can clearly see that Paully has declared specific responses for particular conditions.

HOWEVER... those responses are NOT consistent in terms of current conditions, and are, in fact, erratic in others! This "solution" is NOT a rational approach, as clearly indicated by the K-Map (as if you really took the time to do a K-Map).

At the very least, as per his subsequent disclosures, Paully needs to monitor the fact that a particular Tank is being drained! That means... he needs to KNOW either the current level of the particular Tank, or the state of the Drain Valve for that particular Tank.

Paully,

According to the scheme that you have described, you need to decide on a priority... AND, gather the info necessary to satisfy that priority. That means having analog inputs indicating Tank Levels for each tank so that you can detect that a Tank level is being lowered. At the very least, you need to have a sensor indicating the status of each Drain Valve!

If you insist on using this arbitrary priority scheme then... you are pretty much stuck with what you have... except, at the least, you should give another look to your code regarding Valve-1. As described in the K-Map... there are only TWO input combinations that matter, NOT three.