truth tables...do you use them?

[SimonGoldsworthy]

... I don't think filling and draining the tank at the same time will accomplish much!

This comment hits the nail on the head for me - from the original problem statement the tanks are emptied in no particular order (to me this means someone can manually empty any tank at any time) so there is bound to come a time when someone empties a tank that is being filled. Some more background information is required like why are the tanks emptied. Are they always emptied until there is nothing in them or can they be partially emptied, what decisions were made when they were manually filled to decide which tank to fill. I guess I saw the problem as one where the tanks were to be kept full utilising all the tanks evenly.

 

[Paullys50]

Ah, good point, I should have stated more of the process of the tanks, I got too hung up in the logic. The tanks are just a storage spot for waste chemical, until it can be moved on for processing. They serve no other useful purpose, so what order they get filled in really doesn't matter, neither does the emptying order. Fill order is really only wanted for organization.

I think I found another kink in my logic....

 

[SimonGoldsworthy]

So filling and emptying a tank at the same time will accomplish something.

 

[Paullys50]

So filling and emptying a tank at the same time will accomplish something.

It will probably accomplish me getting a phone call from an operator wondering why the tank isn't emptying even though the drain valve is open!

 

[Terry Woods]

So, Paully...

If I might recap...

You have four tanks...
You have control over the filling of the tanks, but not the draining.
You want to fill the tanks in sequence... regardless of the fill status of the other tanks.
You want to fill 1, 2, 3, 4 then... 1, 2, 3, 4... over and over.
You expect that 400 fill-cycles = 4 x 100 fill-cycles.
That is, you expect fill-cycles to be equally proportional across the four tanks.

And yet, at the same time, you have no control over which tank is being emptied and when that emptying might occur.

You simply want to ensure, somehow, that the filling process follows the same sequence, as much as possible.

This means, if you reach the point where ALL tanks are filled... and Tank-3 is the next tank on the sequence schedule... and then... the operators decide, arbitrarily, to empty Tank-2 (which is the one you just filled)... uhhh...???

Your "sequence-plan" has just gone out the window!

How about this...

Once you start filling the "current tank"... that "current tank" should continue being the "current-tank" until it is infact filled. Once that tank is filled, the program should then "LOOK" at the "fill-status" of the next tank in the scheduled sequence.

If the next tank in the schedule is NOT FULL, then that tank should be selected as the "current tank" until it is full!

On the other-hand, if the next tank in the schedule IS FULL, then the program should skip that tank and then "LOOK" at the "fill-status" of the following tank. If that following tank is NOT full, then that tank should be selected as the next "current tank" for filling. However, if that following tank IS FULL, then... skip that tank and move on to "LOOK" at the "fill-status" of the next tank.

Why should the program "skip" one tank and then go to the next?

This will happen because you have no control over WHEN ANY particular tank might get drained!

The scheme indicated above will indeed follow your "sequence-oriented" scheme. HOWEVER... it WILL NOT necessarily (at least, not very likely, not likely at all) fulfill your stated requirement of 400 fill-cycles meaning that each tank was filled 100 times!!!

This is because you have NO CONTROL over when any particular tank is drained! Draining is completely arbitrary!

If the idea of 400 fill-cycles = 4 x 100 fill-cycles is REALLY important, then you ABSOLUTELY MUST provide some sort of indication to the Operators as to which tank THEY SHOULD drain next! At the very least, you need to provide an indication for the Operators that will allow the drain-sequence to follow behind the fill'ED'-sequence.

This can be accomplished, easily and cheaply, by simply providing a GREEN/RED Indication at the various Drain Valves. Only ONE of the Drain-Valves should have a GREEN Indication.

HOWEVER... if it is the case that NONE of the tanks are currently full... hmmm... that could present a problem.

Is it the case that once a tank is being drained it continues to be drained until it is infact drained?

Or... is it possible that a tank might be only half-drained? How would you know?

If, when a tank is drained, it is ALWAYS drained until it is infact drained, then your job is somewhat easier. Once the particular "FILLED" signal goes OFF then you KNOW that the particular tank is being drained and will indeed be empty!

I gotta stop here... 'cause I'm trying to explore way too many parallel universes!

These "possible parallel universes" exist because... there are too many unanswered questions.

Paully, I've already raised a LOT of questions regardinging YOUR perception of how the process should really proceed.

So... Paully... have you got any answers to those questions (questions stated and implied)?

You REALLY, REALLY, need to CLEARLY state your operative-concerns - from the most important one down to the least important one, all of them, in order.

Paully... THE FOLLOWING IS REALLY, REALLY, IMPORTANT...

It is MUCH more important to determine the question than it is to determine the tool(s) to use to come up with an answer...

I really appreciate your attempt to use a K-Map (believe me, I do)... however, deciding to use a K-Map as an "answer" BEFORE you fully understand the question is... insufficient, to say the least.

Live long and prosper.

 

[FrancisL]

Nice description Terry



Paully, have you actually asked the process people these questions?



Now, going back to my resource handler. This has a further advantage as it de-couples the request logic from the implemention. Each tank can have it own request logic. The Resource handler stays the same or at least has the Which Tank Next logic separately from the tanks.



