One output, multiple conditions

SLC 5/03 with a relay output card.

I have an output that I need to drive with lots of different conditions. First, I tried to put the output coil on each of my rungs, then I read not to do that. I have it set up now where each rung sets the same bit when it comes true, then that bit drives the output. With this setup, when one of the rungs comes true, the output will come on, but when the other comes true, it won't turn the output on. Am I going to have to have a different bit for each rung, then have all of them in parallel to drive the output? If so, that is going to be a major pain because I need this program to be expandable in the future.

Any suggestions would be appreciated.

The reason using the same bit doesn't work is because if the last rung scanned is not true then a 0 is written to that bit so basically the bit will turn on and only when the last rung evaluated is true.

How many places is this used that it is such a major hassle?

One thing you could possibly do is use a different output bit on each rung such as N7:0/0, N7:0/1, etc. Then on the rung with the actual output bit instead of having 10 contacts in parallel you could instead use the NEQ command and with N7:0 NEQ to 0.
Obviously more than 16 different runs would require 2 words i.e. N7:0 and N7:1 and then the rung with your output would have to NEQ's in parallel.

Hope this helps.

I'm not an AB man but my guess is that you can only have ONE coil per output. Use unique internal coils, and OR the contacts from thoes coils to drive the single output.

Or you could...maybe use the master rung set/reset instructions.

Post you logic. If you can print it out to a PDF file and post that for the non-AB guys like me...

wilheldp said:

SLC 5/03 with a relay output card.

... I have it set up now where each rung sets the same bit when it comes true, then that bit drives the output. With this setup, when one of the rungs comes true, the output will come on, but when the other comes true, it won't turn the output on. ..<snip>

Click to expand...

I'm not clear on your problem. Are you saying that's what happening now and it's not what you want or..??

Define your condition in plain english first, translate it into boolean logic, then translate it into ladder. If you can get to the step of just the boolean logic, post it here and we can help you.

hd_coop nailed my problem. I am trying to turn the coil on, then later rungs are turning it back off.

Is it a super-bad thing to have sub-routines driven off of an input? I have a plan...I'll let you know how it works out.

EDIT: I got it working. I just put each condition into a sub-routine and put mutually exclusive conditions on the jump statements. Thanks for the help guys.

oh... the multiple OTE devil...

it's just me.. but I would NOT have multiple OTE even if using Conditional Subroutine. Unless the Subroutine is temporary and used for simulation purposes.

---
I shouldn't be showing this, since this can be dangerous in the wrong hand, but... one can do this in SLC:

(conditons)



    B3:0                               B:10

----] [--------------------------------(L)---

     0                                  0



    B3:0                               B:10

----] [--------------------------------(L)---

     1                                  0



    B3:0                               B:10

----] [--------------------------------(L)---

     2                                  0



    B3:0                               B:10

----] [--------------------------------(L)---

     3                                  0



(The Output Rung)

   B3:10                               O:1

----] [--------------------------------( )---

     0                                  0

(Right after the output Rung)

                                      B3:10

---------------------------------------(U)---

                                        0

someone did that to me once.. for the life of me I could not figure out which condition was turning on the output.

Since you guys helped me out, I'll let you know what I am doing. Some buddies and I are building an automatic bartender. I am putting "recipes" into subroutines, and the condition to jump to the routines is an input from a TCP Quickpanel Jr. Since multiple recipes may call for say, Vodka, I need to drive that output from multiple recipes. I don't have any of it working 100% right now...I was just trying to get a skeleton recipe file, then actually work on the real recipes.

Wil, yes this is a classic PLC issue. I call it the "last rung scanned wins" bug. If it is any comfort after 20 years plus programming PLC's I still commit this error by accident from time to time. When you want multiple conditions to all be able to drive an output there are several ways to approach it.

One way is to ensure that the output address can only ever be scanned once, even though the adddress may be used multiple times in different subroutines in the program. Just ensure only one of those subroutines is ever scanned at any one time.

Another way is to use multiple internal flags, eg B3/0, one for each condition, and then parallel them all together to drive the actual O/P address. This way the no address ever gets used more than once in the program.

I have used both approaches and I much prefer the latter as it easy to confirm that you have got it right with a quick cross-reference to ensure that the address only has one OTE instance. AB allow you to use the same O/P OTE address multiple times in order to allow the programmer more flexibility in how they structure their program, but it comes at the cost of having to be aware of this issue.

Visual example:

does your preventative maintenance routine for your daily checks include sampling?

I have a flag that the Quickpanel sets to select a drink that jumps to the correct subroutine, then I latch another bit in the subroutine that continues to jump to that routine until the recipe is completed. It worked like a charm with the 2 test recipes that I have entered. We'll see how well it works once testing is complete and hundreds of recipes are entered.

That, by the way, is the reason that I didn't want an individual bit for each alcohol from each recipe...there could conceivably be 16!+15!+...+2!+1 recipes. That's a lot of bits.

mordred...We are all looking forward to the "Recipe Testing Phase" where we get to drink our mistakes. It may take several days because our taste buds will eventually not be good for anything.

"Some buddies and I are building an automatic bartender. I am putting "recipes" into subroutines, and the condition to jump to the routines is an input from a TCP Quickpanel Jr."

Now that's a great application!!! Could it be a "self service" bartender?? Take money and make drink. May I suggest a durnk control function like a breathilizer, or a short quiz..

BTW..what about martinis..are you going to shake them or stir them?

It is going to be completely self service. We are going to have the Quickpanel right next to the spout where the drinks come out, so you walk up, pick your poison, and walk away with a drink. We'll probably just have a pack of swizzle sticks next to this contraption so you can stir your own drinks...or you could dispense the martini into a shaker, then pour it into your glass...haven't gotten that far along yet.

This is going in my buddy's personal bar, so there will probably be cover charges for as much as you can drink.

They were planning on doing all of this with PC control, but I thought it would be easier with industrial controls off of eBay. If everything works right, we might try to use Micrologix and a cheaper display to make a production version that doesn't cost a fortune...who knows.

Actually the number of receipes is a lot higher than that. This is assuming you aren't putting the same amount of each alcohol used into a drink. Each alcohol has the possibility of as many states as you can control from none up to the maximum amount (let's hear it for more!).

I think a seperate subroutine for each receipe is a bit wasteful. I would have the receipe in a table of words, each one detailing which alcohol (4 bits) and the amount. When all had been added a 'done' word would occur. That way only one processing area would be used. The complexity would only be in the storage of the 'receipe' words.

But, of course, testing the first attempt very thoroughly is called for before any radical changes. Then, if you can still think, you may wish to consider this different way.

I think a seperate subroutine for each receipe is a bit wasteful. I would have the receipe in a table of words, each one detailing which alcohol (4 bits) and the amount. When all had been added a 'done' word would occur. That way only one processing area would be used. The complexity would only be in the storage of the 'receipe' words.

Click to expand...

What about things like Long Island Iced Tea? The recipe would be several words long.

Having the separate subroutines won't affect the scan time because only one could be run on any given cycle. Adding a recipe adds one run to the main ladder and that's it. It's a lot of cut-and-paste, then a few changes to make a new recipe.

I thought you guys might like this idea!