RSlogix - Simple Car Park

[mitureg]

Hello everyone. I would like to thank anyone reading this post. I would appreciate any advice or thoughts on this program. I am a beginner.

This is a simple car park with a limit of 6. Please have a look and feel free to remark any flaws or mistake that might have been included.

I will post the rungs in 3 reply to make it easier to see, along with a program file in attachment. The program ends at rung #0010.

Cheers.

 

[mitureg]

Snippet 1

 

[mitureg]

Snippet 2

 

[pino2003fr]

the only problem i see you number goes below zero, when the car are exiting .

 

[mitureg]

The parking has 6 spaces. No car can exit without having prior entered. I was not able to repeat this troubleshoot. Can you explain more?

Thank you

 

[bernie_carlton]

Continously held sensors will cause multiple counts because the timer is interrupted for one scan.

The counter is protected in the UP direction from counting above 6 but in the DOWN direction it can count below zero.

 

[mitureg]

Thank you. I corrected that just now. Anything else that could be better improved ?
Much appreciated Bernie.

 

[daba]

I would suggest adding "debounce" logic to the entry and exit sensors. They need to be clear for a period of time before you deem the car to have "gone-through". It is always wise to guard against false triggering.

Another thing you could do is simplify....

1. you do not actually need the B3/0 and /1 "Isolators", you can simply put the counter instructions where those OTE's are.

2. the "seal-in" for the timers could be the .TT (Timer Timing) bit, then you can remove the XIO of the .DN bits from the rungs. .TT = .EN AND NOT .DN

3. you could also change the timers to TOF (Timer Off).... I see no need to hold the barrier up for ten seconds, when a car could pass through in say 2 seconds.... it would be better to keep it up for 1 to 2 seconds after the car sensor has deactivated.

4. I do not like to see XICs or XIOs of output addresses, as you have in rungs 4 and 7. Consider what might happen if the output was forced on or off (probably not applicable to this car-park scenario, but worth bearing in mind for future projects). Forcing an output ON or OFF is NOT reflected in the state of the bit in the output image table (forces are applied to the bits on their way to the output card).


It is great to see, from a beginner, a fully documented piece of code, keep it going like that and you'll be appreciated - well done!

 

[mitureg]

Hello Daba, thank you so much for your advice...

I have a few questions following your intervention:

I would suggest adding "debounce" logic to the entry and exit sensors.

Does that mean only adding and OSR in the same rung as the entry sensor and the exit sensor, or as a general idea "have a debounce logic" within the program? (I have attached my program)

1. you do not actually need the B3/0 and /1 "Isolators", you can simply put the counter instructions where those OTE's are.

The problem I had with this is that the Counter CT1 would increment if the Entry Sensor (or exit sensor) would stay close at the end of the count. Is that why you mentioned the use of "Debounce Logic" (OSR?), so this would actually allow me to simplify by removing these "ISOLATOR" as I called them naively?

4. I do not like to see XICs or XIOs of output addresses, as you have in rungs 4 and 7. Consider what might happen if the output was forced on or off (probably not applicable to this car-park scenario, but worth bearing in mind for future projects). Forcing an output ON or OFF is NOT reflected in the state of the bit in the output image table (forces are applied to the bits on their way to the output card).

I understand what you mean. I do not like to put XIC or XIO of output addresses neither. What would be a better solution, using B3 or putting OR rung branches for the output Any suggestions closer to the industrial standards?

It is great to see, from a beginner, a fully documented piece of code, keep it going like that and you'll be appreciated - well done!

Thank you very much for your compliment. You made my day!

 

[OkiePC]

Expanding on what daba said, use input mapping and output mapping.
I normally have a whole timer file for input mapping and include time phase shifting or just simple debounce timing to filter out false alarms.

I would then look into a sequence mechanism. You know the car has started to enter, you should be able to measure the duration of it's entry, and keep that whole control program in a specific mode for a minimum amount of time, and perhaps set a fault if the car is detected to have vanished or sped through a single sensor, and measure the total duration for each entry even if the sensor "flickers" during the motion.

By time limiting a sequencer in addition to better fault checking in each expected step when there is a mismatch, and with enough steps, you can be very specific about what to tolerate from switches in a nasty environment like a parking lot entry.