This is more object oriented if you wish. The request logic can be contained within each tank module and the Resource handler logic in the Supply module. So when you find out what the real request logic should be you should be able to modify just one or two generic objects (eg Function blocks) rather than 20 or so rungs of ladder.

 

[Clay B.]

So, Paully...

If I might recap...

You have four tanks...
You have control over the filling of the tanks, but not the draining.
You want to fill the tanks in sequence... regardless of the fill status of the other tanks.
You want to fill 1, 2, 3, 4 then... 1, 2, 3, 4... over and over.
You expect that 400 fill-cycles = 4 x 100 fill-cycles.
That is, you expect fill-cycles to be equally proportional across the four tanks.

And yet, at the same time, you have no control over which tank is being emptied and when that emptying might occur.

You simply want to ensure, somehow, that the filling process follows the same sequence, as much as possible.

This means, if you reach the point where ALL tanks are filled... and Tank-3 is the next tank on the sequence schedule... and then... the operators decide, arbitrarily, to empty Tank-2 (which is the one you just filled)... uhhh...???

Your "sequence-plan" has just gone out the window!

How about this...

Once you start filling the "current tank"... that "current tank" should continue being the "current-tank" until it is infact filled. Once that tank is filled, the program should then "LOOK" at the "fill-status" of the next tank in the scheduled sequence.

If the next tank in the schedule is NOT FULL, then that tank should be selected as the "current tank" until it is full!

On the other-hand, if the next tank in the schedule IS FULL, then the program should skip that tank and then "LOOK" at the "fill-status" of the following tank. If that following tank is NOT full, then that tank should be selected as the next "current tank" for filling. However, if that following tank IS FULL, then... skip that tank and move on to "LOOK" at the "fill-status" of the next tank.

Why should the program "skip" one tank and then go to the next?

This will happen because you have no control over WHEN ANY particular tank might get drained!

The scheme indicated above will indeed follow your "sequence-oriented" scheme. HOWEVER... it WILL NOT necessarily (at least, not very likely, not likely at all) fulfill your stated requirement of 400 fill-cycles meaning that each tank was filled 100 times!!!

This is because you have NO CONTROL over when any particular tank is drained! Draining is completely arbitrary!

If the idea of 400 fill-cycles = 4 x 100 fill-cycles is REALLY important, then you ABSOLUTELY MUST provide some sort of indication to the Operators as to which tank THEY SHOULD drain next! At the very least, you need to provide an indication for the Operators that will allow the drain-sequence to follow behind the fill'ED'-sequence.

This can be accomplished, easily and cheaply, by simply providing a GREEN/RED Indication at the various Drain Valves. Only ONE of the Drain-Valves should have a GREEN Indication.

HOWEVER... if it is the case that NONE of the tanks are currently full... hmmm... that could present a problem.

Is it the case that once a tank is being drained it continues to be drained until it is infact drained?

Or... is it possible that a tank might be only half-drained? How would you know?

If, when a tank is drained, it is ALWAYS drained until it is infact drained, then your job is somewhat easier. Once the particular "FILLED" signal goes OFF then you KNOW that the particular tank is being drained and will indeed be empty!

I gotta stop here... 'cause I'm trying to explore way too many parallel universes!

These "possible parallel universes" exist because... there are too many unanswered questions.

Paully, I've already raised a LOT of questions regardinging YOUR perception of how the process should really proceed.

So... Paully... have you got any answers to those questions (questions stated and implied)?

You REALLY, REALLY, need to CLEARLY state your operative-concerns - from the most important one down to the least important one, all of them, in order.

Paully... THE FOLLOWING IS REALLY, REALLY, IMPORTANT...

It is MUCH more important to determine the question than it is to determine the tool(s) to use to come up with an answer...

I really appreciate your attempt to use a K-Map (believe me, I do)... however, deciding to use a K-Map as an "answer" BEFORE you fully understand the question is... insufficient, to say the least.

Live long and prosper.

Wow! I would have taken the easy way out on this one.

Each valve operates when it is avaible and held the fill on that tank by putting in a comparitive statement so the first to start prevents the others from opening. If I needed to get cute and balance the fill I would do a count on each fill and start with the tank with the lowest fill. Heck at the end of the day your going to put the cr*p in whatever hole will take it.

 

[Terry Woods]

Paully...

I can REALLY, REALLY, appreciate that you are in the position of being the "new-guy" in terms of Process Control for a particular process.

But... I gotta say... this is the time to establish your credibility!

I have run into many, many, cases where the production people were trying to dictate my response to their particular concerns.

The problem is... the production folks are coming from a "production point of view"... NOT a "process point of view".

IF YOU ARE INDEED UP TO THE TASK... YOU are in the CAT-BIRD SEAT!

Assuming that you have no idea what "Cat-Bird Seat" means... it means that YOU have, at hand, the opportunity to ESTABLISH yourself as a REAL DEVELOPER!

When it comes to in-house people trying to develop their own credibility, you often have to disregard what they ask for and then go through the effort of trying to find out what they REALLY NEED! That is, NOT just what they say that they WANT... but rather, what YOU, as a real-player in the game, SEE that they REALLY NEED!

