Midweek PLC Musings

Alternating Logic

What are we talking about when confronted with the requirement to discuss something that requires alternation? A pair of pumps that operations would like to see switching to somewhat equalize the runtime on each, but also possibly the set of lube-pumps for the most important unit in the plant. What often goes unsaid is the desire for assurance that the backup is ready to respond when the primary one fails. So there we have a couple of concepts already. We need something that defines a Primary and a Secondary (sometimes called the Standby). Then we need, when the logic is started up for the very first time, something that can generate the Primary condition. Hopefully our logic will just let the Secondary follow the Primary, and we don’t have to be concerned about that. Now that we we have this sorted out, we should collect all the conditions that should lead to a pump running. Lets ask:

When do we want a pump to run? Always? As commanded? On high level until the low level is reached? On low pressure? Then, as follow up question: Do we ever want the second pump to start running while the first is still running? More Questions: When do we want the pumps the switch Primary/Secondary roll? At startup? On failure of the first, the Primary? On a fixed time schedule? Here I would like to suggest that it is not a good idea to take a perfectly well running pump, and stop it just to switch roles. System upsets, especially with machinery that is kept running for a long time, usually happen during a change. Much better to change roles at startup.

Ok, by now we have asked enough questions of all those who have an interest in the solution, and have formed a rough outline of the problem, the possibilities, and maybe even got close to a specific solution. Now is the time to look at the input signals that we will need for the desired control actions, and the outputs required to drive the control. Are our pump motors driven by hardwired outputs or a networked MCC? There is a constant struggle at this stage. Those who have previously supplied or worked on solutions of this type will already have jumped in an created an I/O list and the required modules and their locations defined. While those who would broad brush as long as possible, will bristle under those constraints and demand that the solution requires a bit more study. A better outlining of the desired operating modes, more choices for the operators possibly, and then want to select the signal requirements from that point of view. Either side has their points. But if the expedient side always wins, we will never get to improve things. Some flexibility on either side is a welcome break.

Now everyone understands what is desired, and I can see many of you opening up the programming software to get going. How about just one more delay. What we are doing in a large sense is called system design. But so far we have done no design! We have collected information, we have outlined possibilities, collected opinions, have evaluated them (possibly even rated them to weed out conflicting requirements), we have maybe even started building rapport with those who will be involved in the implementation, so the final result will not be a surprise to them (you get bonus points for that). But we really have not done any design yet. And to start programming now would really be a mistake. The design, especially for a rather small solution like an alternating control system will not be a time-consuming nor demanding process. What I’m talking about is possibly a single piece of paper with a pencil sketch, showing the functional blocks (or boxes) that each perform the things you will program. The kind of sketch that you would use to explain to a coworker what you are after, if you could not get to do the rest of the job because you were called away. Thats the design, and it is valuable because you are demonstrating to yourself and others that you are still flexible, able to modify what is required to come up with the best solution, and maybe most important of all - ready for problems. After the sketch is down, you do well to ask "why would this not work". And when you have settled on a final design you have an overview of the whole set of requirements, not just the interesting part of the problem, the challenge. In other words, you have thought about the whole thing, and now have a better more all-encompassing approach. Now it’s time to program.

Do you have a different approach? Let’s hear.