Quickie Problem

[Prince]

Hello Just a question

I am not sure about the plc you are using but most of the plcs I know even the smallest one do support stacks.

As a novice just to be criticized by others I am suggesting to use an stack based sequence

as you might have some time ( I mean much more than a second ) to up count the counter after detecting a car in any of the gates I suggest to push a value in the stack after any detection interupt on each of 3 gates then when you had enough time and when all the signals went down you will have the time in the next phase to pop your upcount requests one by one and consider about them.

It would be more beutiful if you push a time value in the stack then in upcount phase you can easily detect and omit the unwanted detections.e.g.

if 3 cars enter the gates one by one, you will have
(I am writing in assembly which is the international language)

push 11h /*car entered fome the first gate*/
push 12h /*car entered from the second gate*/
push 21h /*car enterance completed in 1st gate*/
push 13h /*car entered from the 3rd gate*/
push 23h /*car enterance completed in 3rd gate*/
push 22h /*car enterance completed in 2nd gate*/

then when there is enough time ( which I think you would have )
the normal phase can read the stack and do the rest.

I think this can be evaluated to work in Random access memories too

 

[gluca]

Hello Prince, I don't understand your assembly example.
Could you translate it in ladder?

 

[Terry Woods]

So, you have three inputs (one vehicle detector at each booth) and you have a REAL counter at each booth AND there is a Master Counter.
(A total of 4 counters - is that correct?)

I don't get the part about "audit" - what's that?

Anyway... so far, I don't see anyone playing "Be the Computer".

This problem can be solved pretty easily and it doesn't matter if you have two or three cars coming in at exactly the same time!

"Be the Computer!"

 

[Prince]

The Ladder will make the idea a little MIXing , It is just the matter of my bad english I just meant that instead of direct counting by the sensors and mentioning the fact that they will be seconds with no car entering you can easily save the sensor information by interupts and then compile and consider about counting with the main program the picture show below is just for the perpose to test pasting pictures in my text but it repeats what I said :

 

[Allen Nelson]

Ron, Kevin & Gluca:

Your solution is good - having internal PLC counters mimic the physical ones, and having some additional logic to pulse the master one if the sum of the individuals is greater than the mimicked external master.

A couple of cautions:

1. At some point, when all the counters agree, the PLC counters need to be reset, lest they exceed the 32767 or 9999 or whatever barrier. This could be done once per day (at midnight, when the park gates are usually closed), or perhaps more often, depending on traffic.
2. The "Extra Credit" that I posted about debounceing the input still needs to be addressed.
3. The code that Gluca posted has a few flaws. I know that he said that he hadn't tested it, but I feel thay should be pointed out anyway:
   
   A) If a car comes in after T4:1 is done timing, B3/0 will latch, the pulse count will increment, but the output will not be enabled, and B3/0 will unlatch, all on the same scan. In effect, this code won't work as intended.
   
   B) N7:2 - Number of pulses left - is calculatd, but never used. Sloppy.
   
   C) A better solution would be to put a counter on the output (mimicking the physical counter) rather working off of internal logic.
   
   
   D) Remember that he's using a DL05 PLC, so be careful when posting "exotic" addresses like T4:1.TT - not every PLC has a Timer Timing bit.

<hr>

Terry:
There are at least 5 counters - at least one at each booth, and two masters - one resetable, one not. For reasons that escape me, they need different outputs, even though they get the same pulse at the same time and could be wired in parallel (assuming voltage drops, etc).

I've been playing "Be the Counter" with the timing diagrams and such. Once it's understood what the counter needs to 'see', you're right, it's not hard to program the PLC to produce such a signal. (I did it in about 15 minutes yesterday (including testing and fixing typos), using a variation on the code that I posted). I'm trying to teach, not just hand out code.

 

[gluca]

[No message]

 

[gluca]

Allen, you're right on all, but it I don't see why the ladder doesn't work:

