Those of you who regularly read this blog will recall that I have been discussing the details of applying a technique I learned years ago from Chuck McClure that let me use condensate and feedwater pump cycles to assess steam consumption and load profile.
So far, we have discussed how to work with the raw data typical of what you might get from a current technology data logger equipped with a Current Transformer (CT) and how to detect when a pump cycles by using Excel formulas to query the data.
Bear in mind that what I am showing you here is how I happen to go about doing this. Like I said previously, for any given engineering problem, the number of potential (not necessarily workable) solutions is about equal to the number engineers working on it multiplied by a factor of 2 or 3. In other words, if you are looking at this concept and thinking “I wonder why he just didn’t …” it probably means you have an idea that will work too and maybe makes more sense to you, so pursue it. If it doesn’t pan out, you can always come back to how I did it and meanwhile, you may discover a better way. Worst case, you’ll have learned something.
As you saw in the previous post, the technique I used to detect a condensate pump cycle placed a 1 or “On” in a new column in the spreadsheet any time the formula I used saw the pump current fall into a given operating range as illustrated below.
What I know at this point is that the pump was running on the 10th of October, 2009 at 01:54:32 and 01:54:40 pm. I don’t really know when it started or stopped. For instance;
- It literally could have started right at 01:54:32 and shut down a fraction of a second after 01:54:40 pm, which would mean it ran about 16 seconds.
- It could have cycled on a fraction of a second after the 01:54:24 data sample and cycled off a fraction of a second before the 01:54:48 data sample, which would mean it ran nearly 32 seconds.
- It could have cycled in a time frame between the two extremes discussed in the first two bullets.
- It could have cycled off and back on again sometime between 01:54:32 and 01:54:40, which would mean that there were actually two cycles the length of which would be constrained by conditions similar to the first three bullets.
I bring all of this up because its easy to be staring at a data file and take it as fact; all of those numbers only 8 seconds apart; how could it possibly be wrong?
But, what’s actually a fact (assuming the sensors and time stamps were accurate) is what the logger recorded as happening at the exact time it took the sample. What happened in-between samples is really speculation and, if you speculate incorrectly (us older folks speculate rather than guess), you could reach an invalid conclusion. Bottom line is that you need to take trend data with the proverbial grain of salt.
That’s not to say speculation is a bad thing; you’ll likely need to do quite a bit of it, especially in this business. and, your speculation can be informed by judgment or other observations. For instance, I watched the pump for a while when I was deploying the logger (pretty darned exiting I might add) and based on that, knew that it seemed to run at least 12 – 15 seconds when it came on. That’s part of the reason I selected the 8 second sampling time; it would give me at least one or two data points every time the pump cycled. And, the observation allows me to make the reasonable assertion that the pump likely did not cycle off between the data samples.Given all of that, as you may recall from previous posts in the series, there are two ways I could go about figuring out how much condensate the pump moved, which is the key to understanding the steam consumption and load profile.
- One option is to assume the pump operating point is relatively constant since it sees a virtually fixed pressure difference. Making that assumption lets you assess the pump flow rate via a pump curve and pump test and then multiply the flow rate by the time it occurs; i.e. gallons per minute times minutes gives you gallons. If you use this approach, then knowing exactly how long the pump operated is important. In the example we are looking at, the potential error in terms of run time could change our result by a factor of 2 (the pump could have run anywhere between 16 and 32 seconds). So, if I was going to use this technique, to be accurate, I would need to sample much faster given the short pump cycle time.
- The other option is to assume the pump discharges a fixed volume of condensate for each cycle, which is a fairly good assumption for condensate return pumps because they are typically are triggered to start and stop by float switches. This may not be as good of an assumption for feed water pumps serving multiple boilers since they are often triggered by float switches on the boiler and two boilers could have overlapping demand cycles. In other words, the pump could be pumping into one boiler some times and more than one boiler at other times.
Bottom line is the second option may be an undesirable approach for feed water pumps but is usually fine for condensate return pumps assuming you sample fast enough to catch every cycle. Usually, that sampling rate is slower than the rate you would need to paint an accurate picture of the exact run time and apply the first option.
Slower sampling rates mean more time between visits to the logger to retrieve data with out loosing data. Like most engineering enterprises, there are compromises to be assessed and the right answer to selecting the approach for the general case is “it depends” (if you ever take the U of W DDC control class from Jay Santos and Bob Shultz, this phrase will be come a litany).If I assume that the pump didn’t cycle off between the two data points, and assume that I sampled fast enough to catch every cycle with at least one data point, then I know that ever time I see the value in my “Detect Cycles” column transition from “0” to “1”, the pump cycled. If I know the number of pump cycles, I can multiply it by the volume discharged and get my steam consumption for any given time period. But, the trick is that I can’t simply add up the “1”s in the “Detect Cycles” column. That’s because each cycle has the potential to generate more than one “1” if the pump ran more than 8 seconds.So, to figure out how many actual cycles there were, I have to somehow survey the “Detect Cycles” column and note how many times it transitioned. One way to do this is manually; you scan the column and make a tick mark on a little slip of paper each time you notice a transition then add up the tick marks. As you may surmise, this could get a little tedious.
My solution was to add another column and insert a forumla in it to detect a transition in the “Detect Cycles” column. If I go about doing this correctly, the new column will have a “1” (or the word “cycle” or what ever you happened to want) in it each time there is a transition from “0” to “1” (or from “1” to “0”; what you pick may have something to do with your outlook on life) in the “Detect Cycles” column. Here is what that looks like for typical cycle detection along with the formula that accomplished it.
In general terms, the formula says something along the lines of if there is a “0” in the cell immediately above and to the left of me and a “1” in the cell immediately to the left of me, then I just detected a pump start and should give a result of “1”. Otherwise, I should give a result of “0”.As you can see, the formula puts a 1 in its cell only once for every pump cycle, even if the cycle lasted for several data points.
All of this might seem like its complex and time consuming, but the reality is that once you understand the concept, you can create the formulas in one cell and cut and past them to the remaining cells in the column in a matter of minutes, or even seconds.
The next step we will discuss is converting the cycle count to a steam load. Until then (and even after that), I hope everyone’s new year is off to a good start.
Senior Engineer – Facility Dynamics Engineering