I'm just starting to learn PLC's and Ladder Logic, so be patient - I realize this is pretty basic.

1.) The problem setup is a single conveyor, the conveyor has a motor that can run in two directions: forward (O:2/0) and reverse (O:2/1)
Forward and reverse operation is controlled using two normally-open switches (I:1/0 and I:1/1 respectively). Pushing either button will start the conveyor in the appropriate direction (regardless of its current state). Also, the buttons should not need to be held for the conveyor to remain in motion.
A third normally-closed switch is used to stop the conveyor (I:1/2).
The conveyor motor's reverse and forward coils should NEVER be engaged at the same time.

For this design I'm only allowed to use three basic instructions XIC, XIO, and OTE (No latches, one-shots, etc.)

The attached image shows my setup. Rungs 0 and 2 are the seal-ins for the forward and reverse operation using momentary switches.
Rungs 1 and 3 prevent both motor coils from being engaged at the same time: Rung 1 disengages the reverse coil if the forward coil is engaged, rung 3 disengages the forward coil if the reverse coil is engaged.

The ladder accomplishes the desired results in simulation, but is there an easier/better way to prevent both coils from being engaged at the same time (using only the XIC, XIO and OTE elements)?

2.) Assuming I were alllowed to use the latching instructions, it seems like I could eliminate rungs 1 and 3 completely by just adding OTU instructions in parallel with the OTE instructions on rungs 0 and 3 (i.e. setting one motor output's bit while clearing the opposite motor output's bit.) Is there a reason I wouldn't want to do this?

3.) What would be the typical way to accomplish this task (all instructions being available)?

Thank you,
Zazoo

 

strantor is good at this. You might PM him in case he doesn't see this thread.

 

#1 - you cannot use the same coil twice. Consider your drawing, I push FWD, FWD coil is energized in rung 000, it latches, and as a result it is energized in rung 003 as well and the conveyor is going forward. Now I push REV. This causes the coil in rung 003 to drop out, but the coil in rung 000 is still energized. logic fail, 0 ≠ 1. For this reason, most software won't even let you place the same coil twice, or it will throw fits when you go to compile. What software are you using to draw this ladder?

Your ladder should look more like this:

However, this prevents FWD operation when the REV coil is latched, and vise versa, defeating your requirement of "from any state" (you would have to press stop between direction changes). Are you sure this is a valid requirement? Normally this is not advised, especially on a conveyor. Can you imagine a conveyor full of wine bottles trucking along in one direction at 100 FPM and you instantaneously reverse direction to 100FPM in the opposite direction?

If it's definitely a requirement from the instructor, I'll modify the ladder to suit.

 

I think that you could eliminate rungs 1 & 3 without using OTL & OTU. You could put your XIC instructions in series after your start button instruction. The problems that I see with using this in a real world application is that if someone was to push the reverse button while the motor was in forward motion damage could occur.

The thing about PLC programming and ladder logic is that there really isn't one correct way to accomplish a task, though there may be other more efficient ways. Your method may work and like I stated I would have put the XIC in series with the start buttons, which would also work. Is either method better? Probably not with such a simple program. It would matter when you get into a program whose size is pushing the limits of the PLC memory though, or you have hundreds of rungs the PLC has to scan.

Remember, the PLC scans each line to see what has changed on the inputs. After all the rungs have been checked it changes the outputs as needed. So the less rungs it has to scan, the faster it can change the outputs.

edit: saw strantor came about while I was responding. His drawing shows what I was referring to.

 

#1 - you cannot use the same coil twice.

I didn't know that, thanks.

Consider your drawing, I push FWD, FWD coil is energized in rung 000, it latches, and as a result it is energized in rung 003 as well and the conveyor is going forward. Now I push REV. This causes the coil in rung 003 to drop out, but the coil in rung 000 is still energized. logic fail, 0 ≠ 1. For this reason, most software won't even let you place the same coil twice, or it will throw fits when you go to compile.

Do you know why the no same-coil-twice rule is enforced in software?
From my (very limited) understanding of PLCs (Allen-Bradley), if the coils are just references to bit addresses on the PLC and the rungs are executed sequentially then MOTOR-FWD can never really be in conflict with itself in software. It may be set in one location and then unset somewhere else, but this occurs at two different points during program execution (i.e. it always has a single, well-defined value at every point in the program).

