My attempt at a parking lot plc program from last week.

ThomasHunter

Member
Join Date
Nov 2021
Location
Ontario
Posts
8
This is the reason why I signed up here and decided to get some help before I tackle the traffic light program on Wednesday.

It looked good on paper, but it did not work out and ended up getting me a subpar grade. I decided to remake it to see what everyone's opinions and insight is on my design.

This lot can hold only 25 cars. Design a PLC routine that will keep track of the number of vehicles entering and/or leaving the lot in order to avoid the possibility of vehicles entering when no space is available. There are photo-eye switches located on each side of the enter and exit gates. Photo-eye switch 1 (In 1) detects when a car is at the entrance gate. Photo-eye switch 2 (In 2) detects when the car has cleared the entrance gate and is fully in the lot. The entrance gate will be controlled by solenoid valve 1 (O:2/0). The entrance gate must be disabled when the lot is completely full.
Photo-eye switch 3 (Out 1) detects when a car is at the exit gate. Photo-eye switch 4 (Out 2) detects when the car has cleared the exit gate and is fully out of the lot. The exit gate will be controlled by solenoid valve 2 (O:2/1). Flash (0.25 second on/off) pilot light PL8 when the lot is full. Pilot light 8 will remain solid when the lot is not full.

Rungs1-5.png Rungs6-10.png
 
Last edited:
First problem: no comments.

Go back and describe what each rung, or sequence of multiple rungs does.

Do not just say what the code is doing internally

  • e.g. do not say for rung 000, when [In 1] is 1 AND [In 2] is 0 AND C5:0/DN is 0, assign 1 to the value of O:2/0);
instead describe what you think the code models that process is doing

  • e.g. IF a car is detected at sensor [In 1] i.e. a car is waiting to enter, AND there is no car (yet?) at sensor [In 2] i.e. car has not yet passed entrance gate, AND lot is not full, THEN open the entrance gate (O:2/0).
Often in so doing you will find a discrepancy between

  1. the physical process, and
  2. the virtual process model that the code represented.
That is a form of Rubber Duck Debugging cf. here.
 
Last edited:
That is a form of Rubber Duck Debugging cf. here.

I wondered what that was. Thanks for that. I explain stuff all the time to my GF who knows nothing about PLC, programming or software design and I have found that I realize during the explanation that I have a problem that needs attention. She's a peach; she listens and doesn't complain. I don't do that too often. Thanks again!
 
Second problem: the latch and unlatch of the entrance gate are not next to each other. This is a minor criticism, because this is a short program and there are only two rungs between them, but if at all possible, latch/unlatch pairs should be adjacent. Or, if it is necessary that there be logic between them, because things have to be tested in a certain order, then comments on the latch rung stating why and where the unlatch operates, and vice versa, would be a good idea.

Third problem:

  • Ff a car arrives and activates the first sensor ([In 1] on Rung 000), but not the second ([In 2]), and the lot is not full, then the gate opens because O:2/0 becomes 1.
  • That O:2/0 becoming 1 starts the T4:0 timer on Rung 001
  • If the car does not move forward and activate the second sensor (In 2) within 1.0s (T4:0.PRE time 0.1s),
    • then the reset on rung 002 does not occur, so the T4 timer will complete,
      • and T4:0/DN will have a rising edge,
        • which rising edge will cause the CTU on Rung 003 to increment the lot count.
        • So, if the car then backs away without going in, the count is (at least) one more than the number of cars in the lot.
 
... Photo-eye switch 1 (In 1) detects when a car is at the entrance gate. Photo-eye switch 2 (In 2) detects when the car has cleared the entrance gate and is fully in the lot. ...

Problem four is in the problem statement itself:

How does Photo-eye switch 2 work?

E.g. say a car comes in, triggers Photo-eye 1 [In 1] i.e. I:1/0 becomes 1, your logic opens the gate, as the car moves forward [In 1] I:1/0 returns to 0, and, when the is clear of the gate and "in" the lot it triggers Photo-eye 2 [In 2] i.e. I:1/1 becomes 1, and the continues on to park somewhere in the lot.

When the next car approaches the gate, what is the state of Photo-eye switch 2 [In 2] I:1/1? The problem statement states that [In 2] "detects when the car has cleared the entrance gate." Well, that first car is clear of the entrance gate even after it is long gone and parked, so should [In 2] I:1/1 still be 1? If yes and it is 1 from the first car, then how will it detect that the next car is clear of the entrance gate? Or maybe [In 2] is a one-shot that is a pulse, say 100ms i.e.long enough for PLC to detect the event, when the car clears the gate?

