Timer settings based on process speed

Terry,

In anothr thread you said:

The BEST advice that I can give to any programmer is to recognize that any process is more Event-Driven and Time-Driven, with a healthy "awareness of prior history", than it is Condition-Driven.

A Condition-Driven and Static-Timer-Driven control scheme will handle a lot of very simple processes... as long as they remain static and simple.

An Event-Driven and Dynamic-Timer-Driven control scheme (with historical references) will handle ALL processes... even if speed conditions change (within reason, of course).

The other major advantage to this scheme is that the program can detect when something unexpected happens, or it can ignore those conditions which it "knows" to be invalid.

A Dynamic-Timer is one where the Preset Value is calculated, at the appropriate time, and then loaded into the Timer before the Timer is activated. As speeds increase, timer preset values typically decrease. As speeds increase, one needs to watch for subsequent events sooner... Q.E.D.

(113)
This has set me to thinking. One could measure the events or the process speed. Then use that value to adjust the timers as process speeds up or slows down. Makes a lot of sense.

The part that I don't quite get is the referance to history. Are you referring to the programmers knowledge of the process and its operation history or are you actually dialing in a factor to account for history??

The reason for asking is I have finished studying timers and now know something about them (at least caution -- they are easier to turn on than to turn off). ALSO am starting to study Sequencer. Seems to me this is an excellant time to incorporate some real world thinking and experience in my studies.

Am thinking of using a traffic lite for the sequencer. The advantage is that it is a fairly easy task sequence to describe. Do you have a better project??
Ah yes the home washing machine ?? Not ready to get into analog yet (for temp control of wash water).

Lessee
1. Start
2. Open fill valves
3. Fill to hi level
3 A Soak (optional ??)
4. Agitate
5. Pump out
6. Spin
7. Refill
8. Agitate
9. Spin dry
10 Done

Thoughts ??

Dan Bentler

Don't forget the door limit switch. After machine is started, opening and closing the lid, should stop and start the machine.

After you've written your program, you can view another version at this Thread

Washing machine programming is a good learning experience, after you do the basic machine, you can add additional features as you learn them. Multiple wash sizes, multiple temperatures, perhaps even varible timing. And For the Super Duper Deluxe model , you can have an HMI where the entire "cycle" can be customized by the operator. Saw one of these at the local Home Supply Store, very hi-tech looking, and very very expensive.

OK

