Ron Beaufort
Lifetime Supporting Member
Greetings to all,
One extremely common request on the forum is for a program which will allow a certain number of devices (usually pumps, motors, or fans) to be "sequenced" or "rotated" so that wear and tear can be more evenly spread over all of the available machinery. That particular function isn't too hard to accomplish – especially if only three or four devices are involved. Beyond that, the logic gets somewhat trickier to write. And then invariably comes the additional specification that certain individual devices must be removed from the lineup occasionally for maintenance or other reasons. Gracefully handling that particular requirement is often the most challenging piece of the puzzle.
I've written the program that I've attached below as a foundation for further development and discussion. Basically I've tried to help answer some of the questions posed in the thread linked here:
http://www.plctalk.net/qanda/showthread.php?p=334570&postcount=1
(and in other posts by the same member) but I've also made a genuine effort to keep the project as "open" as possible in hopes that it will be helpful to more people in the future.
Basic program overview:
12 fans are used to cool an industrial process. As the input temperature increases beyond a certain setpoint, the fans are brought into operation one at a time. The greater the difference between the input temperature signal and the desired setpoint, the greater the number of fans which are placed in operation. As the temperature subsequently drops, the fans are "shed" (or turned off) one at a time.
The lineup of fans may be "rotated" (or "sequenced" – or "cycled") in order to achieve approximately equal wear on each fan. This rotation may be based on Day of the Week, Hour of the Day, Total Time in Service, and so forth - whatever is required by the individual application.
When required for maintenance or repairs, etc., individual fans may be marked as "bypassed" and thereby removed from the lineup list. This is done by marking a specific storage bit with a status of one. For most applications, this operation will be done with an operator's or technician's HMI device. Any fan which has been "bypassed" will not be called into operation – and the next fan in the lineup list will automatically compensate by serving as a substitute for the missing fan. Subsequent removal of the "bypass" marker (by putting a zero in the bit) will automatically reinsert the now-serviceable fan back into its normal position in the fan lineup.
To make the project as readable as possible, "Page Title" documentation has been provided to divide the program into separate functional sections. These are:
1. Rotate the fan lineup
2. Calculate the temperature difference
3. Decide how many fans we need to use
4. Make a list of the available (serviceable) fans
5. Assign each available fan to a specific control bit
6. Drive the field output devices on and off
This general programming approach is often referred to as "abstracting the ideas" – as opposed to the brute force method of "controlling the field outputs" rung-by-rung and branch-by-branch. Once a programmer becomes used to thinking along these "abstract" lines, programs which would normally be extremely complicated to write may be broken down into more easily manageable sections. You'll probably notice how simple all of the various rungs look – which consequently makes it much easier to describe the program flow with detailed rung comments.
Note that this program makes use of Indirect Addressing at both the "word" and at the "bit" levels. If you're not familiar with these concepts, the following RSLogix500 tips might help you understand and interpret the program logic.
From the RSLogix main menu select View/Properties/Comments. Experiment with the various selections for "Symbols" settings. Some selections work better than others depending on whether you're trying to get an "overview" or a "detailed" look at what's going on. Be prepared to switch between the various settings from time to time.
Also - from the RSLogix main menu select View/Properties/Address Display. Experiment with the "Display Value for Indirect Address" checkbox. You should also try "floating" your mouse (and holding it still) over various addresses in the program listing. The "Tool Tip" which pops up will often contain very helpful information.
Notice that a couple of "Custom Data Monitors" have been provided to make it easier to visualize the layout of the "bypass" bits contained in word B3:2 – and also the layouts of the "lineup" and the "available" files. A separate figure has been attached to this post to show an example of how these files are arranged.
Please keep in mind that this program has been developed not only as a basic foundation for a useful project – but also as an example for teaching purposes. In some cases the code could certainly be "tightened up" and the primary objectives might be accomplished with (for example) fewer rungs. In deciding upon the layout, I have tried to keep the main "flow" of the logic as straightforward as possible – mainly to allow for the easiest interpretation of the concepts involved. Another consideration has been to make future program modifications as easy as possible. I've also tried to stay away from certain "advanced" techniques in order to make the project as "portable" as possible between different types of processors.
For a simpler approach (which doesn't use Indirect Addressing) you might want to take a look at a program that I wrote some time ago. You'll find it at this link:
http://www.plctalk.net/qanda/showthread.php?p=65066&postcount=39
For people who don't have access to RSLogix500, a PDF printout of the VACPUMPS program is provided here:
http://www.plctalk.net/qanda/showthread.php?p=226769&postcount=61
Notice that only three devices are required in that older program – so the logic could be handled reasonably well without resorting to Recursive Loops and Indirect Addressing. On the other hand, handling 12 devices gets a little cumbersome without using some extra "tricks of the trade".
Finally, if you're really "into" this type of stuff, then absolutely the best way to get a handle on it is to simply load the program into a spare processor and experiment with how it works. I hope that you will find this material useful.
One extremely common request on the forum is for a program which will allow a certain number of devices (usually pumps, motors, or fans) to be "sequenced" or "rotated" so that wear and tear can be more evenly spread over all of the available machinery. That particular function isn't too hard to accomplish – especially if only three or four devices are involved. Beyond that, the logic gets somewhat trickier to write. And then invariably comes the additional specification that certain individual devices must be removed from the lineup occasionally for maintenance or other reasons. Gracefully handling that particular requirement is often the most challenging piece of the puzzle.
I've written the program that I've attached below as a foundation for further development and discussion. Basically I've tried to help answer some of the questions posed in the thread linked here:
http://www.plctalk.net/qanda/showthread.php?p=334570&postcount=1
(and in other posts by the same member) but I've also made a genuine effort to keep the project as "open" as possible in hopes that it will be helpful to more people in the future.
Basic program overview:
12 fans are used to cool an industrial process. As the input temperature increases beyond a certain setpoint, the fans are brought into operation one at a time. The greater the difference between the input temperature signal and the desired setpoint, the greater the number of fans which are placed in operation. As the temperature subsequently drops, the fans are "shed" (or turned off) one at a time.
The lineup of fans may be "rotated" (or "sequenced" – or "cycled") in order to achieve approximately equal wear on each fan. This rotation may be based on Day of the Week, Hour of the Day, Total Time in Service, and so forth - whatever is required by the individual application.
When required for maintenance or repairs, etc., individual fans may be marked as "bypassed" and thereby removed from the lineup list. This is done by marking a specific storage bit with a status of one. For most applications, this operation will be done with an operator's or technician's HMI device. Any fan which has been "bypassed" will not be called into operation – and the next fan in the lineup list will automatically compensate by serving as a substitute for the missing fan. Subsequent removal of the "bypass" marker (by putting a zero in the bit) will automatically reinsert the now-serviceable fan back into its normal position in the fan lineup.
To make the project as readable as possible, "Page Title" documentation has been provided to divide the program into separate functional sections. These are:
1. Rotate the fan lineup
2. Calculate the temperature difference
3. Decide how many fans we need to use
4. Make a list of the available (serviceable) fans
5. Assign each available fan to a specific control bit
6. Drive the field output devices on and off
This general programming approach is often referred to as "abstracting the ideas" – as opposed to the brute force method of "controlling the field outputs" rung-by-rung and branch-by-branch. Once a programmer becomes used to thinking along these "abstract" lines, programs which would normally be extremely complicated to write may be broken down into more easily manageable sections. You'll probably notice how simple all of the various rungs look – which consequently makes it much easier to describe the program flow with detailed rung comments.
Note that this program makes use of Indirect Addressing at both the "word" and at the "bit" levels. If you're not familiar with these concepts, the following RSLogix500 tips might help you understand and interpret the program logic.
From the RSLogix main menu select View/Properties/Comments. Experiment with the various selections for "Symbols" settings. Some selections work better than others depending on whether you're trying to get an "overview" or a "detailed" look at what's going on. Be prepared to switch between the various settings from time to time.
Also - from the RSLogix main menu select View/Properties/Address Display. Experiment with the "Display Value for Indirect Address" checkbox. You should also try "floating" your mouse (and holding it still) over various addresses in the program listing. The "Tool Tip" which pops up will often contain very helpful information.
Notice that a couple of "Custom Data Monitors" have been provided to make it easier to visualize the layout of the "bypass" bits contained in word B3:2 – and also the layouts of the "lineup" and the "available" files. A separate figure has been attached to this post to show an example of how these files are arranged.
Please keep in mind that this program has been developed not only as a basic foundation for a useful project – but also as an example for teaching purposes. In some cases the code could certainly be "tightened up" and the primary objectives might be accomplished with (for example) fewer rungs. In deciding upon the layout, I have tried to keep the main "flow" of the logic as straightforward as possible – mainly to allow for the easiest interpretation of the concepts involved. Another consideration has been to make future program modifications as easy as possible. I've also tried to stay away from certain "advanced" techniques in order to make the project as "portable" as possible between different types of processors.
For a simpler approach (which doesn't use Indirect Addressing) you might want to take a look at a program that I wrote some time ago. You'll find it at this link:
http://www.plctalk.net/qanda/showthread.php?p=65066&postcount=39
For people who don't have access to RSLogix500, a PDF printout of the VACPUMPS program is provided here:
http://www.plctalk.net/qanda/showthread.php?p=226769&postcount=61
Notice that only three devices are required in that older program – so the logic could be handled reasonably well without resorting to Recursive Loops and Indirect Addressing. On the other hand, handling 12 devices gets a little cumbersome without using some extra "tricks of the trade".
Finally, if you're really "into" this type of stuff, then absolutely the best way to get a handle on it is to simply load the program into a spare processor and experiment with how it works. I hope that you will find this material useful.