Need help on a pain in the booty issue!

[oldskewl]

I am making a Allen Bradley PLC500 ladder logic program for a ferris wheel application and cannot get my latch( a photocell) when 'someone' steps off the photocell...here is an example of a part of my program:

[I:2/4]------------------------TON

[T4:1/EN]--------------------[OTL]

[T4:1/DN]--------------------[OTU]

Is there a way to keep the OTL latched when the I:2/4 becomes XIC? Any help will be appreciated. thanks.

 

[DwSoFt]

a little more detail would be more helpful, but im going to take a guess.

ok so you want to get it to latch when someone steps out of site of the photocell, and then the timer will keep the output latched until it times out?

 

[iant]

yes there is
Search for the Toggle or FlipFlop posts in this forrum
it is the same logic

 

[bulletin blues]

oldskewl,

Describe what you are trying to do in plain words. I'll give an example.

"I have a ferris wheel application that I am trying to figure out. I have a photocell that detects when a person steps into the lane of the incoming carriage and ensures the ferris wheel will stop if someone is in the path. I would also like to detect if a person leaves the area, so that I can continue running the ferris wheel, after they have exited the safe area. I believe that using a latch and unlatch circuit will work, but I am running into some problems with my logic."

It is difficult for me to understand what you are trying to accomplish based on the information you have posted. I applaud you for posting at all! Many of the individuals I work with in the field would not even take the time to login to PLCS.NET and even try to ask a question, so please don't think I'm bashing you. Just remember, you need to be extremely specific about what you are trying to accomplish, otherwise it's kind of a mystery to everyone else.

 

[oldskewl]

a little more detail would be more helpful, but im going to take a guess.

ok so you want to get it to latch when someone steps out of site of the photocell, and then the timer will keep the output latched until it times out?

When a person activates the photocell, the output needs to be latched. It needs to stay latched when the person moves to sit in the ferris wheel and continue to be latched until the timer times out.

 

[DwSoFt]

[I:2/4 XIC]-------------------[OTL]

 

[I:2/4 XIO]-------------------[TON]

 

[T4:1/DN]--------------------[OTU]

I Believe this would work for you

 

[Ken Roach]

What address is on the OTL (Output Latch) instruction ?

The address associated with the OTL instruction should remain True until the Timer times out.

But if the Input doesn't stay true until the timer times out, the address associated with the OTL and the OTU will never go Flase.

I think maybe the misunderstanding is coming if you're trying to "latch" the Input address; that's just fundamentally against the rules and the state will be overwritten the next program scan by the actual state.

I think that what you actually want to do is "seal in" the timer so that once it starts, it continues to run until it is complete. The standard method for that is to place a branch around the Input condition, with XIC T4:0.EN XIO T4:0.DN in the branch.

 

[DwSoFt]

I Thought of the seal in cct, but im not so sure that is what he is after

in my example a guy steps in front of the photocell. which then makes the first rung true, and latches the output.
rung 2 is now false and rung 3 is false. now he steps out of the photo cell, rung 1 is false, but rung 2 is now true starting the timer. rung 3 becomes true once the timer is done, and turns the output off

now if he wanted to do it with an OTE instead of OTL/OTU then a seal in cct would be necassary i would think

i do see a possible flaw in my logic, if a second guy steps into the photocell. the timer is reset. now depending on the application, this may be desireable, or not. if not, then a seal in cct would be useful.

 

[OkiePC]

Ken's is logically equivalent to the OP pseudo code, and you could trim it more by replacing the "timer enabled and not done" branch with XIC timer timing.

In reality, you would probably have more than one timer, perhaps debounced so as not to react to every brief flicker, but then again, perhaps some kid would be able to blink the eye for one PLC scan jumping on a ride.

 

[dcooper33]

How about a TOF timer?
If I understand the OP's request, a TOF would be perfect for the job. In this example, the Output would come on as soon as the Photocell is tripped, and then remain on for 10 seconds after the eye clears.
It's always good to avoid Latching a physical output whenever possible, IMHO, and in this application it is unnecessary.

 

[DwSoFt]

Ken's is logically equivalent to the OP pseudo code, and you could trim it more by replacing the "timer enabled and not done" branch with XIC timer timing.

In reality, you would probably have more than one timer, perhaps debounced so as not to react to every brief flicker, but then again, perhaps some kid would be able to blink the eye for one PLC scan jumping on a ride.

Good point. i forgot about the nature of a photocell to flicker lol.

 

[daba]

How about a TOF timer?
If I understand the OP's request, a TOF would be perfect for the job. In this example, the Output would come on as soon as the Photocell is tripped, and then remain on for 10 seconds after the eye clears.
It's always good to avoid Latching a physical output whenever possible, IMHO, and in this application it is unnecessary.

This is a good use of the TOF instruction, often overlooked by many programmers.

Most consider that the TOF is timimg something going false, and condition their Timer.EN with TRUE logic.

In this instance though, the timer is being used as a "pulse stretcher", keeping the .DN bit true for the timer's preset time after the input goes false again.

              _
Input    ____| |________________________
              _
Timer.EN ____| |________________________
              __________________
Timer.DN ____|                  |_______
                ________________
Timer.TT ______|                |_______

However, I would consider that the input, being from a "photo-eye", would likely go false when the beam was broken (fail-safe), so I reckon an XIO should enable the timer.

         ____   ________________________
Input        |_|
              _
Timer.EN ____| |________________________
              __________________
Timer.DN ____|                  |_______
                ________________
Timer.TT ______|                |_______

 

[DwSoFt]

thank you bmacattack/daba. i now realize you are right. it would be perfect. but like okiepc said, the photocell input should probably have a debounce timer to avoid false triggering.
so the code would look like this

|----[photocell]----------------[debounceTON]--|

|                                              |

|----[TON/DN]---------------------------[TOF]--|

|                                              |

|----[TOF/DN]------------------------[OUTPUT]--|

 

[daba]

Good. Now that the hypothetical situation is dealt with, let's move into the real world.

Do NOT rely on a timer to re-start the ferris wheel. There are many situations where the "passengers" may not be seated properly, may still be getting in, delayed by the previous occupants getting out etc. Re-starting the wheel must be done by an attendant, who has to decide that everything is in order.

I for one, would not be happy to let Joe Public near an autonomous "machine" that decides to start with no other inputs than a broken photo-cell, and a timer that "assumes" everything is OK to start.

I'm hoping this was a theoretical exercise, or homework, if not, I'm hoping you take this post seriously.