RSlogix - Simple Car Park

[mitureg]

Anyone on this problem?

Cheers.

 

[daba]

Sorry for not replying sooner, I've been away for a few days.

Looking at your posted file, the only comments I can make are as follows....

The debounce logic is not "a sequence" as you described it, it is simply a piece of the logic that is continuously and sequentially scanned.

Don't make the JSR to the Input conditioning (debounce) subroutine conditional, just JSR it.

Making it conditional on the input being ON means that the logic doesn't get scanned when the input is OFF, so the debounced output from the logic can never "turn off".

Just noticed you call it again for the exit sensor... You only need to JSR the input conditioning (U:3) once per scan. The logic uses the debounced states of both inputs. Think of the debouncing of input signals as being something that must always be done, for all {relevant} inputs. (Think of this as "equipment control").


The Return instructions in the debounce logic (file 3) are not necessary, and will give you grief.

Now think how your "Equipment Control" delivers the debounced state of your inputs to your "Procedural Control". Separating the 2 entities in this way is the key.

Here are the edits you need to do to make this work....

File:Rung

2:2 delete the XIC I:0/0 - JSR becomes unconditional

2:6 delete the rung

3:3 delete the branch with the RET instruction

3:7 delete the branch with the RET instruction

HTH

 

[Lancie1]

Anyone on this problem?

Yes. This program is so short, forget the subroutine. It will only add confusion. Leave out a lot of the fluff and fix it so it will work. I think every vehicle barrier or gate in current U.S. lawyered-up times must have a sensor downstream to detect if a vehicle is stopped at or under the gate, before the gate can be reclosed. Otherwise there will be some shyster send a car through and stall it under the gate just to get a injury and damaage case going. I added two sensors for that purpose, and managed to reduce the rungs down to 9 instead of 18.

 

[daba]

Using a subroutine to perform input signal conditioning is never mandatory, however it is considered good practice to break up your code into defined "functions".

In this application there are only two inputs to debounce, and yes Lancie1 is quite correct to point out that the subroutine is a tad overkill for this simple application....

However, I recommend you to take on-board the notion of using subroutines in this fashion.

Once you have entered the debounce code for all your inputs, and tested them, you can happily forget about them, and treat the subroutine as a "black box" that just does what it does. I see no reason to clutter the application-specific code with the mundane task of cleaning up the "inputs" to the application.

Segregating a given task into separate program file "blocks" makes a control program easier to follow, I don't agree that it adds to any confusion.

I'm sure that when the time comes to program for a real situation, you will be in the position where your peers will guide you, and ensure you adhere to "current practice". Most car park entry and exit gates have inductive loops in the ground, sensing that there is a large metallic object "in the way", which keeps the barrier up until it has been removed.

This usually prevents damage to vehicles. But this will not prevent possible injury to someone walking under the raised barrier, which is usually taken care of with large signs saying "No Pedestrian Access", "Do Not Walk Under The Barrier", etc.

I suppose it would be feasible to sense just about anything... with capacitive proximity sensors, light-curtains, even vision systems could be employed, but ultimately it boils down to cost....

 

[Lancie1]

I don't agree that it adds to any confusion.

I think the confusion was caused by doing the debounce function 3 or 4 times, one set in the main program, then another set in the subroutine, when only two inputs could possibly need it, and then only to prevent double-counting for the number of cars parked.

I think my so-called debounce method took care of the problem. At least I could not make it double count in the LogixPro Simulator, which is a pretty good emulation of RSLogix. I don't see that splitting 9 rungs into 2 sections would help anything at all except take longer to read. If it were 100 or 200 rungs, then you might have a point.

But this will not prevent possible injury to someone walking under the raised barrier, which is usually taken care of with large signs saying "No Pedestrian Access", "Do Not Walk Under The Barrier", etc.

That may still work in Canada and the UK, and was okay here 10 years ago. Now, there are thousands of starving ambulance-chasing lawyers that are looking for any excuse to file a $10 million court case. It doesn't have to be just, but only good enough to allowed into court by some judge. Then the accused faces 10 years in court and several million in legal fees, or has to agree to settle out of court for extortion money.

 

[daba]

I did not consider the debouncing of the inputs, and keeping the barrier raised for a period of time after the car is not sensed as "double-debouncing".

In my mind they have 2 completely separate, and independant functions.

 

[mitureg]

Thank you for your advice Lancie & Daba. The last version is very concise and I think that is a plus. I would consider JSR even if it's a small program just to exercise myself. I will conclude this work with a written analysis rung-by-rung during the week. I will keep you updated.

Cheers.

 

[Lancie1]

Debouncing is overblown, not as important for a student program, and often a snipe hunt for the new guy to run around in circles, while the old guys sit back and wink and laugh.

