This article is the fifth installment in this series. It provides an example of inappropriate enable logic for AHU humidifiers. Next month’s article will discuss a separate example with inappropriate disable logic for AHU humidifiers.

The Sequence

This example came from AHUs in a new hospital. The specified sequence of operations for the AHU humidifiers was as follows:

Humidifier Operation Enable:

The packaged, clean steam humidifier shall be enabled when all of the following are met:

• Outdoor air dewpoint is below 40°F (adj.)
• Supply fan is enabled.
• Supply fan status is proven ON.

Humidifier Control:

The BAS will send a modulating demand signal to the packaged humidifier. That signal will be modulated to maintain the AHU’s supply air dewpoint at its setpoint.

Supply Air Dewpoint Setpoint Reset:

The supply air dewpoint setpoint will be reset between 33°F and 44°F as needed to keep the return air relative humidity at setpoint (35% (adj.)).

Essentially, these are cascaded control loops. Return air relative humidity is the primary controlled variable we care about, but we control the humidifier to supply air dewpoint to ensure we perform the operation stably without tripping a high humidity limit switch in the supply duct.¹ A diagram depicting this logic is shown in Figure 1.

The Issue

The sequence of operation, in addition to a variety of high limit safety sequences, tested out well early in the testing phase. The ambient conditions were well below the 40°F outdoor air dewpoint enable setpoint, so we toggled that setpoint a few times and confirmed the BAS indeed disabled the humidifier as intended when outdoor air dewpoint rose above the outdoor air dewpoint enable setpoint.

Later in the testing phase, the outdoor air dewpoint rose, and the humidifier operation disabled naturally. However, when the outdoor air dewpoint dropped back below the enable setpoint of 40°F, we realized there was a glitch in the programming. The humidifier did not enable as expected, despite return air humidity hovering well below the 35% setpoint.

CONTROLS: Cascaded control loops for AHU humidifier operation. (Courtesy of Questions & Solutions Engineering)

The Root Cause

The sequence clearly indicates when the humidifier is to be enabled, and there was a binary output from the BAS to allow for such enabling. However, there will be times when this humidifier will not be needed despite the outdoor air dewpoint being below 40°F, due to sufficient latent gains within the served space. With that in mind, the temperature controls contractor interpreted the sequence’s humidifier enable language as a permissive, meaning the humidifier operation will be allowed to run if needed when outdoor air dewpoints are below 40°F. Their intent was to avoid enabling the humidifier itself when it was not needed. Therefore, the logic expanded upon the specified sequence so that all of the following needed to be met before the humidifier was enabled through a binary output from the BAS.

Humidifier Operation Enable:

The packaged, clean steam humidifier shall be enabled when all of the following are met:

• Outdoor air dewpoint is below 40°F (adj.)
• Supply fan is enabled.
• Supply fan status is proven ON.
• A non-zero demand for humidification (i.e., the output of Control Loop 2 in Figure 1).

The addition of the fourth bullet above should have worked fine. However, for the entire humidification operation to be carried out correctly, Control Loop 1 (whose output resets the supply air dewpoint setpoint) and Control Loop 2 (whose output provides the analog demand to the humidifier) would also need to be enabled. Control Loop 2 was correctly configured in the software to enable when the first three of the four listed prerequisites for the packaged humidifier operation were met; that is what allowed for a non-zero demand for humidification to be generated and the fourth prerequisite to eventually prove true.

The root cause of the issue was that the programming used the same enable logic (all four prerequisites listed above needing to prove true), which physically enables the humidifier, for enabling Control Loop 1. This resulted in the supply air dewpoint setpoint staying pinned at 33°F (the low endpoint of the reset range), the supply air dewpoint hovering a bit above that setpoint, and the humidifier never enabling to bring return air relative humidity back to setpoint.

The Fix

The remedy was simple: continuously enable Control Loops 1 and 2 when the first three prerequisites for humidifier operation were met. Enabling the humidifier itself could still wait for the fourth prerequisite (a non-zero demand for humidification). This allows for the supply air dewpoint setpoint to reset upwards when return air relative humidity is not being satisfied, and eventually it would reset high enough to generate a non-zero demand for humidification and force the humidifier to run.

Conclusion

Some issues may not present themselves during initial functional testing. This particular issue was only caught through trend review weeks after initial testing. Programming review during initial testing may have caught it earlier, but that level of rigor for each sequence being tested on a project is typically not budgeted for by commissioning providers. Commissioning providers should be aware of issues such as these, and then best employ the tools at their disposal (programming review, trend review, active testing, etc.) to ensure such issues are not present.

Next month’s article continues with the topic of AHU humidifiers when we discuss inappropriate disable logic which resulted in … freeze-stat trips! Does that sound far-fetched? Join me next month and allow me to explain.

References:

1. Ryan, M. 2021. “Understanding Cascade Control and Its Applications For HVAC.” ASHRAE Journal, Vol 63, Issue 2, (February)