Also, if a value of 1 for [In 1] declares "a car is at the gate," and a value of 1 for [In 2] declares "a car has cleared the gate, then it is necessary that both must be 0 at some point when the car is between between the sensors, because a car cannot both be at, AND have cleared, the gate, at the same time. That being the case, what happens if a car triggers [In 1], then backs up and leaves so the value of [In 1] returns to 0? The gate is opened, but because the care is never detected as cleared, the gate should be left open because the system cannot detect the difference between the car being in between the sensors ([In 1] and [In 2] values are both 0 and gate has been opened) and having backed up ([In 1] and [In 2] values are both 0 and gate has been opened - i.e. same conditions). Maybe that is okay, and the next car will trigger [In 1] again but the gate is already up, and eventually one car will trigger [In 2], so who cares?

Or, say [In 2] becomes 1 when a car moving forward clears the gate, but then becomes 0 again at some point as the car continues forward. If that is the case, then what happens if a car triggers [In 1] and the gate opens, the car then clears [In 1] and triggers [In 2], so [In 1] is 0 and [In 2] is 1, but then the car backs up, but not far enough to re-trigger [In 1], so now both [In 1] and [In 2] are 0 again? How is that sequence any different from the normal expected case of a car moving forward through both sensors? It is not, so presumable the program (model) will increment the count and close the gate, possibly damaging itself and/or the car, which care is now back between the sensors.

Yes, I know I am being bloody-minded and overly literal here, but ambiguity in the problem statement is exactly what item 4 of @James Mcquade's list in the other thread is about. Talking with the mechanical designer could even cause a change in the physical system because that designer realizes the physical arrangement has flaws that will keep it from correctly handling all possible situations, like a car approaching, triggering the gate, but then backing up and leaving.

My point is that any computer program is a model of something in the real world. That model has assumptions, and it is useful, if not critical, to state those assumptions. So, before you write the program (model), make sure you declare unambiguously any assumptions about how the model works. At a minimum, with the current problem description, you could highlight the ambiguity in the behavior of Photo-eye 2, declare which way you assume the ambiguity is resolved, and state that the program works correctly only if cars behave in a normal manner, i.e. go forward, stop until gate opens, and continue forward into the lot and not back up.
 
Last edited:
Thanks for your posts drbitboy! They are truly helping me produce a better way of thinking while creating a plc program. Truly appreciate the knowledge!

Here is my second diagram with descriptions. I hope it helps somewhat. I truly am clueless with the Greater compare bit and my counters exceed 25. Would placing a '<' in front of some values in the counters help?

