RSLogix Math help

[brisutterfield 0]

Can anyone help me figure out how to do this? Using RSlogix 5, I need to count the number of total times Integer values N88:0/1, N88:1/1, N88:2/1 all the way through N88:999/1 are high. For example, If N88:0/1 becomes high and later on that day N88:7/1 become high, I need the total to be 2 in another integer word (N65).

[Ken Moore 23]

Can you expand on this a little? You have 1000 words, that you want to monitor the second bit in, and count how many times, these bits go high. What if the a bit goes high, then later goes low, then goes high again, do you count it twice? Is there a time duration? How often do the bits change? Do you need to monitor every word, every scan?

[brisutterfield 0]

The process is a sortation system at a distribution center. Every carton that is introduced onto the sorter receives on Identification # using indirect addressing. Each carton also receives a "reason code" # using indirect addressing. These reason codes are stored in the N88 file. N88:0 through N88:999. The reason codes tell me what happened to the carton and why. Here is an example of several possible results from tracking one carton which has the reason code # of 67...When N88:67/1 becomes high, I then know that the carton did not divert successfully because the takeaway lane was full and could not receive ay more cartons. Or, If N88:67/7 became high, I know the carton diverted successfully. Or if N88:67/3 became high, I know that there was communication errors. In the above example the next carton introduced onto the sortation system would have a reason code # of 68. The reason code would be stored in N88:68. Bit 1 represents the takeaway lane was full. Bit 7 represents the carton diverted successfully. There are actually 9 different bits that could go high to represent what happened to the carton on the sorter. Once the reason codes go to 999 the next carton has the reason code of 0, then 1 and so on. The bits only stay high for 3 seconds. "What if the a bit goes high, then later goes low, then goes high again, do you count it twice?" Yes. "Is there a time duration?" The time duration does not matter. I only need the number of times the bits were high. How often do the bits change?" Of the 1000 words being monitored, anywhere from 1 to 20 of them could be high at the same time. Once they become high they will stay high for 3 seconds. The processor is an Allen Bradley PLC 5/80E

[BobLfoot 301]

Let's get this straight Identification Number is assigned to parcel when it enters the sorter. Reason Code is added to the data table when it exits the Sorter or at what point. You say reason code bit stays hi for three seconds what does the reset? A simple for next loop would let you check all 1000 locations at one "point" in time.

[brisutterfield 0]

"Reason Code is added to the data table when it exits the Sorter or at what point." The identification # is assigned to the carton once it goes through the bar code scanner and is then introduced onto the sorter. The reason code is updated when the carton reaches the point where it is supposed to divert. It either diverts or it doesnt. The reason code is to say it diverted or why if it didnt divert. There are 40 different diverts on this particular sorter. Each divert takes a carton to a different shipping dock door to be loaded on a trailer. You say reason code bit stays hi for three seconds what does the reset? Not sure

[BobLfoot 301]

I am starting to put together a picture now. You must have a tracking array which tracks the Parcel #. I suspect that reason code is reset when the package code reaches the recirculate point on the sorter. A simple indirect address lookup and add instruciton would allow you to count diverted parcels quite efficiently. THis begs the question. Are you the SI trying to change your code or the customer trying to add function to a system you bought? I've spent several years in automation and at one point specialized in sorters and package handling. Am out of that field the last year, but still could recommend a couple of good US firms to work with.

[brisutterfield 0]

I am an electrician employed by a large clothing retailer. I want to be able to diagnose problems and track efficiency of our sorters. I actualy would eventualy like to track all the various reasons why a carton diverted or not (reason codes for each carton). Im just starting with whether or not it diverted. I actually already track and count the # of cartons diverted in each lane by using an add instruction when each divert fires. But I want to be able to do it using the reason codes so eventually I can track all 9 different reason codes that could be assigned to each carton. What instructions are used to make a "for next loop". I could set the trigger to scan every 1 second. Not sure how taxing that would be on the processor though.

[Ken Moore 23]

Just thinking out loud here. It would be much easier to track what ever is setting your reason bit, and a lot less processor intensive. Use what ever logic sets the bit high to index a counting register, at the end of the day, you would have a record of the amount of faults at each of the 9 stations. Just a thought.

[BobLfoot 301]

Okay let's talk Sorter Basics Then. 1. What I am about to say applies to almost every sorter in one form or another. 2. Your sorter has an Entrance. At the entrance your parcel is identified uniquely and in your case assigned a reference # between 1 and 999. 3. Next Every Sorter has some form of Data Tracking method or array. This in PLC5 is usually a bit or integer file which is FIFO'd or COP'd to move Integers as the sorter moves. THis file may contain all the data about the parcel or only it's reference number. 4. If tracking is done by reference number you will then find other integer files which contain the data for that parcel usually index by the reference number. YOu have determined N88 to be sortation history file. There are probably other files holding the bar code and possibly weight. 5. Every Sorter has destinations. You've found the logic to assign sortation result to N88 and added 40 add instruction to your program already. A lot of decisions and math can be done at each destination, but it is not usually the most efficient place. If you are going to do your math at each destination I'd advise writng one math subroutine and calling it from each destination logic section rathe than writing the same code 40 times. 6. Finally every sorter has an Ultimate Exit. Whether this is the recirculaton loop or a catch all divert. Somewhere in time shortly after this Ultimate Exit is usually where Reference Numbers are cleared and Data Tables Initialized. If you can decipher your tracking schema well enough to locate the data in the tracking array just after Ultimate Exit, you need only examine the Reference nUmber reaching this "math analysis point" and process your nine adds on that number. In Conclusion. I see you having 3 options. 1. Add 9 times 40 or 360 add instructions to your program. WHile this might be the easiest to explain and troubleshoot. It is the most difficult to implement and burns up a lot of memory. 2. Convert your 40 existing Adds to JSR's and move the add instruction to a New SBR. Then add eight more adds to that SBR. THis is probably almost as easy to understand as number 1 and only slightly less difficult to implement. 3. Locate the Ultimate Exit or Reset of Tracking for your sorter and write your math logic to act on the parcel or data which was a parcel at that location. This is the best solution for elegance and still being understandable. Hope this helps.