Hi Dan
Here`s some more food for thought. A lift station
2 - pumps the pumps alternate LEAD and LAG
4 - float switches
Bottom switch is STOP
Second switch up is START
Third switch up brings on both pumps if the level gets HI
Forth switch brings on a Hi Level Light
if Level is HI to long dial out for HELP
If a pump trips on O.L. automatically reset it once.
If it trips the second time dial for HELP
Similate flow while each pump is on
If the Lead pump is on and shows no flow
bring on Lag pump
If you have analog use it in the place of float switches
use floats as backup control
DATA:
How long has each pump run
How many gallons has each pump put out
Does one pump pump more than the other one
Pump trend chart
How many times has the level been Hi
Has either pump tripped on O.L.
Store your alarms in a fifo say 10 deep
Show your DATA in your PV
GOOD LUCK WITH YOUR STUDIES :!:

:site:

Greetings Dan,

Not ready to get into analog yet (for temp control of wash water).

Click to expand...

you don't need analog ... just do it the same way a household washer does ...

hot solenoid only = hot water ...
cold solenoid only = cold water ...
both solenoids = warm water ...

Hot + cold = warm

Ron,

Was planning to do the two solenoid valves. Stepped back from washer and used simpler projects to learn sequencers tonite. Cheated a little and used example from ROCKWELL PLC manual. Now that I know how it works the real education starts -- applying it to real world.
For instance on door switch I can have switch stop the sequencer OK but I am wondering how to get the timer to stop where it was when the door opened.

HMMM Allen Bradley Micrologix 1000 using RS LOgix 500 software.
Could I have door open switch to start a one shot
THEN
one shot starts "something" to record the timer accumulated time when it stopped
THEN when restart the data in "something" gets transferred back to Accumultate ??

I see another learning curve.
You can tell me what the "something" is but please dont tell me how to do it. Gotta figure it out on my own.

The real world application would be time sensitive process ie
"not too short not too long"
which would not be acceptible for timer to start over. Maybe autoclave ??

I think I am getting hooked this stuff is kinda fun.
Dan Bentler

Dan Bentler

but I am wondering how to get the timer to stop where it was when the door opened.

Click to expand...

Hint: Take a look at retentive timers (RTO).

but I am wondering how to get the timer to stop where it was when the door opened.

Click to expand...

don't use a timer.....

integer and 1 second pulse are easily stopped.

Random Fire
In previous post you said:
don't use a timer.....
integer and 1 second pulse are easily stopped.

Using AB Micorlogix 1000 w/ RS Logix 500 software.
Looked in AB manual. Saw nothing indicating how to do this.
Can it be done in this setup??
If so how??
Is this too advanced for me at this stage of lesrning??

OTHER SUGGESTIONS
RON Also looking over how to incoroporate Retentive timer
Ken Moore. Have not opened up your program either here or in Mr PLC. Will do when further experienced.

Thanks to all for help
Dan Bentler

I think RandomFire is saying use a 1 sec pulse to ADD 1 to a integer (N) file. If you need it "reset" then MOVE a zero into that integer (N) file. Its a roll your own rententive timer/counter.

RTO is a retentive timer that works with Micrologix. If you have RSL 500 open click Help then look at SLC Instruction Set. Take the time to just browse thru the instructions to see what is available and works with the ML.

Dan,

Sorry I'm late... I didn't catch this when you first posted it.

Back to your original question in this thread...

"The part that I don't quite get is the referance to history. Are you referring to the programmers knowledge of the process and its operation history or are you actually dialing in a factor to account for history??

First... I'm not referring to the kind of history that would normally be examined by means of Mr. Peabody's "Way-Back Machine".

I am referring to the history associated with the current conditions in any given, running, process.

The "history" aspect refers to "knowing how a particular set of conditions came to be".

Let's say that there are a set of sensors that track widgets through a process.

FIGURE-1:

                  PROX-A      PROX-B      PROX-C

PROX                ||          ||          ||

Stat

"000"  No Widget                                          



"100"     ////////////////// 



"110"            //////////////////



"010"                   //////////////////



"011"                          //////////////////



"001"                                 //////////////////



"101"     //////////////////                //////////////////

.
Now... DON'T BE FOOLED!!!
The figure above seems to indicate that the widgets move only from left to right. NOT SO! Depending on the particular circumstances, a widget might enter from either side and then leave by either side. That means, a widget could enter from either side, stop in the middle and then exit through the same side it entered. Get the picture?

Let's look at a K-Map for the three sensors.

                    PROX-C    

  PROX-A  PROX-B      OFF       ON

                  +---------+---------+

                  |         |         |

    OFF     OFF   |  "000"  |  "001"  |

                  |         |         |

                  +---------+---------+

                  |         |         |

    OFF     ON    |  "010"  |  "011"  |

                  |         |         |

                  +---------+---------+

                  |         | FAULT!  |

    ON      ON    |  "110"  |   NOT   |

                  |         | Allowed |

                  +---------+---------+

                  |         |         |

    ON      OFF   |  "100"  |  "101"  |

                  |         |         |

                  +---------+---------+

.
Rule #1:
Sensors change state one at a time. That is, two or more sensors can not change state at the same time.

Rule #2:
If all three sensors are ON then a fault condition exists.


Now, all of this is a complicated set-up to explain one simple point...
...and I'm not gonna say what that point is... yet.


Let's say that YOU are the Computer.
The state of the sensors is displayed on a wall. You can not see the process like a human sees the process. All you can see is the lights.

Now, one other constraint... as the computer, you have many things to do... so you can not be watching the sensor lights constantly. You are allowed to look at the lights only once every so often.

So, let's take a practice run...

1. Look at the lights.
2. Record their states on a piece of paper
3. Open your program listing and begin evaluating each rung...
...using only the data you have on your piece of paper
4. Manipulate your outputs according to the results.

Let's go back to Steps 1 & 2.

After looking at the lights it should be easy to recognize that the particular combination corresponds to one of the locations in the K-Map. That combination also corresponds to one of the cases in Figure-1.

Let's say that the particular combination was "010". That means that, at the instant you looked, a widget was sitting under Prox-B.

Now, here are the pointed questions...

Which way is the widget moving?

Better yet... Is the widget moving?


Now, according to the "rules", only one sensor can change state at a time... if any states change at all.

Since the current condition is "010" then the previous condition could have been one, and only one, of the following:

CASE#  PREV    CURRENT

  1    "010" => "010" (Might not be moving)

  2    "110" => "010" (Came to Center from the Left)

  3    "011" => "010" (Came to Center from the Right)

  4    "000" => "010" (hmmmm.....)

The last one is interesting...
It indicates that Prox-B came ON without moving the widget through Prox-A or Prox-C.

If the process was shutdown with widgets in the machine then the progrssion from "000" to "010" might occur if a widget is under Prox-B when the machine is turned ON.

Other than that particular situation, the progression from "000" to "010" is illegal, or at least, illogical.

Although illegal or illogical, other than the power-on situation, is this progression possible?

The answer is a resounding YES!

So... how?

All that is necessary is for one, or more, of the sensors to be faulty.

Prox-A or Prox-C could be "dead-open". Prox-B could be "dead-closed". If Prox-B is "dead-closed" then there might not be a widget at all... maybe.

The key point of the "history" issue is "knowing how the process progressed from one set of conditions to another". That is, "How did we come to be where we are?" This question applies to LIFE in general as well as PLC logic.

Cases 1, 2 & 3 are valid progressions.
Case 4 is not valid, or at least, not normal. It should "call" for attention.

Now, just because Cases 1, 2 & 3 are valid... does that mean that any one of them is the "correct" progression?

That depends on the "expected progression".

Knowing what the "expected progression" is depends on another layer of "history". You have to know the previous condition and the subsequent action that you have applied.

If the previous condition is "110" and you are telling the widget to move to the Right then you should "expect" to see "010" as the next progression. Depending on how long it takes to move the widget, you might see that the current condition is "110" for several condition checks. Once the widget is told to move, you'll probably want to run a timer. If the timer times out before the "expected" condition occurs then a fault of some kind has occurred... either the widget has stalled (hung-up?) or the widget went the wrong way. In either case, the timeout tells you that something is wrong. If the "expected" condition occurs before timeout then disable the timer and carry on with the next step in the process.

The program does NOT maintain a historical record of activity unless you create the means to do so!

You have to create the means for the program to know how it came to be where it is.

If you don't provide that means, then the program is nothing more than a switch handler... this means that if you go up to some particular sensor or switch and then activate it... the code associated with that input will simply react... just like Galvanni's Frog Leg or Pavlov's Dog.

The Frog Leg and Dog are NOT considered as intelligent systems... they are considered reactionary, or conditioned.
Neither one of those make for "intelligent" processing.

Without having a sense of process history, you only know what conditions are... not what they were. You don't know how we came to be here!

Have you ever found yourself wandering around in the kitchen wondering what you were looking for?
(When that happens to me I simply resort to grabbing an MGD from the frig.)

Or gone through the house looking for your glasses... and you had them on? ON YOUR FACE!

Or the pencil that was tucked behind your ear?

If you haven't suffered any of those conditions as of yet... you will.

"Intelligent Processing" is BASED IN HISTORY!

Now, do you understand what I meant?

(242)

Quite right rsdoran. I always think of it as a really tidy way to make a timer do whatever you want. Admittedly this comes from working with processors that do not have retentive timers, but still a very useful bit of code. Even useful if you are in need of a lot of timers and don't have many within the PLC.

Need timer 1 sec pulse
-------| |-------| |------------INC WORD

Using the above takes away the need for worrying about the values of a timer. If your timer condition goes to zero, the counting stops. Simple. You may need to add a OS to the code, some compares for when you reach your value you require and a reset to tailor it to your needs.

rf

THANK YOU

Terry,

With an explanation like that there is NO need to apologize for taking some time. Now I see what you mean by history factor. Your explanation makes a lot of sense, not sure I can explain it back to you yet - will need to study it make a model and see how to apply it.

Random Fire thanks. That makes sense also. Am getting out of simple switching mode into data handling mode so will have to study this one also and make a model of it.

MANY THANKS

Dan Bentler

Dan,

A lot of PLCs have a really limited number of timers. If a particular PLC has only 32 timers and your application calls for 33 timers... wha' cha gonna do?

By using a single pair of timers you can create a single, general purpose timer (comprised of two timers) that is available for any number of uses... concurrently!

CAUTION: You have to consider the particular resolution you might need for the particular use.

Let's say you have a process that is relatively insensitive to timing issues. That is, if your process only needs to have timers that are accurate within a couple of seconds, then you can do the following and have an almost unlimited number of one-second timers (the limit is the number of available V-Mem locations).

Use the pair of timers to create a pulse-train where the train is ON for one-half second and then OFF for one-half second.

       .5 sec

         ON

       +-----+     +-----+     +-----+

       |     |     |     |     |     |

   ----+     +-----+     +-----+     +----- ...

             .5 sec

               OFF

.
Timer-A = .5-sec. Timer-B = .5-sec.

Have Timer-A configured to always run.

Use the output from Timer-A to run Timer-B.

When Timer-A times-out, the output from Timer-A causes Timer-B to run.

When Timer-B times-out, reset both timers.

"Bet cha didn't know..."
Some PLCs call for the Timer Current Value to be reset to zero (count-up), others call for the timer to be reset to the preset value (count-down).

Some PLCs call for an explicit reset-bit to be turned ON (one-shot style) to reset the elapsed time value. While others call for an Enable-Bit to be turned OFF to reset the elapsed time value. In the latter case, the Enable-Bit has to be turned back ON before the Timer is allowed to run... however, the timer still won't run unless the "Run Timer-Bit" is turned ON.

There are as many different timer methods out there as there are PLC types. You simply need to know the ways and means of your particular type.

Anyway...
Once the timers are Reset, and since Timer-A is no longer timed-out, Timer-B stops running.

Now, at the particular module, you can have a "count-value" in a V-Mem word. This is typically a single-word Integer. It could, however, be a single-double-word... now yer talking LARGE numbers!

If your resolution is smaller than one-second then the total count available becomes smaller. However, you could "roll yer count" into an additional "cascaded-counter".

The act of incrementing a value is nothing more than "Vxxx + 1 = Vxxx". You must take care to reset the local "counters" as required.

You can increment your "counters" by "watching" one of a couple of conditions.

Whenever the "Reset Timers Bit" is turned ON (one-shot style), increment any and all associated "counters" in the particular modules.

BTW, in the case above, "one-shot style" means that the output bit from Timer-B will "act" like a "one-shot". You don't have to create a one-shot function because the bit WILL go OFF after the scan returns to Timer-B.

Meanwhile, since Timer-A is configured to run continuously, Timer-A begins timing.

Another way to increment your "counters" is to "watch" the state of the timers. In some PLCs there is a bit indicating that the timer is running, however, it is not timed out. There is another bit indicating that the timer is running and that it has timed out.

You could "watch" for the OFF-ON transition of the bit that indicates that the timer has timed out.

You could use that bit to increment the particular "counters".

Basically, all you need to do is "watch" for a particular change within the relative status of the two timers.

"Additional Bonus..."
If you need a "FLASHER" you could "watch" for the relative status of the timers.

While Timer-A is NOT timed-out then drive the Flasher Output ON.

It's all just a game... if you can "think it"... it can be done! (You might have to acquire additional hardware, but it can be done!)

REMEMBER... (assuming you have a half-decent PLC to begin with...)
YOU ARE THE MASTER OVER THE PLC... not the other way around.

ANOTHER THANK YOU

Terry

Sequenced timers - did tht once works great - little different application though -- BUT I get the concept.

Am using the schools equipment
Allen Bradley Micorlogix 1000 with RS Logix 500 software.

Soon (instructor says) will graduate to a SLC (not sure of model #).

I am doing this on independent basis - essentially I dream up the homework, design the program on paper, enter it, see how it works, fix mistakes and LEARN. The tough part is knowing enough to write up the homework task. Will be asking you guys for "tasks".

Currently am designing for washer (home style). Fairly simple with sequencer until I add real world
ie door open (AND not lose or gain any cycle time ie timer freezes when door opens then restarts when door shut.
Also am adding "forgot the soap" which will reset everything and start back at the start.
Also am dealing with the fill and pumpout cycles and associated float switches. The issue here is (I think) switching from a time driven sequencer to an event driven. I just learned these terms so am still working on this.

HINTS are OK but please DO NOT give me any full solutions. I won't be worth a darn unless I figure out my own problems.

Dan Bentler

In terms of "stopping the timers" when you open the door...

If you are using the "universal timer" configuration I described, then would it simply be a matter of...

     RESET       DOOR IS

     TIMERS      CLOSED         +-------------------+

  -----| |---------| |----------+ INC "Timer-Count" |

                                +-------------------+

The "Process Timer" increaments only when the "Reset Timers" Bit goes ON AND Only If the Door is Closed.

In TI, my timers are Retentive as long as my timers are enabled. Being "enabled" doesn't mean that the timer is timing... only that the timer is NOT in the Reset/Disabled condition.

     WASH    DOOR IS

     CYCLE   CLOSED

  ----| |------| |-----------(     ) Run Wash Timer      



     RESET    RUN WASH

     TIMERS    TIMER      +----------+

  -----| |------| |-------+   WASH   +-------(     ) Wash Cycle Done

                          |   TIMER  |

      ENABLE              |          |

       WASH               |   300.0  |

      TIMER               |          |

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

                          |          |

                          +----------+

What do you think?