Efficient Way to Detect Large Number of Inputs in Logic

Hello all,

I have to deal with large number of (125+) sort bin doors opening and closing. Each bin door has a open position sensor and a close position sensor. This is similar to a Mail sorting machine in operation (mail sort slots/gates opening and closing), except it's not and this system runs at a snails pace. So I have about 10 to 15 seconds to detect a Bin(s) open/close state before we proceed to the next step in the subrotine to place product in to a particular bin(s). In logic, I would tell the bin to open and wait until I see it's open state sensor to be active, then move on to my next step to place something in this bin(s). While waiting for the bin(s) to finish opening/closing, PLC continues to scan all other subroutines and do it's own thing.

My Issue:

How to detect a bin is opened or closed to set a Flag for each bin when it's ready, but without using timers. I want to be able to detect Success as wel as Failure for a given bin. At times this could be just one or two bins. But at other times, depending on the process involved, logic might be tasked with detecting open/clos/fail status of more than 70 bins at a time within the same subroutine of logic. Using 125+ timers does not look very elegent nor does it appear to be very efficient in my thinking.

Anyone have any Ideas or suggestions on how to go about this?

Thanks All.

EDIT: PLC Platform is Allenbradley Controllogix L55A (Logix 5555PLC)

what type of PLC?

Sorry I forgot to mention the PLC.

It's a control Logix L5555

Take a look at FSC (File Search and Compare) instrution. I think that would be my first option. If you mask inputs into an Array where Input1 = ArrayInput.1 and Mask your command outputs where Output 1 = ArrayOutput.1 Then Compare the the 2 arrays with FSC to see if they are equal or not. The only problem is when to compare.

skyfox said:

Hello all,
Using 125+ timers does not look very elegent nor does it appear to be very efficient in my thinking.

Click to expand...

While not answering your question, I just wanted to throw my 2 cents out there and object to your thinking. There are lots of neat tricks to efficiently write code do to this, but is you back against the wall when it comes to memory? Even with an L55 I bet you aren't using half of it's memory.

When I think of efficiency, I think of dollars, so when it's down and the guy who must maintain it is troubleshooting your timers, is it going to be quicker to do a cross reference and find the 1 of 125 timers that are associated with a particular input, or try to understand a command such as an FSC and follow it through it's loops?

I'd stick to the KISS principle.

TWControls said:

While not answering your question, I just wanted to throw my 2 cents out there and object to your thinking. There are lots of neat tricks to efficiently write code do to this, but is you back against the wall when it comes to memory? Even with an L55 I bet you aren't using half of it's memory.

When I think of efficiency, I think of dollars, so when it's down and the guy who must maintain it is troubleshooting your timers, is it going to be quicker to do a cross reference and find the 1 of 125 timers that are associated with a particular input, or try to understand a command such as an FSC and follow it through it's loops?

I'd stick to the KISS principle.

Click to expand...

+1 "KISS" it and go on.

I have to go with TW Controls. I think that PLC has plenty of memory left. When I was doing consulting work I had an engineer for the customer tell me "I dont want to know how smart you are, I just want to be able to understand what's going on with the code at 2 AM.

If you have a lot of doors that work the same way everytime you could try using an Add-On Instruction (AOI). Make it up one time then all you have to do is assign the Inputs and Outputs to the AOI and all the timers, one shots, holding bits will be internal to the AOI. They will be easy to find for the door you are working with and it will be more organiezed in you tag databases.
AOIs are not for everyone. There area a lot of examples out there, in this case it may be worth you while.

I don't know how you avoid timers, when the very definition of a failure would seem to require at least one per door (I would use two).

Failure Definition (in my mind): If you send the open (or close) command, and the door does not reach the limit switch within a certain amount of time it has failed.

I have some applications in which I omit the timers for things like contactors which usually provide a "proof" contact within a half second, so those will momentarily turn on the "failure" bit for a hlaf second, but I don't seal it in, it's only for visualization, and not a problem to see a blink of an alarm on an object. If I am logging, or latching the alarms, I always use the timers.

If the doors take more than a second or two to travel to the limits, you definitely need the timers.

If you can use AOI, UDTs and indirection to get the job done with less code and still retain the ability to properly locate and monitor each individual door easily, then certainly consider that. If it is confusing or difficult to monitor individual instances, then K.I.S.S. and repeat the same logic 125+ times. I have not had that many instances to deal with, but I have had some situations where I dreaded repeating 50 or so lines of ladder for 48 instances but once I got the grunt work done, it was worthwhile to have plain "normal" code for the next guy to follow.

You'll need Version 16 firmware in your L55 to use AOI's.

One more note on firmware version 16: 16 is as high as you can go on the L55. Later versions are not supported on the L55.

Thank you all,

Appreciate all the help. My concern was effect of scan time when using 125+ timers (250+ if I use one for Open and 1 for close detect) But I think can get by with one timer for both. I also have equivalent number of totalaizers, One per bin, that counts products going in to it. Bins open and close rather slowly, but products move at a rapid pace (approximately 1/per second) that I need to accurately keep count of. Would scan time come back to bite me on totalizing because of the timer overhead or am I worrying about this for nothing. I do have Add-on Instruction capabilty with this PLC.

Thanks again to all of you.

Best Wishes.

I don't think you have to worry too much about scan time, even with 250 timers. The timer has very little overhead. It is is a relatively simple computer instruction that executes quickly - it performs a couple of simple additions and a compare. Whether you use one or two timers per bin isn't going to make much difference. And if you have to adjust the timer preset according to function you'll add more overhead than just using two timers.

When a timer is enabled it stores the system time in the 16 bit LSW of timer.0. On subsequent scans it subtracts the value stored in the LSW of timer.0 from the updated system time and then adds that difference to the .ACC and stores the new system time value in the LSW of timer.0 Then it compares the .ACC to the .PRE and sets .DN and .TT bits accordingly. The time required to do that for 125 timers vs 250 timers is going to be measured in microseconds.

You should be able to get the instruction reference for ver 16 from AB website and calculate the effects of all the timers on scan time.

You can divide up the bin logic from the totalizers and run them in seperate periodic tasks. You could probably run the door logic at a 1 Sec period and still be within your requirements. That would free up a bunch of processor time for the faster totalizer task.

What about using digital alarms on version 16.