By mapping the outputs, you avoid the problems daba speaks of.

I also allow addition of timers to the output map to more or less hard code things like minimum reversal times for starters, or dwell times and interlocks for double solenoid valves.

Use the Advanced Search and search the forum for I/O mapping.

 

[daba]

Does that mean only adding and OSR in the same rung as the entry sensor and the exit sensor, or as a general idea "have a debounce logic" within the program? (I have attached my program)

Here's what I mean by "debounce" logic. This is my favourite way of doing this, but there are a few other ways. Typically this sort of logic is used for sensors that may go On-Off-On-Off repeatedly, for example a level probe in a tank night do this if the tank is agitated (stirred). The logic sets/resets an output signal only if the input has been at the same state for a period of time, as set by the timer preset values.

 

[daba]

The problem I had with this is that the Counter CT1 would increment if the Entry Sensor (or exit sensor) would stay close at the end of the count. Is that why you mentioned the use of "Debounce Logic" (OSR?), so this would actually allow me to simplify by removing these "ISOLATOR" as I called them naively?

That is because the TON timers would "time-out", and it would take a further scan of the logic to re-establish the .EN bit to keep the barriers up. If you take a look at the timing diagram enclosed of the TOF instruction, you can see that the .DN bit comes ON with the .EN going true, and stays in that state indefinately. When the .EN goes false, the timer will time, and the .DN bit goes false after the programmed time delay (preset). I believe this is better suited to your requirements, and avoids a false triggering of the counters.

 

[mitureg]

Ok here it is. I would like to take this opportunity to thank these 4 gentlemen that gracefully helped me enter the last phase of this project up to professional standards: Daba, Bernie, OkiePC and pino2003fr.

This is my first real PLC program in my lifetime.

-I added the debounce logic for the entry and exit gate sensor
Question to Daba: Do you usually put these Debounce Logic rungs in a subroutine?

-I use TOF now for 2 seconds after the car has cleared the input sensor and use the /TT of each timer to count cars in and out.

-The exit gate can't open if the car park is empty. This also prevent the counter to go under 0 value (-1,-2..) with the use of a EQU = o that blocks the exit gate and counter if the car park is empty.

Any additional advice or comments would be most welcomed. :site:

Cheers!

Program in attachment...

 

[daba]

I added the debounce logic for the entry and exit gate sensor
Question to Daba: Do you usually put these Debounce Logic rungs in a subroutine?

Yes, put all your input conditioning in one subroutine. One call (JSR) to that subroutine per scan is all you need. Nowadays in Logix5000 I would use an Add-On Instruction for each input, but you don't have that luxury with Logix500. Even then the AOI's would all be in one routine... tidy.

I use TOF now for 2 seconds after the car has cleared the input sensor and use the /TT of each timer to count cars in and out.

-The exit gate can't open if the car park is empty. This also prevent the counter to go under 0 value (-1,-2..) with the use of a EQU = o that blocks the exit gate and counter if the car park is empty.

Not the way I would do it....

If a car appears at the exit gate when the software thinks the car-park is empty clearly indicates the software is wrong, and has lost track of how many vehicles are in there.

Under these sort of circumstances, you have to let the reality of the situation override the software, not the other way round. The reality is that there IS a car in the car-park, at the exit gate, trying to get out, irrespective of how many counts the counter has. Imagine the inconvenience to the driver if he can't get out of a car-park, just because the count has got screwed.

I would let the car out regardless of the count in the counter, but prevent the counter going below zero, that's all. It just needs one rung...

LES C5:0.ACC 0 CLR C5:0.ACC (or MOV 0 C5:0.ACC)

or you could put GRT C5:0.ACC 0 in the rung with the CTD instruction, either way stops the counter going negative, although I prefer the trap rung above, as it is more robust.

 

[mitureg]

Hi Daba, thank you for your reply. There seems to be a problem with the LES C5:0.ACC 0 CLR C5:0.ACC logic. I think its due to the fact that I am using the same bit for the CTU/CTD for the exit and entry barrier?

Also, I can't seems to have the JSR and RET properly configured. It gets jammed in the debounce sequence. The barrier always stays up and the counter doesn't increment or decrements properly.

Any clues?

Please have a look at my file in attachment.

Much appreciated.