One of the more popular posts I have done, based on the WordPress statistics, is the string that starts with a post titled Assessing Steam Consumption with an Alarm Clock where-in a share a technique Chuck McClure (a mentor and the founder of McClure Engineering) taught me that literally used an alarm clock but which I now replicate using a data logger.
The technique is based on the concept that each time a condensate pump cycles, a known quantity of condensate is discharged. So, if you count the cycles, then you know how much condensate (condensed steam) is being handled by the pump. That, in turn, lets you understand steam consumption and the load profile for a facility, assuming minimal steam and condensate leakage and not much steam is being used directly in a process.
By doing the same thing to the feedwater pumps, you can figure out pretty exactly how much steam goes out of the plant (minus the blowdown). So if you log feedwater pumps and condensate pumps, you can start to paint a pretty good picture of where and how big the loads are (with the granularity of the analysis related to how many condensate pumps you have to monitor). You can also figure out how much steam you are loosing to direct injection processes and leaks (the difference between the goes-outa’s from the loads, represented by the condensate pumps and the goes-inta’s represented by the feed water pumps).
One of the issues that comes up when you are using this technique is that you have to be logging data faster than a typical pump cycle, otherwise you will miss cycles and be mislead in your analysis.
Pump Cycles and Data Logger Memory
Frequently, a condensate pump cycle can be very short, perhaps 5-10 seconds of run time followed by a much longer off time. This is often because the pumps have been generously sized for the maximum steam load that is ever anticipated and we seldom if ever see that condition in a real building.
The need to capture a short on cycle (i.e. sample faster than the shortest anticipated cycle time) can use up the memory in a data logger pretty quickly. For instance, if you were logging data every 5 seconds (to be sure you captured a pump cycle that would typically be 10 – 15 seconds long) with a Hobo U12 series logger and were only using one channel you would fill up the available memory (nominally 43,000 samples) in just a little over a day.
That means that you would have to return to the site and pull the data out and re-launch the logger pretty frequently if you wanted to capture a week or two of operation. Not a problem if your office is on the site, but a significant problem if your office is in Southern California or Portland, Oregon and the site is in Berkeley, California and you have no other need to be there for a week or two.
Spending Money on Data Loggers to Save Money on Travel Costs
Thus, I had always thought that my little alarm clock technique was best suited for implementation when I would be on site for a couple of weeks. Otherwise the travel costs to simply retrieve data could become cost prohibitive. Or, so I thought until the light bulb came on the other day when Gary Kawabuchi (one of our senior field engineers) and I were faced with just such a problem in an effort to validate a steam meter.
The solution seems obvious in hindsight; what we realized is that you can solve the problem by deploying multiple loggers measuring the same thing and set them up with delayed starts so that one starts logging right about the time the one ahead of it runs out of data space.
Figuring Out How Many Loggers You Need
Right after Gary and I wander off in our separate directions to bask in the glory of our brilliance, my cell phone rang. It was Gary, with a really good question; Exactly how do I figure out how many loggers I will need?
If you have a logger and the associated software, this is not hard to answer. You just plug the logger into your computer and do a psuedo launch. In the course of that process, the software tells you how long the logger will take to fill up given the number of sensors and the sampling frequency you have set up.
Here is what that looks like for one of my U12 loggers set up to log one channel with a 20 amp CT connected to it once every 5 seconds, which will fill up memory in 2-1/2 days.
Here is what an H8 logger (older with less memory) would do with the same set-up.
Gary and I figure that for our project, if we logged condensate pump motor current every 5 seconds, we will capture a 15 second pump cycle. By deploying three, Onset U12 loggers on our condensate pumps, each with one active channel measuring pump current every 5 seconds and set one logger to start just about the time the logger ahead of it in the sequence runs out of memory, then we could get over a week of data with 3 loggers, and over two weeks with 6 loggers. Pretty cool.
A Tool To Help if You Don’t Have A Logger To Experiment With
Gary’s problem was that he didn’t have any loggers handy to plug into his laptop. They were all up on the site doing other things. So he called me to ask if I had any sitting around that I could plug in and play with.
Bottom line was he wanted to be sure that when he showed up on site next week, he had enough logger to do our meter validation. If he didn’t. He wanted to get a few ordered so they would be there when he arrived.
For under $200 with a CT, buying a couple more that we could then use on other projects was still a lot more financially attractive than having Gary make a trip to the Bay Area from Southern California every couple of days to retrieve logger data when we don’t have much else going on up there.
I was getting ready to plug a couple in and answer the question when I realized that there was a pretty specific relationship between the number of samples a logger can hold and the sampling rate and number of sensors you were monitoring. So, rather than answer the specific question, I built a little spreadsheet that answered the general question.
For most loggers, at least the ones I have been around, how long they will take to fill up memory is basically equal to the number of samples they will hold multiplied by the sampling interval and divided by the number of channels of data you are measuring. So, if you had a logger that could hold 100 samples and you were sampling 1 data channel every 2 minutes, it would take 200 minutes to fill up memory.
That’s a mathematical relationship and spreadsheets are really good at math. So, I built a little spreadsheet that showed the durations for all of the standard logging intervals for a U12 logger with from 1 to 5 of channels active (some U12s support 4 channels and also can log the battery voltage).
The spreadsheet also has two other tools built into it. One lets you calculate the duration for aU12 logger with a custom sampling time and any number of sensors.
The other tool lets you do the same for any logger provided that you know how many samples it can hold and that the memory is allocated uniformly between all active channels. I included a table with the amount of samples most of the loggers we use at FDE can hold to make it easy to use.
I spot checked it against what the logger software predicts (Boxcar for the H8s and Hobowarefor the U12s) when you plug in a logger and launch it and it looks like my spreadsheet is pretty accurate. And if not perfect, it’s conservative if you round down to a whole number of days or hours. Specifically, the logger software says a logger will last a bit longer than the math predicts. But this only seems to come up if you enable battery logging, otherwise the spreadsheet prediction seems to be perfectly accurate.
I’ve put a copy of the spreadsheet in a public folder in my Google Documents account if you want to download a copy and use it as a starting point for your own tool.
Another Way to Save on Travel Costs
Onset makes a cool tool that you can use with their loggers called a Data Shuttle. Here is a picture of the ones I have, which I use with my Onset loggers; the one on the left is the shuttle that is used with the older H8 loggers while the one on the right is used with the more current U12 loggers.
Normally, to retrieve data from a logger, you have to hook it up to your computer, run the proprietary logger software, access the logger memory, remove your data, clear the memory, and restart the logger. So, you either have to go gather up all of your loggers and then put them back, or carry your laptop around with you in the field, tempting you to balance it somehow on a ceiling tile while you stand on a ladder and plug it into the logger on the AHU mounted 3-4 feet above you.
You can probably envision the potential disaster that might ensue. I have not personally had that happen, but I would bet more than one laptop has taken a tumble from the top of a ladder under such circumstances. And I have a friend who left a person shaped hole in a suspended ceiling when he leaned over a little too far to take a measurement.
Shuttles solve the danger to life, limb, and property” problem. Specifically, you can plug a data shuttle into a logger and a little internal subroutine automatically:
- Establishes communications with the logger,
- Checks the battery and gives you the chance to change it if you need to,
- Copies the contents of the logger memory to the shuttle memory,
- Clears the logger memory, and
- Re-launches the logger
When you plug the shuttle into your computer, the process is reversed, depositing the data on your hard drive and setting up the shuttle for another round of data retrieval.
This means that someone with a map of where the loggers are located and a bit of basic training (along the lines of “plug this in here and then wait until the lights stop flashing, then go to the next logger”) can retrieve data. Or, you can do it with out endangering yourself and your laptop, at least not quite as much (you don’t have to be retrieving logger data to fall off a ladder).
The other cool thing is that data shuttles are light and durable, meaning you can mail them. I have logged data for months at a time by:
- Visiting a site once to deploy the loggers ,
- Showing the staff how to use a shuttle,
- Giving the staff a map of where the loggers are located
- Doing a quick tour of the logger locations and practice round with the staff,
- Telling the staff how often they needed to retrieve data,
- Leaving a prepaid, self addressed envelope big enough for the shuttles with the staff,
- Calling to remind them to gather data,
- Having them send the shuttles back in the envelope after they filled up, and
- Sending the shuttles back with another prepaid envelope and repeating the process
My shuttles can hold about 64 loggers worth of data. So, I just have the folks at the remote site send them back well in advance of that point; better safe than sorry. And, unless you are sampling really fast, you can usually use the less costly express (2-3 day) or ground shipping and have time to spare.
Using a logger to detect pump cycles vs. pump run time is slightly different. If you only need to detect pump cycles, then you just need to sample fast enough to know that the pump has come on (transition from no amps to full load amps) and then shut down (transition from full load amps to no-load amps). As long as your sampling interval is shorter than the pump cycle, you will pick that up.
In contrast, if you want to figure out exactly how long a pump has run, you need to sample much more frequently. I think I recall doing an exercise when I took differential equations that proved you probably needed to sample a process 5-6 times faster than its cycle frequency to begin to paint an accurate picture of it.
So, if you were trying to understand how long a pump was running and it had a cycle time of 10 seconds on and 60 seconds off, if you sampled once every 9 seconds, you would know that it ran, but you really wouldn’t know if the cycle time was, for instance:
- Less than 9 seconds (the pump cycled between the times you took readings and was not running when you sampled)
- Exactly 9 seconds (you consistently sample somewhere in the pump operating cycle), or
- Somewhere between 9 and 18 seconds (the pump came on exactly when you sampled the first time and kept running until right after the second sample)
So, you easily could be off by 8 or 9 seconds. In contrast, if you sampled every second, your window of uncertainty is significantly decreased. But the logger memory memory requirement is significantly increased and the deployment time for a given logger with a given amount of memory is decreased.
The alarm clock method I discuss can be accomplished by simply detecting cycles accurately since you associated a fixed volume of condensate with each pump cycle. It assumes all pump cycles are about the same length and discharge the same volume of condensate, which is reasonable but has some assumptions embedded in it including:
- Pump performance is fairly constant: this is reasonable in most cases since your window is likely a couple of weeks to a month and the pump is unlikely to experience significant wear in that time frame. and if you are pumping from a receiver to a vented return, the pump head is fairly constant, meaning the operating point on the curve will not shift and the volumetric flow rate will be constant.
- Only one pump operates per cycle: this is reasonable but, if you did not observe the cycles and set the logging interval based on a period of heavy load, then you may have missed the fact that two pumps sometimes operate. And/or, if the pumps are equipped with an alternator that switches the lead pump and you are logging current to one pump, not the assembly, you may miss ever-other cycle. You can protect yourself from error in this case by simply logging both pumps.
- The level switches that control pump operation are repeatable: Since the level switches trigger the pump cycle and the level change and receiver cross-sectional area are what sets the volume used to calculate the condensate flow rate as a function of pump cycles, the repeatability of the level switches comes into play in determining the over-all accuracy of the approach.
- Condensed steam is the only source of water entering the pump reciever: Frequently, steam is used to generate hot water in a heat exchanger. If the heat exchanger develops a tube leak and the pressure in the water system is higher than the pressure in the heat exchanger (fairly likely), then water from the system served exits the heat exchanger along with the condensate and becomes part of the flow measured by the pumps.
- There is a check valve on the discharge of the pump: This is subtle, but Gary and I just saw it on a job. Specifically, the discharge from the condensate pumps was up-hill for a significant distance and there was not a check valve on the pump discharge. As a result, the pump would operate to the point where it lowered the level in the receiver to the point where it would shut down the pump. But since there was no check valve, when the pump shut down, condensate that was in the up-hill portion of the piping would drain back through the pump, filling the receiver much more quickly that would other wise be the case. This meant that the pumps cycled continuously, even if there was absolutely no condensate entering the reciever from the steam system loads and created the impression of a high steam consumption rate that simply did not exist.
Learning More about Data Loggers
I have been talking a lot about Onset loggers, mostly because that is what I happen to use. But most of these ideas apply to just about any piece of data logging hardware and there are a lot of devices out there, each with its own unique capabilities. If you want to get a feel for what’s around, the Tool Lending Library catalog at the Pacific Energy Center is a great way to see what’s available.
There are many manufacturers represented and the library is fully searchable.
When you find what you are looking for, generally there are some pretty detailed specification as well as links to the manufacturers web site and manuals.
And, better yet, if you live or are working in the California Public Utility service territory, you can borrow anything in the library at no cost, just by filling out a form and then showing up to pick up your tools and receive a bit of training in how to use them.
And, you couldn’t ask to work with a nicer, more knowledgable group of people than the lending library staff.
Happy data logging!
Senior Engineer – Facility Dynamics Engineering