Hi Jean,<br><br>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. <br>
<br>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...<br><br>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. <br>
<br>Hope that helps!<br>-- <br><span style="color:rgb(0,0,0)">Marcus Jones, </span><span style="color:rgb(0,0,0)"> M.Sc.</span><span style="color:rgb(0,0,0)">, </span><a style="color:rgb(0,0,0)" name="SafeHtmlFilter_131245b5df81718e__MailAutoSig"><span style="font-size:10pt"></span></a><span style="color:rgb(0,0,0)"><span style="font-size:10pt">LEED<sup>®</sup>AP BD+C</span></span><br style="color:rgb(0,0,0)">
<i style="color:rgb(0,0,0)">Freelance energy consultant</i><br style="color:rgb(0,0,0)"><i style="color:rgb(0,0,0)">Vienna, Austria<br><br><br></i><div class="gmail_quote">On Fri, Sep 14, 2012 at 2:33 PM, Jean Marais <span dir="ltr"><<a href="mailto:jeannieboef@gmail.com" target="_blank">jeannieboef@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Group,<br><br>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.<br>

<br>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".<br><br>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".<br>

<br>HERE'S THE CATCH:<br>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.<br>

<br>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".<br><br>pls. advise,<br><br>Kind regards,<br>

<br>JEAN MARAIS<br>
<br>_______________________________________________<br>
TRNSYS-users mailing list<br>
<a href="mailto:TRNSYS-users@cae.wisc.edu">TRNSYS-users@cae.wisc.edu</a><br>
<a href="https://mailman.cae.wisc.edu/listinfo/trnsys-users" target="_blank">https://mailman.cae.wisc.edu/listinfo/trnsys-users</a><br>
<br></blockquote></div><br><br clear="all"><br><br><br>