if a car enters after the T4:1 is done timing, B3/0 will not latch, since T4:0/DN will be off, the pulse count will not increment, and the output will not be enabled, but it will be enabled the next T4:1 timing interval.
It was to avoid the two cars entering in a small time interval could cause the PLC to emit too close pulses.

I agree with you that surely there is a more elegant solution, but I've not the time to work on it. Anyway I'm curious to see further solutions.

 

[Allen Nelson]

Car enters (after T4:1). Count increments.
N7:0 > N7:1

Rung 7: T4:0.DN is not done (yet). B3/1 is not latched. N7:1 remains less than N7:0
Rung 8: B3/1 is not latched, no output
Rung 9: T4:1.TT is false, so B3/1 is unlatched, even if it was on, which is isn't.

...scans happen....nothing changes.....

Eventually...

Rung 4: T4:0 finishes.
Rung 5: T4:0.TT is no longer true, T4:1 drops out
Rung 6: N7:2 is still 1
Rung 7: T4:0.DN is true, N7:0 > N7:1 is true, so B3/1 latches, and N7:1 increments (to N7:0)
Rung 8: B3/1 is true, but T4:1.TT is not. Therefore no output
Rung 9: T4:1.TT is false, so B3/1 is unlatched.

Next scan:
Rung 4: T4:0.DN is true, so T4:0 drops out (reseting T4:0.DN)
Rung 5: T4:0.TT is not true, so T4:1 is still off
Rung 6: N7:2 is now 0 (n7:1 was incremented last scan)
Rung 7: T4:0.DN is false, nothing happens
Rung 8: B3/1 was unlatched last scan, nothing happens
Rung 9: T4:1.TT is still false, so B3/1 get unlached again (not that is was ON in the first place)

 

[gluca]

Allen you're right, the problem is in rung 0009, and it can be solved adding a T4:1/DN open contact, so as to unlatch B3/1 after T4:1 has finished timing, and not in the same rung B3/1 is latched.

Thank you Allen for your attention.

I'm interested in how you've debugged my file: simply reading it, drawing a timing diagram or running a siulation program or anyway how?

What's your job? PLC programmer, teacher, other?

By, Luca

 

[Eric Nelson]

D) Remember that he's using a DL05 PLC, so be careful when posting "exotic" addresses like T4:1.TT - not every PLC has a Timer Timing bit

And, sure enough, the DL05 is one of those PLCs that does NOT have a Timer Timing bit...

Easy to create something equivalent, that is, if the guy programming the DL05 already knows the function of a .TT bit!

-Eric

 

[Waidesworld]

Knowledge lacking

Unfortunately I don't know the coding for this which is why I went to this web forum in the first place. I have worked with PLCs but not as recently as 1994 and it's taking more than the time I have to refresh myself on this.

I am working with some other engineers on this also and if I do get a solution I will post it here for the benefit of all that helped. My only issue about a solution is that if it doesn't work I have wasted six hours of driving as the location is pretty remote.

 

[Terry Woods]

Man! For a "Quicky Problem" this is certainly one of the longer threads I remember seeing here!

Anyway...
Here's my take on the subject...

First, it appears that Waide did a poor job of describing the problem from day-1. As more and more "solutions" were posted he divulged more and more info about the system to explain why the "solutions" would not work.

So, now it's at the point where, maybe, we don't know what else to expect. Or maybe we now know all that needs to be known... maybe.

Anyway... From what I read, I am assuming that the counters are electro-mechanical. The following is my "guess" at his configuration.
.
.

.
.
.
Seems simple enough. Each loop provides a 12V Pulse when a vehicle is detected. The 12V Pulse goes to the Local Counter and to one of the PLC Inputs.

Now, here's what I see in my minds' eye when I "BE THE COMPUTER"
.
.
.

.
.
.

The three blocks at the top of the FlowChart have one job to do. They simply watch for OFF-to-ON transitions at their respective inputs. (See NOTES, below)