After all, aren't you really answerable, ultimately, to Corporate?

Oh... you can't get past your local supervisor to Corporate Level?

Well... All I can say is... work like hell to get the Production People ON YOUR SIDE!!!

Once you do that, you can then show the Production People what they didn't even think that they needed!

At that point... you don't have to justify your existence in the game... Production will do it for you! When that happens, I'd call your position pretty damned well established and, depending on the idiots making the calls, I'd say... pretty much... "Cat-Bird Seat" (That is a VERY, VERY, GOOD, INFACT, EXCELLENT THING FOR A PROGRAMMER/DEVELOPER).

If you want to solidify your position before someone, or something, bumps you out... Find out what your process needs BEFORE your Production People call for it... and provide that beforehand!

Then you can walk around saying... oh... you need this? Then simply do that!

Stay AHEAD of the expectations!

That is the ULTIMATE KEY to being a REAL Process Programmer!

 

[Terry Woods]

Clay...

You obviously didn't pay any attention at all to the constrainsts as they were presented.

Go back, read the constraints... and then see if your truely considered answer isn't somewhat like my own.

 

[panic mode]

... (edit, wrong tread)...

 

[Clay B.]

Clay...

You obviously didn't pay any attention at all to the constrainsts as they were presented.

Go back, read the constraints... and then see if your truely considered answer isn't somewhat like my own.

Read the constraints. I assume you mean what he had to accomplish. What I saw was 4 tanks filled with chemical that could be empitied in any order. Order tanks are empited are not real important but "production " asked for the tamks to be fill one at a time from first to last as they became avaible. Now I read this to mean that they generally like to empty the tanks from front to back. So for me that meant doing as asked, start with the first tank, fill it, then move to the next one. Since they could be empitied in any order then the actual sequence of who got filled first becomes mute. If they empty them in random order then filling them in random order is not really going to show up.As you said it is important to set your place and telling the "bean counter" you need extra componets that were never needed before to make the tank system perfect kinda makes you look like you might be just wanting to "Grand Stand" and show how much better you are than other people. If you think the emptying of the tanks may become an issue then make sure the PLC you quote for the job as enough extra I/O's. So if or when it does come up you lean back in your chair and say " Hey I spec'ed the I/O's for that just incase you wanted it so now you just need to add the sensors and churn out some code. Now that shows your a team player and your looking after the bottom line.



Thats my 2 cents worth anyway.

 

[Paullys50]

Terry -

Wow! Thank you so much for taking the time to give me advice, and present your thoughts in such a logical manner! I know that is an area I need to work on............................ taking a step back, re-thinking about what I'm going to present to make sure I have the clarity in my message.

Your interpritation of the tank filling process is correct. Without any additional sensors to monitor the tank levels, or drain status, my *ideal* 400 filling cycles = 100 cycles per tank; my not actually happen (dependant on the operator). As things stand right now, the next tank in the sequence will be skipped if it is still full. Tanks will contiune to be skipped until the next available tank in the sequence is in fact not full. This is how the logic is currently written, and this is how I will present the operation of these tanks at our next meeting. At that meeting I will explain the limitations of this system given the limited I/O I have, and explain that those limits can be overcome with additional I/O.

Before this meeting, I will be making a trip to visit the operators so I can learn how they are currently operating the tank's manual drain valves. I will use this information as ammo during the meeting, this will help me iron out the process differences between production, and management. Hopefully in the process I'll be able to figure out what they actually need! I should have walked through this door from the very beginning.....lesson learned!

Back to my original post, the fact that I have no control over the tank drain is what resulted in my erratic truth table, I tried to account for the random states the tanks could be in due to the operator; then I gave those states a resulting output that I thought would accomplish the desired tank sequence. I put the truth table together to organize my thoughts of what was going on, from there I fell into the world of k-maps...........when I was first given this task, it seemed pretty cut and dry....now I know that I need to take a step back, and understand the problem fully before I settle on a solution.

In my original post I wanted present my thinking, and to compare it to the years of experience on this board. I wanted to know if my approach was on par with memebers of the board. I value the resources here, and I hope that some day I'll be able to move from the "asking questions" portion of our program, to the "answer questions" portion of our program. Again, thanks to all for helping me see the larger picture, thanks for not getting too frustrated with me!





Terry, your words of wisdom in your follow up post were very familiar! Today was the last day for one of my co-workers. Last night we all went out, and for the first time I felt that they viewed me as an equal. Everyone was soon giving me advice, from what is going on currently in the company, down to how to be a successfull programmer. "Understanding the Process" was said over and over, they told me"

- Understand the Process

- Understand the people that can help you, and the ones who can't

- Understand that when a problem arises, and the finger is pointed at controls......be smart enough to realize that the "problem" could be just a "symptom" of the real problem somewhere else in the line. Knowing how to figure this out then relates back to Understanding the Process!



Gosh, it's 11:20pm on a friday night.....and I'm talking about work!! Ugh....I need to find some friends in this town! At least I know I can always count on Mr. Miller.

Sorry I didn't do a spell check. Its friday night!