I know I'm obviously thinking about this wrong somewhere, but I lack the perspective to understand where. Any insight you can offer is appreciated.

What software are you using to draw this ladder?

It's a educational/simulation program called LogixPro that the company gave me to play around with prior to starting next week. I have some exercises intended to familiarize new students to PLCs and ladder logic.

However, this prevents FWD operation when the REV coil is latched, and vise versa, defeating your requirement of "from any state" (you would have to press stop between direction changes). Are you sure this is a valid requirement? Normally this is not advised, especially on a conveyor. Can you imagine a conveyor full of wine bottles trucking along in one direction at 100 FPM and you instantaneously reverse direction to 100FPM in the opposite direction?

The exercise was academic. The follow-up exercises asks for a modification that incorporates a delay to avoid abrupt changes in direction. I haven't got that far yet.

 

Do you know why the no same-coil-twice rule is enforced in software?
From my (very limited) understanding of PLCs (Allen-Bradley), if the coils are just references to bit addresses on the PLC and the rungs are executed sequentially then MOTOR-FWD can never really be in conflict with itself in software. It may be set in one location and then unset somewhere else, but this occurs at two different points during program execution (i.e. it always has a single, well-defined value at every point in the program).

Yeah I guess you're right about that, it's not physically wired. But I think they intend you to think of it as being physically wired. Actually Allen Bradley (some, not all) software lets you get away with it, but it's still a big faux pas in the PLC world, as it makes the program a nightmare to monitor. To learn more about how AB software handles it, google "duplicate destructive bit detect"

 

Zazzoo, consider this:

           A             B
000  |----| |------------()---|
           (98 rungs of BS)
           A             B
099  |----|/|------------()---|
100  |------------------(end)-|

This would result in the output B being switched on and off a zillion times per minute. Let's say it's a relay output driving an inductive load. Swift destruction ensured.

By forcing you to use each coil only once, the software will cause you to find yourself changing the code to look more like this:

           A     A       B
000  |----| |---|/|------()---|
           (99 rungs of BS)
100  |------------------(end)-|

... at which point you would realize, "hey, that's pretty stupid. It will never energize"

 

Zazzoo, consider this:
This would result in the output B being switched on and off a zillion times per minute. Let's say it's a relay output driving an inductive load. Swift destruction ensured.

I see your point.
This must have been a misunderstanding on my part. I though the output bits inside the PLC memory were only translated to physical output signals after each complete scan of the ladder (vs. after each scan of a single rung.)

Good to know.

Zazoo

 

you might be right about that too. I'm not sure, I've never been formally educated on PLCs.

 

I went to a A-B PLC-2 school years ago, we were taught that each rung was updated as it was scanned. We had some sample programs that were quite long and we were instructed to do a "contact histogram" on the first rung. That in turn would display the amount of time it took to scan/update the entire program. To do this you must choose an address that is only used once in the whole program. We're using RS Logix 500 now and I've never tried to do a histogram with it, not even sure it's available.

 

The program scans the rungs each one by one and updates the memory, can't remember what it is called exactly. After all the rungs are scanned it updates the outputs. If an input makes O:3/1 true on rung 10, then on rung 23 another input makes O:3/1 false what do you think will happen once all the rungs are scanned and the outputs are updated?

It will stay in the false state.

 

If it's definitely a requirement from the instructor, I'll modify the ladder to suit.

If you wouldn't mind I'd definitely appreciate this.

Thank you,
Zazoo

 

If it's definitely a requirement from the instructor, I'll modify the ladder to suit.

If you wouldn't mind I'd definitely appreciate this.

Thank you,
Zazoo

here you go:

 

strantor's solution is definitely one i would use too (but there are many ways to accomplish this).

for newcomers to PLC, i recommend to snoop (or join) mrplc.com (free forum, not controlled by hardware/software manufacturer). also check download section for code samples, manuals etc.

also recommended is to lookup Ron Beaufort's comments and videos. his job is to train new guys on AB PLCs. for example check this one out:
http://www.youtube.com/watch?v=zlsJxSK8tPE

note: one CAN use coils more than once but it is bad practice because this is usually safest way to make mistake. this is why most programming software has option to warn/prevent such practice.