When one of the modules sees an OFF-to-ON transition it increments its particular internal count. An "ADD 1" is used to increment the current count value.

 Lane-1

 JustON     +-------------+      

---| |------| V1 = V1 + 1 |

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



 Lane-2

 JustON     +-------------+      

---| |------| V2 = V2 + 1 |

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



 Lane-3

 JustON     +-------------+      

---| |------| V3 = V3 + 1 |

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

.

That is all that each of these three modules has to do. Any one, two or three of these modules can be incrementing their particular count in the same scan. (See NOTES, below.)

V1, V2 & V3 Data-Types only need to be Integer. This is because the count in V1 or V2 or V3 should never exceed 2. It is most likely that the value in each will never even exceed 1. However, this scheme will accommodate counts upto integer limits - which ain't, never, no-how, gonna happen!

Now comes the big (well, bigger) module...

The first step is to check to see if UPDATE is ON. UPDATE is Output-1. If Output-1 is ON, that means that the Master Counters are currently being updated. If Output-1 is ON, then I check to see if the TimeOut Bit ON. If the TimeOut Bit is ON, then I go back and check the Inputs. Taking this path turns OFF the Timer and UPDATE.

If UPDATE was not ON, then I check to see if V1 is greater than Zero. If V1 is greater than Zero, then I subtract 1 from V1 and I start the Timer. As long as the Timer is ON, UPDATE is ON. As long as UPDATE is ON, I don't check the contents of V1, V2 or V3.

If V1 is NOT greater than Zero, then I check to see if V2 is greater than Zero. If so, then I subtract 1 from V2 and start the Timer. Again, as long as the Timer is ON, UPDATE is ON. As long as UPDATE is ON, I don't check the contents of V1, V2 or V3.

If V2 is NOT greater than Zero, then I check to see if V3 is greater than Zero. If so, then I subtract 1 from V3 and start the Timer. Again, as long as the Timer is ON, UPDATE is ON. As long as UPDATE is ON, I don't check the contents of V1, V2 or V3.

If V3 is NOT greater than Zero, then I simply return to Check the Inputs. Taking this path turns OFF the Timer and UPDATE.

That's all there is to it!

The purpose of the Timer is to allow the Output to be ON long enough to produce a valid count on the Master Counters. A single pulse lasting only one scan might not be enough to trigger the master counters - if they are the electro-mechanical type. Adjust the timer value as necessary to ensure a good count.

So, when the Inspector-General comes around looking for numbers, he sees the total count upto that point (unless some vehicles are crossing the sensors at that very time - then the count might be off by one or two). After he records the numbers he uses his key (or whatever) to reset the count of the Resetable Counter.

To "BE THE COMPUTER" means to put yourself in a dark place with nothing more than...

• a nice chair to sit in,
• a nice wide desk to sit at,
• a bunch of idiot lights on your left (inputs),
• a bunch of idiot lights on your right (outputs),
• a stack of scratch-paper, and
• a pencil.

Then you need to mess around a bit with your time frame.

PLC's have very small time segments. We, on the other hand, deal in longer time segments. The basic unit of which might be called, the "Six-Pack".

Under that constraint, we have to work very hard to see events which normally happen at PLC speed happening instead at our own speed.

It's almost as painful as switching back-and-forth between the frequency and time domains!

So, you watch the lights, make a few notes, throw a few output switches - all the time, paying very careful attention to how you naturally respond to various conditions.

The natural response is generally what you are looking to find. And, if you are as most of us are, you will try to find the easy, (lazy?) more efficient way to do anything.

If you can figure out what the hell you are doing (every detail counts!), then that is called "BE THE COMPUTER"!


NOTES:
This scheme will always bring V1 to Zero first, then V2, then V3.

A "Debouncer" is usually a good idea for electro-mechanical inputs.

You should be sure to Zero-Out V1, V2 & V3 on Start-Up.