Assigning Priority Based on Run Time in CCW

[mnwinter]

Thank you for providing your code.

We've all been there, so I'd like to take a step back. The first two rungs we see are the Start and Stop rungs below*. There are two canonical ways to start and stop a process or sub-process: the Start/Stop Pattern (see this link); and the Set/Reset Pattern (see this link). One reason for using the Start/Stop pattern is that the process should always be put in its stopped state when the PLC mode changes to Run (e.g. after a power failure and recovery). One reason for using the Set/Reset pattern is that the process should be returned to its previous state, started or stopped, when then PLC mode changes to Run.

Looking at your code, it seems that you have confused the two patterns:

View attachment 60020

I am not saying the code does not work as is, but it does mean that your code is more cluttered than it needs to be, certainly on these two rungs and therefore likely elsewhere, which will make adding new features, such as runtime balancing, more difficult.

Also, while there are some comments in the code, it is very brief; it would be helpful for others here, and more so for yourself a few months from now doing diagnostics, if there was more a detail comment on the reason and behavior of each rung. Comments should describe what is happening in the process (e.g. "Switching to manual or pressing Stop button stops the process"); comments do not need to describe the logic instructions (e.g. "XIC of Manual bit or XIC of Stop bit will cause Reset instruction to reset System_1 bit"), because it is assumed the reader can read the logic.

Again, we have all been there I am not trying to embarrass you. But with experience will come a recognition of things like these. Also, it will be difficult to communicate in this forum unless there is more of a common understanding how PLCs work. I strongly suggest you commit to memory at least the Start/Stop pattern and the Set/Reset pattern, and look at the other patterns on that website (see this link). Further, you will benefit from watching Ron Beaufort's excellent bootcamp primer series, comprising less than a dozen videos and taking less than a couple of hours; see this link.

* I removed the XIO Toggle_1/_2/_3 instructions for clarity.

No, I appreciate your comments. This is literally my first PLC program I saw a need at work and wanted the position so I am teaching this all to myself. It sucks not really having a co-worker or someone close who already knows this that I can ask questions to. The program you see is everything I have figured out to do through your guy's response on these forums to youtube and AB manuals. So any time I am doing something that is wrong to industry standards please let me know it is the only way I'll learn I have done something wrong, even if it does work my messed up way.

 

[drbitboy]

No, I appreciate your comments. This is literally my first PLC program I saw a need at work and wanted the position so I am teaching this all to myself. It sucks not really having a co-worker or someone close who already knows this that I can ask questions to. The program you see is everything I have figured out to do through your guy's response on these forums to youtube and AB manuals. So any time I am doing something that is wrong to industry standards please let me know it is the only way I'll learn I have done something wrong, even if it does work my messed up way.

Watch those videos by Ron Beaufort. Watch them again, and until the light comes on.

Would it help to go over your rungs and make comments? I see ways to clean up and/or remove unneeded cruft on quite a few.

Btw, I found where an application like this had been covered on this forum before:

• https://www.plctalk.net/qanda/showthread.php?t=82543

The interesting one is @Lancie1's program in Post #8, which included a fourth standby pump that would come on if one of the other pumps did not.

I made my contribution (https://github.com/drbitboy/PLC_3_pump_sequencing), which is fairly similar to this thread's problem, in the later resurrection of the thread a couple of months ago.

I want to call particular attention to the logic in program file [LAD 234 LEADLAGLAG], where it takes the runtime, auto/manual, and maintenance (disabled), status of each pump to determine the nine BOOLs PUMP_1_IS_LEAD through PUMP_3_IS_LAG2 (_LAG2 in that program is LAG_3 here): Tthe point is that only four of those BOOLs require detailed logic looking at runtimes and such; the other five BOOLs are determined by difference, like a Sudoku.

 

[drbitboy]

Although to be honest, given the earlier comments from experienced folk that balancing runtime may not be the best idea, maybe accumulating runtime at four times the rate in the lead pump relative to the lag_4 pump is a good thing, and all that is needed is a layer of indirection to shift-and-rotate the priority of the pumps by one slot, so e.g. pump 2 become lead_1, pump 3 becomes lag_2, pump 4 becomes lag_3, pump 1 becomes lag_4, and the shift is triggered by the PM reset event.

More generally, the pumps are re-ordered from most runtime to least at each PM reset event, so the pump that comes off reset will become lag_4 because it will have 0 runtime.

 

[JTCat]

Make a Day-of-the-Week AOI and change priority every 24 hours, with the option to manually shift priority if necessary for PM's or equipment failures. It's how I would do it. I am not able to provide any coding assistance with this, but it should be reasonably easy for OP to figure out.