Babel Buster Network Gateways: Big Features. Small Price.
Discussion on Descriptors
Commanding and confirming the operation of two-state devices
“State descriptors” are terms that describe the status of two-state devices such as pump/fan motors and valve/damper actuators. These terms take on their import when used within the context of the Building Automation System (BAS). More specifically, these terms are typically to be found in the front-end systems and equipment graphics, accompanying the graphical representation of the particular device that they are there to describe. For instance, for any given air handling unit, the equipment graphic for the air handler will show all components of the air handler that are subject to automation. These include (but are not limited to) the following: fans, motorized dampers, and motorized control valves. For those automation components that are proportional in nature, the descriptor will be in the form of a true variable. For instance, the descriptor for a proportional control valve will be a value of percentage, i.e., “percent open”. For the automation components that are two-position in nature, the descriptor will be in the form of a two-state terminology. Two-state descriptors are what this writing is all about.
Before getting into the nitty-gritty of all of this, it is important to understand that, when a digital output commands a two-state device to assume one position or the other, the state descriptor shown on the graphic that correlates with that particular two-state device may get its information from one of two sources. The first comes from the simple fact that the BAS knows what end state it is commanding the device to be in, so this information can provide the basis for the state descriptor shown on the front-end graphic. However, does that truly tell us, beyond all reasonable doubt, that the end device is really in the position commanded of it by the output? Not really. What we need in order to truly confirm that an end device is in the position that it is commanded to be in, is some proof. Well, the proof comes in the form of some additional device, be it an end switch, relay contact, or what have you, that gives definitive confirmation as to the status of the two-state device. The switch typically feeds a digital input on the same controller, and this information is what is utilized to provide the basis for the state descriptor. We’ll explore the various proving techniques used for the two-state devices discussed ahead.
The first state descriptor that we talk about is perhaps the most fundamental. Applied in the case that the BAS is actually turning something on and off, this typically encompasses fan and pump motors. In the case of a three-phase motor-driven fan or pump, a digital output commands the fan or pump to be on, by initiating a contact closure at the motor starter. The motor starter responds to the contact closure by engaging, and in turn the motor is energized electrically. The proof that the motor is indeed running can come in one of several forms, the simplest being an auxiliary contact on the motor starter, when the starter pulls in, the contact is made, thus indicating that the motor has been energized. Taking proof of motor operation to the next level, a current sensing switch directly monitors the current draw of the motor, and provides a contact closure when current draw is present. Of course neither method describe above provides true proof that the pump or fan is indeed operating, although both are accepted methods of doing so. To provide “without-a-doubt” proof that a pump or fan is running however, a flow switch or pressure switch is required. For the pump, this takes the form of a paddle switch that is inserted into the pipe, or a differential pressure switch that’s installed across the suction and discharge of the pump. For fan systems, a differential pressure switch, with its high port inserted into the fan discharge duct, and its low port either left open or inserted into the fan suction side, is often the best way to prove fan operation.
If the motor starter for the pump or fan has a Hand-Off-Auto (H-O-A) switch, then the digital output from the BAS that commands the pump or fan to run will typically be wired into the “Auto” circuit of the switch. This allows for manual override of the motor: “override on” when the switch is placed in the “Hand” position, and “override off” when the switch is placed in the “Off” position. In these instances, even though the BAS may be calling for the motor to be doing one thing, the motor may actually be doing the opposite, depending upon the position of the H-O-A switch. The proving switch will provide information that is contradictory to what the BAS is calling for, and an alarm can be generated to flag the manual override condition.
As is the case with two-position motorized control valves and dampers, these devices assume either one of two states, with no in-betweens. A digital output commands the valve or damper to be in either one position or the other, and the state descriptor can be fed from this information. However for true proof of valve or damper position, it is common for the actuator to be equipped with an end switch, one that changes state at some position within its stroke. The degree of rotation at which the switch changes state is either fixed or adjustable, however with a two-position actuator, that’s really kind of arbitrary, as all that is really important is whether the valve is open or closed, and not at what point the end switch makes. Still, there may be a reason that you would want to set that end switch to make at a specific point in the stroke of the actuator. That of course is up to you!
This type of descriptor is used in the context of equipment, such as boilers and chillers, whereby the equipment has its own operating controls and its own means of starting and stopping itself. In these cases, the BAS is not turning anything on or off, but simply allowing or prohibiting operation of a piece of “packaged” equipment. A digital output ties into the equipment’s on-board control system, and thus has control over whether or not the equipment can operate, under it’s own controls.
In the case of a boiler, when the boiler is enabled, it is allowed to fire and maintain hot water temperature setpoint via its own operating control. In the case of a chiller, when the chiller is enabled, it is allowed to energize its compressor(s) and maintain chilled water temperature setpoint via its own leaving water temperature controller.
A status contact from the equipment, which is typically a dry contact closure that can serve as a digital input to the BAS, can provide “run status” information on the piece of equipment. For the boiler, this contact may tell whether or not the boiler, once enabled, is actually firing. And for the chiller, the status contact may indicate whether or not the compressors are energized. In both cases, the status contact provides useful feedback to the BAS, for if the BAS is enabling the equipment, and the status contact never seems to signify a run condition, then it is likely that something else is holding out the operation of the equipment, such as an unmade flow switch or other safety device. Or even an on-board failure diagnostic, in the case of equipment that has microprocessor-based controls.
Of course the enable/disable state descriptor is not limited to boilers and chillers, but can apply to other types of equipment as well. These are just two of the more common types of packaged equipment that come to mind, and serve as good examples to explain the application of this state descriptor.
|Tip of the Month: Be aware of state descriptors, and of their origins. While it is easy to look at the front-end graphic and read that a two-position device is in one state or the other, the state descriptor must be fed from the proving switch in order to reflect the true status of the device. Otherwise it’s just the BAS telling you what it is asking for of the end-device, and whether or not it’s actually true is anybody’s guess!|
This state descriptor, as the one discussed above, typically applies to equipment, or really any kind of device that operates under the control of some separate, independent control system. A digital output ties into the external controls that operate the equipment, in such a fashion so as to either allow the equipment to operate as it is intended to, via its own controls, or override the equipment into a run state. To use the examples from above, in the case of a boiler, this would mean that the output overrides the boiler’s operating control, and puts the boiler into a firing mode. For as long as the digital output is closed, the boiler will fire, with no regard to what its local operating control is commanding it to do. Until the output is opened, or until some other device, such as a high limit temperature control, ceases operation of the boiler. In the case of the chiller, it would be the leaving water temperature control that is overridden, causing the compressor to run, until the override command is released, or some other hard-wired safety device trips and shuts down the chiller.
This particular state descriptor doesn’t originate from a digital output. Its information is taken solely from the equipment that’s being monitored. As with the run status contact that was described above with respect to chillers and boilers, a piece of equipment may also provide an alarm output, which can serve as a digital input to the BAS. This is essentially the case for equipment that has microprocessor-based controllers, which in themselves have I/O capability and can monitor any number of equipment operating parameters and ensure that the equipment is operating within tolerance. If the microprocessor determines that a certain operating parameter is out-of-whack, the controller will generate an alarm, and may or may not cease operation of the unit, depending upon the particular alarm. Typically, upon an alarm that does cease operation of the unit, the alarm output contact will change state, and thereby signal to the BAS that the equipment is “in alarm” and in need of some manual intervention.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]