Traffic Control Cross Walks.

Hello. I am having so much trouble with this. Problem:

• 
  [*]When depressed, the crosswalk pushbutton will cause the appropriate Walk Sign to be illuminated at the next occurence of a Red to Green transition for the appropriate direction.
  [*]If the Green light is already illuminated when the button is pressed then the Walk signal sequence will be delayed until the next Red to Green transistion ocurrs.
  [*]Once the Walk Sign is illuminated, it will remain so for the duration of the Green signal.
  [*]When the Amber light appears, the Walk Sign will commence to flash On and Off and continue to do so until the Red signal appears.

My ladder logic is attached. I have been working for maybe 3-4 hours trying to get the cross walks to work properly but have have had no luck. I think I need to unlatch B3:0/2 when O:2/00(left red light) goes false after O:2/7(walk sign) has been on. Pretty much the first two steps I am having trouble with. I got the walk sign to flash and stay on for the duration of the green light. Can anyone offer any advice.

Thanks.

Hello z32man and welcome to the forum.

Traffic light problems get little respect on the forum so don't be disappointed if you get few replies or negative comments.

You did show your work and do a fair job of explaining your situation so I think you deserve a break.

With that said, my advice would be:

1) Break up your screenshot into smaller chunks that better fit the attachment size restrictions without all the whitespace. Two or three Jpegs would be readable, whereas the one you posted is blurry when zoomed in.

2) Add address comments for all your addresses. Make them concise and apply to the true state of each bit/register.

3) Rewrite the problem in more "ladder friendly" terms without "breaking" it. Example:

When depressed, the crosswalk pushbutton will cause the appropriate Walk Sign to be illuminated at the next occurence of a Red to Green transition for the appropriate direction.
If the Green light is already illuminated when the button is pressed then the Walk signal sequence will be delayed until the next Red to Green transistion ocurrs.

Click to expand...

I would rewrite as:

When the button is pressed, seal in a bit called "Cross Walk Sequence Request" that remembers that the crosswalk light sequence needs to run. When the crosswalk sequence is done, unseal this bit.

When the appropriate direction signal is first activated (think one-shot) and the "Cross Walk Sequence Request" bit is set, then begin the crosswalk sequence.

Click to expand...

4) Draw a flowchart or state diagram that summarizes the logical flow. That will help you organize things and should translate into ladder logic more easily.

This should get you started, and good luck.

Paul

Sorry, I figured the image created by the program would not be too small. I have attached a pdf.

OkiePC said:

Traffic light problems get little respect on the forum so don't be disappointed if you get few replies or negative comments.

Click to expand...

The threads I've seen about this looked as if they hadn't tried anything.

1. Done
2. Done, I believe
3. working on
4. working on

I'm not sure how to unlatch the bit "Latch for crosswalk light, and "When the appropriate direction signal is first activated (think one-shot) and the "Cross Walk Sequence Request" bit is set, then begin the crosswalk sequence." Not sure how to use a one shot here.

Thanks.

z32man said:

2. Done, I believe
...

I'm not sure how to unlatch the bit "Latch for crosswalk light, and "When depressed, the crosswalk pushbutton will cause the appropriate Walk Sign to be illuminated at the next occurence of a Red to Green transition for the appropriate direction."

Thanks.

Click to expand...

My bad on the comments...they're below the instruction instead of above like RSLogix...

As for your dilemma, think one shot rising. I am not sure of the instruction in LogixPro. It might be OSR or ONS or something else.

Also, you need the crosswalk request bit to stay sealed in until your LIM instruction makes a true to false transition for the appropriate direction. Assuming I read the logic correctly, if it is already on, your rung will not seal in to store the request. In other words, when the light goes off, one-shot a bit address and use that to unseal the request rung.

To beging the crosswalk sequence, you need a oneshot when the light first turns on. That way, if the light has already been on for at least one program scan, and then the button is pressed, the request will seal in, and then not begin until the next false to true transition of the appropriate traffic light.

OkiePC said:

