[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TRNSYS-users] Type 56 with AHU



Hi Jean,

I never use the type 56 internal heating when coupling to AHU. I always instead create i.e. a VENTILATION type in TRNBLD which is defined by INPUTS for the temperature, flow rate, and humidity of incoming air. This provides the input side. For the output side, I would read the temperature of the zone, and feed that to the AHU controller. This defines the demand for that zone, and it's closer to reality, a real controller would never directly know the energy demand of a zone.

But it amounts to a lot of clicking and connecting if you have a lot of zones, which I think you do. It's often a battle against the software trying to get at the values we need...

In your case it sounds like you at a minimum need to externalize (create an INPUT) the heating power of the heating type. This way you can turn it off/on or regulate the power in the ideal type. Same goes for set temperature, if you set the heating temp very low, this is the same as turning it off. So generally, you need to lookup how to get values into/out of TRNBLD? Maybe you already have, but click the play arrow icon in TRNBLD for a field - change from constant to input - and then update the type 56 icon.

Hope that helps!
--
Marcus Jones,  M.Sc., LEED®AP BD+C
Freelance energy consultant
Vienna, Austria


On Fri, Sep 14, 2012 at 2:33 PM, Jean Marais <jeannieboef@gmail.com> wrote:
Dear Group,

I'm stuck with a fundemental catch22. I report QSENS, the heating/cooling DEMAND from the building object Type 56. This, however does not report the demand, but instead the minimum of the demand and available "power". This means when, eg. "heating power" is set to 0, QSENS will report zero and when set to "unlimited" QSENS will report the actual demand to hit the defined setpoint.

Going on to the zone...The cooling heating setpoints can only be assigned to the zone to do the previous calculation QSENS for the zone, when the heating/cooling is clicked "on".

Thus, the actual demand for the zone QSENS can only be read out when the limit is set to "unlimited" and the heating/cooling is set as "on".

HERE'S THE CATCH:
I used QSENS to tell my AHU how much it should try and heat/cool. I send the resulting air into the zone which could be anything and does't matter, because even if the AHU can't meet the loads (or there is a power failure and the AHU is off for 2 hous), the resulting air temperature will never go outside of my heating/cooling setpoints (20/26), because unlimited cooling energy exists in the zone. This again is bad as the extracted air from zones is read from the building to be no higher than 26, which affects the heatexchanger, economizer, etc.

At the moment I don't see a work around. The best I can do is report when the AHU Q does not meet the sum of zones Q at which point the simulation becomes "inaccurate".

pls. advise,

Kind regards,

JEAN MARAIS

_______________________________________________
TRNSYS-users mailing list
TRNSYS-users@cae.wisc.edu
https://mailman.cae.wisc.edu/listinfo/trnsys-users