8 boiler lead lag system HELPPP plz !!

Join Date
Mar 2016
Location
Chicago, Il
Posts
5
Hi all,

I'm new to plctalk (this is my first post actually ). Anyway I am trying to program a micrologix 1400 plc using RS logix 500 . The scope of the project is to have 8 boilers available to run. 2 are the leads , ( minimum of 2 on at all times ) and there are 6 available lags to be called on in case any one of the 2 leads fall under a setpoint ( lag setpoint cycle on ) for x amount of minutes, the lags will cycle off as necessary when they reach a setpoint ( lag setpoint cycle off ) . Now here is the kicker All 8 boilers need to fault sequence as well all the while acting as leads and lags.
lead lag logic looks as follows,if lead 1 or lead 2 fall under setpoint, call on lag 1, if lag 1 falls under setpoint , call on lag 2 ..and so on and so on.
Iv'e had a couple of gos at it, but to no result. It seems like I keep chasing my tail, every time I get close to a solution it all falls apart o_O. Any help would be greatly appreciate it !!

Cheers !!
 
Two basic approaches:
1. One boiler (the modulating boiler) varies its firing rate in response to changes in demand. When the modulating boiler reaches a high value it calls for the first lag boiler to start up. When the modulating boiler reaches its maximum firing rate it lets the first lag boiler become the modulating boiler.
2. All boilers in service vary their firing rates in response to changes in demand. When they reach some high firing rate, add the next lag boiler. If the firing rate falls below some low value, drop out one boiler.

Are all boilers the same size?
Do you have a sensor to detect demand or are you trying to maintain a header pressure?
 
Steve ,
Thanks for The reply the boilers try to maintain header pressure and all receive the same firing rate based of that header pressure. I am reading each boilers " load output ," and basing The lag call on setpoints on That. So far I was able to come up with 8 diferent sequencing The boilers could be at anytime boilers 1,2,3,4,5,6,7,8 are lead 1 lead 2 lag 1 lag 2 lag 3 lag 4 lag 5 lag 6 respectively OR boilers -,2,3,4,5,6,7,8 are lag 6, lead 1, lead 2, lag 1 , lag 2, lag 3, lag 4, lag 5, lag 6 etc until all possible boiler sequences are filled . That portion of my Logic works fine meaning That i Can cycle The boilers so That each State ( lead 1, lead 2, lag 1) Can be files by any boiler, the problem is that when I cycle the positions and boilers are in fault ( Deffined by a bit ), my Logic will try to call on boilers that are in alarm , so eventually if i cycle positions to were any of The boilers That are ment to be on are in alarm , my logic won't check for the next available boiler. So if boilers 1 and 2 are lead 1 and lead 2 and boiler 1 and 2 are in alarm when they cycle into those positions , they will stay there and not look for the next available boilers...
 
Here's a tip. Instead of identifying your boilers by number, use some other ID scheme, letters for example.
That's because you also need to maintain a table of boiler IDs in priority order. Whenever the header pressure is below the setpoint for a period of time you need to tell the next boiler in the priority list to come online. If you identify the boilers by number it gets confusing when boiler #3 is boiler #5 on the priority list. Easier if boiler "C" is #5.
To your point about the alarm state of a boiler, if a boiler that is currently contributing steam to the header shuts down on alarm, that should immediately trigger the next boiler in the priority list to come online. Don't wait for the header pressure to drop.

PS:
HeroControlsInc, check your private messages. I left you contact information in case you want to talk person-to-person.
 
Assuming the logic for each boiler is in its own Block of Logic.
Maybe think about maintaining two FIFO stacks, One with the StandbyBoilers with six positions and another with just two positions for the LeadBoilers. These are variables with indirects pointing to the variable calling the proper Block of control as needed.

Not sure I stated this correctly but I can "see" it.
 
Everyone ,

Thank you for all the great feedback. I got it to work eventually with a little bit of trial and error and pure Luck haha. I did it the old fashioned way though with pure plug and chug logic, compare, equals etc... seems like WAY too much logic then necessary, but it works. I was hesitant to use load , unload and more intricate commands as i am unfamiliar with them. Any one have any decent links or sites to get a quick practical overview of those types of commands... ??

Thanks Again
 
I see that you found a solution to your problem, but I figured I’d post since this seems to come up often in the forms.

Your issue is you have X number of boilers that you need to alternate and you need to do so in such a way that if a boiler is faulted that you don’t try to use that boiler, but instead move on to the next boiler. Here’s an example that I use for pumps that you can apply.

First, I break up my logic into separate programs. I have a program for my Request logic, this is generally part of my Tank program because that’s the object that needs water. I have separate programs for each of my pumps. And I have a program for the Alternator.

Each pump program has a rung that determines if that pump is Available. In my case that rung is – If pump’s HOA is in Auto, and pump is not in Alarm, and pump is not RemoteDisable then pump is Available. RemoteDisable comes from some other logic in the program, it is used to say no matter what don’t run this pump, it is generally used for low level lock-outs and such.