Get the subroutines in your elevator program straightened out and working. That should keep you off the street for a few days. You don't need a subroutine for the Drink Machine or the Car Park. It would look pretty darn silly in a 9-rung program.

PS: The comment for new Rung 0008 should say: "This rung decrements a counter...."

 

[mitureg]

PS: The comment for new Rung 0008 should say: "This rung decrements a counter...."

Got it.

Get the subroutines in your elevator program straightened out and working.

Working on it.

Cheers Lancie.

 

[mitureg]

Hi Lancie, I can't use any extra input for this problem. I understand your idea but it cannot be.

There is only 2 I/O available which are:

Entry Sensor (IPO)
Exit Sensor (IP1)

I have to eliminate the 2 extra that you created which are:
Entry Gate Not Cleared (IP2)
Exit Gate not Cleared (IP3)

I figure these can't be replaced as it is by B3s. Any idea?

Cheers.

 

[Lancie1]

I figure these can't be replaced as it is by B3s. Any idea?

Yes, in case the "customer" has asked for a design that is unsafe or could lead to an expensive court case and injury or damage claims, there are TWO methods:

(1) Do the program in a safe manner (as you have now), but add documentation explaining WHY it needs to be this way, instead of the customer's preferred method.

(2) Do as the customer requested, but document it well, with a big WARNING in the program comments, and also require the "customer" to sign a letter where you explain the legal dangers of doing the program HIS way, and how it could lead to a damaged vehicle if a gate should come down on a stalled car, or on a person standing next to his stalled car, or simply come down on a car where the driver is doing somthing else while sitting under the gate. At many parking garages, people stop (after getting a parking ticket on the entry side) to put away their ticket, or answer their cellphone, or tune the radio.

If you do not provide such warnings, then you the programmer and your company (if any) could and probably would be held liable for the damages (at least here in the US). If you choose Method 2, then here are the changes to make:

Rung 0003: On the left (input) side, delete the 3rd rung branch. Also in your comment, add a big warning notice:

"WARNING!! Failure to add or use a vehicle-and-person detection sensor under the gate could lead to car-park customer vehicle damages, personal injury, legal fines, and a lawsuit. The lawsuit could result in large damage and penalty monetary awards in a long court case that could drag out over several years, with large legal fees, and loss of time when the car-park owner has to appear in court numerous times."

Rung 0004: Delete I:0/2, and add the warning same as above.

Rung 0007: On the left (input) side, delete the 3rd rung branch. Also in your comment, add the same big warning notice.

Rung 0008: Delete I:0/3, and add the same warning notice.

Another problem with Method 2 is that without a sensor that detects the car passing the gate, you really can never be sure that your vehicle count is accurate. What if a driver pulls in, trips the Entry sensor, but then changes his mind and backs out? The driver could sit at the entry point 2 seconds, or 200 seconds, but without a detection sensor just past the gate, you would count that vehicle, but it would NOT be in your park. Over a year's time, you could lose a lot of money with empty spaces where your PLC program did not count correctly and did not allow all parking spaces to be filled.

The same problem applies for cars leaving the parking area: A driver might change his mind at the last second and stay in the place, meaning that the next IN vehicle might not have a space to park. Then you will have a very mad customer that is going to raise hell, demand his money back, and probably will never park in your place again.

 

[mitureg]

Thank you for the options and justification Lancie, I wrote to my tutor to double check on this. My guess is that he is going to tell me to stick with the unsafe version. That's what he said for another program, but it was different so let's see...

As a side note...
It's quite an education system we have now..(!) not much concern for real-world application for the most part. We've gotta give them the credit they deserve... those institutions! Good teacher are scarce. I consider myself extremely lucky to have you Lancie.

Then you will have a very mad customer that is going to raise hell, demand his money back, and probably will never park in your place again.

I laughed at this one... good one heheh.

 

[Lancie1]

I know his response:

"Stop worrying about these niggling details. Just do it like the problem says. It doesn't matter if it is unsafe, as long as you learn how to write the program. Anyway, the gate will have built-in sensors."

Yes, but your program is supposed to CONTROL these gates, so if there ARE built-in sensors, then they should be used in the PLC gate-control program.

I think there are a lot of unsafe or legally-risky PLC programs already out there and running.

Here is something to think about. Every residential garage electric door opener in the world has some type of sensor that detects people or objects underneath the door when the door is closing. That is so the manufacturer cannot be held liable for injuries or damages when the door comes down on top of something. Why would anyone think that the gates at a commercial parking lot should be designed to be more risky?

 

[mitureg]

Why would anyone think that the gates at a commercial parking lot should be designed to be more risky?

Yup good point.