PARKING1.png PARKING2.png PARKING3.png
 
  • Why is the [XIO I:1/1(PES2)] on Rung 000?
  • What is the purpose of the timer and timer reset on Rungs 001 and 002?
    • Specifically, state the process logic, i.e. why should there be a timer on the gate when we already have something to detect when the car has cleared the gate?
  • Why is the [XIO O:1/0] on Rung 003?
    • Ignore the timer interaction for now
    • That rung ultimately unlatches [Entrance Gate OPENS] i.e. puts a value of 0 into O:1/0 i.e. closes the gate
    • The CTU does this by detecting a rising edge of [PES2] and [NOT(Entrance Gate OPENS] i.e.
      • from NOT(PES2==1 AND O:0/1==0) to (PES2==1 AND O:0/1==0)
      • stated another way, from (PES2==0 OR O:0/1==1) to (PES2==1 AND O:0/1==0).
        • Since this is the only logic that changes O:0/1 to 0, the only way for it to fire - though the CTU - is for O:0/1 to already be 0.
          • Say the car drives through [PES2] before the ten seconds are up, so the timer is reset (Rung 002) and never expires,
          • Since the timer never expires, the T4:0/DN branch on Rung 003 never becomes True, so O:0/1 remains latched i.e O:0/1 has a value of 1,
          • So the counter input rung can never become True, because the [XIO O:0/1] is False (O:0/1 is 1).
 
Last edited:
...
  • Why is the [XIO O:1/0] on Rung 003?
    • ...

What I am trying to get at is that closing the gate and counting the car are separate operations, and require separate logic.

There may be times where the entrance gate closes (O:1/0 changes from 1 to 0) and the count should increment.

There may also be times where the entrance gate closes and the count should NOT increment e.g. if the car triggers an opening of the gate but then backs out without clearing the entrance gate on the parking lot side of the entrance gate.

Again, this highlights the case where the car can be between the two entrance sensors, so neither sensor is 1, which cannot be distinguished from the case where the car triggers [In 1] but then backs out. If this indeed the case, the simplest program would

  • open the gate when [In 1] is triggered (the value of I:1/- becomes 1)
    • and the lot is not full
  • and close the gate when [In 2] is triggered (the value of I:1/1 becomes 1),
    • And the gate is open
    • This would also be the event that causes the counter to increment
  • with the caveat that the program
    • leaves the gate open if a car triggers [In 1] but then backs out without triggering [In 2],
      • Although that will be corrected for the next car that goes through both sensors.
    • has the wheels come off, figuratively,
      • if a car triggers [In 2] but then backs up to re-trigger [In 1] before the gate comes down,
      • or if a stretch limo comes in and triggers both sensors at the same time
 
Last edited:
*snipped and quotes from both posts*

For the PES2 I was simply confused and thought of adding a TON to the program for the gates as a failsafe. At the beginning I did leave timers out because I believed the same thing. Once PES2 is actuated it means the entire object is cleared to me as well.

XIO I:1/1(PES2) I believed was needed, but it can be removed.

I am going through everything you posted line by line to see how it can all click into place for me.

Really appreciate the information, drbitboy. Supremely awesome of you!

EDIT: Is there a way for the CTU and CTD to stop counting once they reached their presets?
 
Last edited:
EDIT: Is there a way for the CTU and CTD to stop counting once they reached their presets?

Well, I think you can answer that if you can answer these: what event causes CTU to count up; what can you do, or what condition can you test, to stop that event from happening when the count up should stop; what event causes CTD to count down; want what can you do, or what condition can you test, to stop that event from happening when the count down should stop?

Although to be fair, the gates operating correctly should prevent any car from triggering a count up or down
 
Last edited:
The first image below shows two possible cases for placement of the sensors around a gate. The difference is whether the car-approached-gate sensor is

  • EITHER no longer triggered ([In 1] is 0)
    • i.e. the sensors have no overlap
  • OR still triggered ([In 1 is 1)
    • i.e. the sensors have an overlap
when the car-cleared-the-gate sensor is triggered ([In 2] becomes 1).

In the no-overlap case (former case above and upper half of first image below), the rising edge of the gate-cleared sensor indicates when the car has cleared the gate. The typical order of events is A, B, C, D (see first image); this is the less interesting of the two cases; see the next paragraph for the more interesting case. Because this case is less interesting, the second image below shows code that controls the gate (Rung 0001) and counts the incoming car (Rung 0000). That code can handle some unexpected movement of a car as detected by [In 1] and [In 2], but it will not handle all cases (e.g. a second car arriving at the gate while the first car has not cleared the second sensor).

In the overlap case (latter case above and lower half of first image below), the falling edge of the gate-cleared sensor indicates when the car has cleared the gate. The typical order of events is A', C', B', D', and it is that final falling edge event at D' that will close the gate and trigger the count of the car, but the code must ensure that a car backing up and generating a falling edge at position C' does not close the gate or count the car as in the lot yet. This is because, when detecting a falling edge at [In 2] while looking at [In 2] alone, the program cannot tell distinguish between

  • EITHER the falling edge occurring with the car moving forward at position D',
  • OR the falling edge occurring with the car moving backward at position C'.
Similar logic applies to determining when the gate should be held open. It is those subtleties that make this case more interesting, which is why I am not providing the code for this overlap case.

xxx.png


########################################################################


yyy.png
 
From OP's related thread:

The other half is to handle the cases where it doesn't work as intended.

+1.

I have been thinking about the parking lot application. A lot. Too much probably.

A few "doesn't work as intended" cases I can think of offhand are
  • Car backs up after activating either or both sensors;
  • Second car activates approach sensor before first car activates "clear" sensor (i.e. car is beyond, and clear of, gate) sensor;
  • Stretch limousine, which activates both approach and clear sensors, when logic assumes approach is deactivated before clear activates (upper half of diagram in my last post).
    • Although what a stretch limo is doing in a parking lot may be part of another conversation.
Also, we don't know much about the sensor(s). For example, a single optical through-beam sensor angled both across the entrance and across the line of the gate could detect both approach and clear conditions:
single_sensor.png
If the sensor is like that, then a simple XIC on that input* feeding both OTE gate-open and CTU/CTD counter instructions is all that is needed for the base case, assuming cars never backs up.

* ANDed (in series) with an OR (parallel circuit) of an XIO on the counter/DN bit and the gate-open output; the ORed circuit is needed to ensure the gate stays open until the 25th car clears the gate.

The actual arrangement of sensors also affects whether any logic and be implemented to deal with a second car closely following the first.

There is also the issue of debounce for events that comprise multiple 0-to-1 and 1-to-0 transitions.

Bottom line though, this application can be probably be implemented with nothing more complex than a combination of Start/Stop and State Coil/Fault Coil circuits, cf. this link.
 
Last edited:

Similar Topics

Hi, I have a RSLogix 500 that when I try to go online (ethernet) to a SLC1100, I get this error message. "No response form processor at the...
Replies
7
Views
1,566
Greetings, Not sure if this is the place for Vijeo questions. I’m still new at Vijeo development. I’ve got the basics down – screens, child...
Replies
12
Views
6,838
Working with dmroeder to get a AB PIC adapter to work under Windows using SP3 update. Installed his SP3 fix file and still can not get RSlinx to...
Replies
25
Views
6,196
This is my first ever attempt at logic. I was tasked with creating an auto cycle for pumps based on tank level. 2 pumps should not run at the...
Replies
3
Views
2,217
Hello. Stayed after work tonight and finshed this while there was no one around to make me do something else. My first attempt at Logix5000, it...
Replies
6
Views
3,135
Back
Top Bottom