Also, you need the crosswalk request bit to stay sealed in until your LIM instruction makes a true to false transition for the appropriate direction. Assuming I read the logic correctly, if it is already on, your rung will not seal in to store the request. In other words, when the light goes off, one-shot a bit address and use that to unseal the request rung.

Click to expand...

Thanks for your help, it is OSR with LogixPro.

When I put the OSR inline with the LIM instruction that I need the red light does not come on when the OSR is true. I got around this problem with a bit comparison with when the LIM instruction would be true; probably not acceptable.

I think my biggest concern is if my logic where I used the bit comparison is acceptable.

I changed a few things in the attached pdf. The only thing I can see not working is not being able to make a request to walk when the light is left light is green and the walk sign is lite.

z32man said:

Thanks for your help, it is OSR with LogixPro.

When I put the OSR inline with the LIM instruction that I need the red light does not come on when the OSR is true. I got around this problem with a bit comparison with when the LIM instruction would be true; probably not acceptable.

Click to expand...

Instead of messing with the rung that controls the red light (it ain't broke), try adding a rung that looks at the red light status, then OSR, to an internal bit address. That bit address will be true for only one scan when the red light is first turned on. So it can be called "Enable Crosswalk Start 1Shot" or something.

Put that bit in series with your "Crosswalk Request" bit then output to the crosswalk light, and seal around the 1shot bit to keep the rung true as long as the red light is on.

z32man said:

I think my biggest concern is if my logic where I used the bit comparison is acceptable.

Click to expand...

Yes and no. The EQU on the timer.acc will work as long as you are certain that the timer will have that exact compare value during the scan. Since your timebase is 0.1 seconds, as long as your scan time is less than or equal to 100ms then it should always work. It would be a problem if your timebase was .01 or .001 seconds and your scan time exceeded that. In that case, the acc value might actually skip the number you're looking for. So, I won't say it's a bad practice to do it like that, but it is not bullet proof, and there are probably better ways.

z32man said:

I changed a few things in the attached pdf. The only thing I can see not working is not being able to make a request to walk when the light is left light is green and the walk sign is lite.

Click to expand...

You should always be able to make a crosswalk request. It should only end when the crosswalk sequence ends. Think about that sentence. I would define that as the crosswalk light going off 1shot.

So, to unseal that request rung, instead of an up transition or a one shot rising, it would technically be a one shot falling or down transition. You will still use the OSR instruction, but the preceding logic would be XIO on the crosswalk light, instead of XIC.

Paul

OkiePC said:

Instead of messing with the rung that controls the red light (it ain't broke), try adding a rung that looks at the red light status, then OSR, to an internal bit address. That bit address will be true for only one scan when the red light is first turned on. So it can be called "Enable Crosswalk Start 1Shot" or something.

Paul

Click to expand...

I think I understand everything below this. If I added a rung that looked at the red light status in series with an OSR won't the OSR be true always when the red light is one? And not only true for one scan.

I've tried different combination with OSR and the above mentioned result is what I usually get.


I'm not on a computer with my simulator so I will have to try this later.

Thanks

Based on your description, I am guessing that you may have misunderstood how the OSR works. The bit you assign to the OSR instruction is just for storage of the rung conditions before the instruction. In Allen Bradley PLCs that bit is called the storage bit, and must not be used in any other destructive instructions. A destructive instruction, is one that can change the state of the bit address. These include MOV, OTE, OTL, OTU, and most all other output instructions.

When the PLC encounters the OSR and the preceding logic is false, a "0" is written to the OSR storage bit and the rest of the rung is evaluated as false. (OTE instructions, a.k.a. coil instructions, get a "0" poked into their addresses.)

When the PLC encounters the OSR and the preceding logic is true, and the OSR storage bit is "0", it is set to "1" and then the logic is allowed to pass to the next instruction on the rung or branch (some plcs don't allow the OSR to be within a branch). So, any subsequent output instructions will be executed as true during that scan, meaning the OTE address will get a "1" stuffed into it.

When the scan continues and gets back around to the OSR again, and it finds the storage bit is already "1", then it makes the rest of the rung or branch false.

So, everything after the OSR is only true for one scan, but the storage bit follows the state of the logic preceding the OSR instruction.