Letters to the editor
This letter is in regard to “Hvacr Designer Tips” by Amanda McKew that appeared in the April 1998 issue of Engineered Systems (page 38).
The column featured end suction pumps, and a butterfly valve with memory stop for balancing purposes was included in the diagram. My comment is that most of these balancing devices need straight pipes lengths before and after the valve, according to manufacturers’ recommendations. This should be shown on the drawings so the installer is aware of this, because otherwise it will not render it functional.
Milton D. Blake
Republic of Panama
Open protocol dilemmas
This letter is in regard to “Getting To The BAS point (and Counterpoint),” in the August 2000 issue of Engineered Systems, page 48.
I applaud your magazine, and specifically Joanna Turpin, for what I hope is the first of many discussions on “open protocol.” It was thought several years ago that the BACnet specification and the LonWorks protocol would find their own way, into their own corners. Time has proven this not to be true.
I find the quantity and quality of companies afraid to polarize themselves with one technology over another interesting. I also find the attitude of those companies that do have the courage to choose interesting as well. One apparent theme that is constantly recurring in the BACnet camp is one of justification. Conversely, one apparent theme constantly recurring in the LonMark camp is one of invitation.
I’m sure time will allow the open specification named BACnet, and the open protocol named Lon Works to coincide in today’s world, and luckily so, it will be the building operators, who, after years of being stuck with proprietary systems and protocol converting gateways, who will ultimately come to appreciate true, open, scalable systems.
Robert J. Stokes
Sales Engineer/Product Research
The evolution of steam unit heaters
I was so pleased to see steam-propelled unit heaters featured in “Back to Basics” (Engineered Systems, July 2000, page 13). I have not seen this type of unit heater since the late 40s and early 50s when I used to specify them for areas with explosive atmospheres. Sometimes we used compressed air propelled, but this would require three piping systems.
I perused the “Back to Basics” detailed drawings, but it seems the designer neglected to show the steam supply and condensate return to the fan motor.
I finally concluded that these were plain steam unit heaters. I guess the good old days are long gone.
You have an excellent publication and even us old codgers still can still learn from “Back to Basics.”
W.J. (Jack) Davis
Owner, Davis Consulting
Freezing problem solved
I notice that steam unit heaters always seem to be built to hang with the coils zigzagging through the casing in a horizontal path (“Back to Basics,” July 2000, page 13). We had a situation where this arrangement, being in a constricted space, froze-up frequently because we were taking in outside air. We solved the problem by using headers at the top and bottom and running the tubes vertically. The traps were afoot below the headers and air vents at appropriate points. No more freeze-ups.
Director, Housing and Public Works
U&FD, DHPW, USMA,
West Point, NY
Great idea. I also like to use the vertical, integral face and bypass steam coils when in outside air ducts. Same concept, only bigger steam load. Thanks for the input.
This letter is in regard to the “Back to Basics” column that appeared in the July issue of Engineered Systems (page 13).
Concerning question 1, should the heating valve be in the open position (no valve) when the unit is off? In case of loss of power there is still steam in the system that can generate heat, etc. The only reason I ask is because most heating valves I have ever put into a system have been normally open.
Design Engineer 1
Siemens Building Technologies – Landis Division
I can’t disagree with you on wanting the steam valve to be normally open in case power is lost. I usually require heating valves to be normally open. In the case of the unit heat and considering that unit heaters are frequently oversized by a factor of 3 to provide quick recovery when a door to the outside is open, I try to be a little more selective as to the normally open and normally closed position. I don’t necessarily want an oversized steam valve opening to an equally oversized heating coil. The design engineer needs to be cognizant of when, where, and why do you specify the fail-safe positions.
Business development success story
This article is in reference to “Tomorrow’s Engineer” by Howard McKew that appeared in the August 200 issue of Engineered Systems (page 106).
I always enjoy your comments on the industry. But in the August issue, you really hit the nail on the head.
I have made a good business from the industrial refrigeration industry because of owners’ and managers’ attitudes that “refrigeration is a necessary evil.” The only direction management gives is “don’t spend money,” “keep it running,” and “keep it cold.” As a result of this inattention, it costs twice as much as it should to own, operate, and maintain their refrigeration over useful life of the system.
When all else fails and the owner’s whole business is in jeopardy, I get called in to save their “bacon.” I am a firm believer in outsourcing large refrigeration requirements. With a professional owning, operating, and maintaining the industrial refrigeration system, it does not cost the owner any more than it is costing him now. And he is rid of a complex technical problem that he does not understand, and can have a reliable, smooth running source of temperatures.
Many of the deep pocket, cash rich, electric utility companies are looking at extending their business into large refrigeration systems. But I suspect that only a few will succeed; mostly because of the inflexibility of delegating authority and responsibility and the human resources problems of finding and paying the right people to run this business.
Industrial refrigeration has been fun and profitable for me because owners and managers look on their refrigeration systems as a very complicated, but to quote you “a necessary evil.”
Owner, Industrial Refrigeration
The continuing BAS debate: On BACnet’s behalf
While it may help to sell magazines, the “war” between BACnet and LON isn’t really much of a battle. On the technology front, BACnet is clearly the superior technology for building automation and control because it incorporates such required features as robust alarming, scheduling, command prioritization, and trending capabilities “out of the box;” is independent of any particular networking technology; and is implementable in devices of all sizes and complexities.
In short, BACnet is a comprehensive, future-oriented, evolving technology with global support: BACnet has recently been translated into Chinese, Japanese, and Korean (nontrivial undertakings), and is likely to be adopted soon as a full-fledged ISO standard with world-wide applicability.
Like the development of BACnet itself these things have all taken time, something that Echelon Corporation, the developer of LON, desperately needs. According to its 1999 10-K filing with the SEC, the corporation lost $3.9 million last year and has accumulated a total deficit to date of $94.4 million. No wonder they want to fight and try to get a bigger share of the building controls market it is a matter of survival.
On the public relations front, the battle for the hearts and minds of building owners and operators does continue. The strategy of the LON supporters is clear: attempt to portray BAGnet as only applicable at the “top level” of building control systems, thus preserving their niche at the device level (the only place where any of the big building automation companies have seriously suggested the use of LON).
Unfortunately, their tactics have involved statements that are, at best, misleading. Here is an example from the ES article in August: “BACnet is a specification for supervisory system interoperability. In fact, if you read the beginning of the specification, it’s designed for interoperability among computers, not devices.”
This is patently false! BACnet has always been intended to be used in computer-based equipment of every size and description. The “purpose” clause in the BACnet standard actually reads (in part): “… to define data communication services and protocols for computer equipment used for monitoring and control of HVAC&R and other building systems …” What does “computer equipment” mean?
Since I personally drafted this clause, let me tell you: we intended to convey that any device providing digital computation (and thus networking) capability, for use in building systems, was to be covered by the standard. As any high school student knows, a digital “computer” contains a processor, memory, I/O, and instructions. Thus microprocessor-based devices all the way to mainframes were intended to fall within BACnet’s purview. Even the Neuron chip, which is actually three “computers” (microprocessors) on a single chip, was to be covered, although it had not yet been invented.
Note also the explicit reference to “other building systems …” This language was debated at length. While we hoped and intended that BACnet would find application much more broadly than only in hvacr (which it has), we felt that it would be presumptious for an ASHRAE committee to assert BACnet’s role in other building system areas (lighting control, fire, security; etc.) without first consulting with the appropriate experts in these domains. ASHRAE’s stated role, after all, is to advance the arts and sciences of heating, refrigeration, air conditioning, and ventilation. Today, the vast majority of BACnet devices deployed (and they number in the hundreds of thousands), operate at the terminal or small-device level. I would look to the BACnet Manufacturers Association (BMA) members to produce some statistics on this point.
It is also misleading (and annoying to those who have struggled to achieve accredited standard status for BACnet) to hear LON assert that it is a “de facto standard for control.” The Microsoft Windows operating system is a true example of a de facto standard. This means that it is virtually impossible to find a PC, anywhere on the planet, that isn’t running some form of Windows (sorry, Linux fans). The odds of walking into a digitally controlled building and finding LON (or even BACnet, for that matter) is currently slim at best. In order for LON to truly qualify as a de facto standard for building controls, it would be necessary to be able to walk into any modern building and find LON almost without exception. This is far, very far, from being the case.
What really counts, however, is not what the BACnet and LON partisans think. What counts is the experiences of building owners and operators with the two technologies. My suggestion is this: let the BMA provide contact information for the owners/operators of 100 of its top BAGnet jobs (confidentially if need be) and let the LouMark folks do the same. Armed with the names and numbers, the ES editors could survey the people whose opinions really mean something and let us all know the results. Now that would be interesting!
H. Michael Newman
Past Chairman, ASHRAE SSPC 135
Manager of Utilities Computer Section
COPYRIGHT 2000 Business News Publishing Co.
COPYRIGHT 2000 Gale Group