On to the Alternator program. Basically you use counters to determine which pumps (or boilers) to use. There is a counter for each request, so if you have a Lead and Lag request then you need two counters. If you have a Lead, Lead2, Lag, Lag2, Lag3, Lag4, Lag5, and Lag6 then you would use 8 counters. From there we have logic to determine when to increment the counters and logic to determine which pump(s) the Alternator is calling for. The Alternator program is broken down into sections; counters section, increment delays section, increments sections, and pump requests sections.

Here’s the AlternateDelay and counters rungs. I alternate the Alternator 60 seconds after there is no Lead request, this prevents a quick Lead request going Off then back On from causing the Alternator from alternating all the pumps. I also “lock in” the other counters used for the lag pumps at this time. I say “lock in” because once the Lead counter is set, all the other Lag counters are also set. I continue to use the same Lag pumps as long as the Lead request is active, I do not alternate the Lag pumps when the Lag request turns on and off. I also say “lock in” because if a pump becomes not Available, the Alternator will switch the counters which is shown in the logic below. You might be asking why is the UP rung on the AltLag and AltLag2 counters turned off, how do they change then? Those counters’ values are changed with Increment statements below, they are use more as a value holding location. Then why bother using a counter at all? Because it’s one rung that is used to hold a value and reset the value at a preset.
Alternator1.jpg

Here’s the number of pumps available and increment delay rungs. The MATH statement is used to determine the number of pumps available. This is used to determine if it’s ok to increment a counter, if you have 8 counters but only 7 available pumps then there’s no need to increment the 8th counter since there’s no pump available for it to use anyways. The increment pump delay timers are used to delay the changing of the counters. If the Alternator is running Pump 1 and it becomes not Available, then I don’t want to immediately start the next available pump, I want the Alternator to delay grabbing the next available pump.
Alternator2.jpg

Lead Counter Increment rung. This rung says - If at least one pump is available, and if PumpX is not Available (IncrementDelayTimer.Done) and the Lead counter is asking for PumpX then Increment the Lead counter. So what’s happening is, in the top of the program we use the Lead request to increment the Lead counter (normal Lead request on and off), this rung here is used to increment the Lead counter if it is on a pump that is not Available.
Alternator3.jpg

Lag Counter Increment rung. Remember in the first image where all the Lag counter’s UP rungs were turned off, well this is how the Lag counter’s values changes. Here we say – If at least two pumps are available, and if PumpX is not Available and the Lag counter is asking for PumpX then Increment the Lag counter. The last part of the OR is how the Lag counter usually changes to the next pump, it says if the Lag counter is on the same pump as the Lead counter then increment the Lag counter. So, under normal situations (all pumps are available) what happens is the Lead request increments the Lead counter on rung 3 to say pump 1, when we get to this rung and the Lag counter is on pump 1 then the Lag counter will get incremented to pump 2.
Alternator4.jpg

Lag 2 Counter Increment rung. This is very similar to the Lag Counter Increment rung except for two things. 1) We check to make sure that there are at least 3 pumps available to use and 2) there’s an additional rung in the OR which checks to make sure the Lag 2 counter isn’t asking for the same pump as the Lag counter. So back to the under normal situations, the Lead request increment the Lead counter on rung 3 to say pump 1, the Lag Counter Increment rung will increment the Lag counter to pump 2 and this rung will increment the Lag 2 counter to pump 3.
Alternator5.jpg
 
And finally the Alternator request pump logic. There’s a rung for each pump and we basically say, if there is a Lead request and the Lead counter is on pump 1 OR if there is a Lag request and the Lag counter is on pump 1 OR if there is a Lag 2 request and the Lag 2 counter is on pump 1 OR etc. then run pump 1.
Alternator6.jpg

So there’s a pretty simple Alternator program that is easily expandable to however many requests or pumps you have. It’s broken down into easy to understand sections; counters section, increment delays section, increments section, and pump requests section. And it’ll only use pumps that are Available, skipping those that are not.

Here’s one interesting thing about this Alternator program, if it goes out of sync it’ll sync itself back up. Let’s say the Alternator is set to run pumps 1, 2, 3 and pump 2 becomes unAvailable, then the Alternator will set itself to run pumps 1, 3, 4. The Alternator program will always sync itself back up to running consecutive pumps when they are available. It might take one complete rotation of the Lead counter to get everything back in sync, but it’ll sync back up
 

Similar Topics

Hi Everyone, Question regarding Boiler Controls , if anyone would like to chime in. I work for a Boiler OEM where we manufacturer our own...
Replies
2
Views
2,006
Just looking for some advice here... We're just about to commission two new boilers. Both are equipped with Rielo burners and Siemens...
Replies
1
Views
2,681
J
I have recently set up an Automation Direct DL06-AR controller to alternate the operation of two boilers. I'm using the controllers analog...
Replies
1
Views
7,291
Hello, I have problem i'm working on boiler plc, but i get to the problem that i can't solve myself. I have problem with material gate. I need to...
Replies
2
Views
335
HI All : We have a boiler that can produce up to 75000 lb/hour, this boiler has two CompactLogix Plcs from Allen Bradley , one is used for burner...
Replies
10
Views
3,854
Back
Top Bottom