Sorting an Array with Ladder Logic

[lectropop 0]

Not necessarily AB specific - Has anyone come across (or is clever enough to come up with) a simple way to sort a set of values by size? I have a client who wants to rotate the lead/lag1/lag2/lag3 status of a collection of 32 pumps based on each pump's runtime hours. For example: The operator will call for 5 pumps to lead, 6 to lag1, etc and the PLC will pick the lowest 5 pumps in the list to run as lead, the second 6 to lag1 and on and on. I was thinking of assigning a ranking (1-32) for each pump based on the relative value of each runtime accumulator (a set of 32 float values). So far so good - Except there doesn't appear to be a sort function for the SLC5/05. If my math is correct - using simple greater than/less than functions would take 32+31+30+....+1 = 528 tedious rungs worth of comparisons to sort every possible combination in the list. As there are 4 different operating modes (where the 32 pumps are lumped into smaller groups), this brute-force method seems impractical or at least a PITA. Have I missed something fundamental? Ben

[JRoss 84]

Some PLCs have instructions for this sort of application. If not a sort function, then a MIN or MAX function that will return the index of the appropriate value in an array. However I can't find anything in SLC 5/05 either. You could either brute force it (I would use Excel to generate the rungs quickly) or create a subroutine that does the MAX function and calls it 32 times, moving the found value out of the array into another array each time. Those are probably the two "easiest" approaches that I can think of. Another method I would try is to actually write a sorting routine with indexing and for loops and so on, but I'm not sure it would be worth the effort!

[michael G 2]

You are looking at hours run so do not have to finish in one scan so perform the check over multiple scans Implement a bubble sort in ladder using indirect addressing Pseudo code bubble sort

[Ken Roach 194]

I did a simple bubble sort routine in a MicroLogix 1400 a few weeks ago... I'm doing final testing of the machine tomorrow. I'll extract the basics (mine is actually alphabetical) and post an example. The basic data structure is that you will have an integer array that includes the Pump Numbers, and a Floating Point array that includes the Runtime Hours.

[lectropop 0]

Thanks for the feedback! Very good point about not having to solve the order in one scan. I'm picturing the routine running once a day (or some other relatively large period) so it would be a non issue to use consecutive scans as my for loop. I know I have done sorts many years ago in Java, but was having a hard time trying to adapt nested for loops into ladder code. Ken, I look forward to checking my ideas against your example. Ben

[daba 4]

Sounds to me like you are trying to "balance" the pumps so they all have relatively equal "hours run"... There's several schools of thought on why this may not be a good thing.... 1. When a pump fails, and is replaced, its "hours run" would be reset, and that would mean it was the pump of preference, and would be hammered until it reached the same "hours run" as the others. This may be detrimental to other pumps, which often need to be used regularly to keep seals wet and bearings lubricated etc. 2. Assuming maintenance is required after XXX hours run, they would all come up for maintenance at the same time, leading to a huge asynchronous load on the maintenance people. I prefer an algorithm that simply rotates pump usage, regardless of hours run. In fact I'd even suggest that a deliberate offset is introduced, so that scheduled maintenance is spread over a longer period. It all boils down to WHY the customer wants "hours-run" balancing. If he uses it (genuinely) to perform maintenance on the pumps (very rare in my experience), then my comments above become a factor. If he uses the info to just document the hours-run in case of failure (so he can seek recompense from the pump manufacturer), then why bother to balance the usage at all. I always play devil's advocate when a customer requests this. Most times they just haven't given it the thought it deserves. Here's a scenario to consider.... Suppose that your 32 pumps have to have seals changed at xxxx hours, to comply with manufacturer's warranty, any form of "hours-run" balancing would mean that the seals would have to be changed on all 32 pumps in the same week ! Now imagine the consequence of saying (at startup) that pump1 starts at zero hours, pump2 starts at already having run 168 hours (1 week), pump 3 has already run for 2 weeks etc., etc. This scenario means that you will be changing seals early for all but one of the pumps, but you are guaranteed not to fall foul of the manufacturer's warranty conditions, AND you'll keep your maintenance people happy. Of course, I appreciate there are many different reasons for accumulating "hours-run", but in my experience balancing them is often the wrong thing to do : food for further thought....... Edited 24 Dec 2012 by daba