Tracer Summit Site Sync + CPL Manual??

[apprentice3]

The other day I worked on a Tracer Summit system that I have worked on before, but this time I noticed a lot of the analog inputs were gone, the event routing wasn't set up the same, the phone book for the BCU modem was blank, and a lot of the graphical bindings/links were gone. I found out the customer connected to the system with a Laptop with a old copy of this site on it. Would this laptop try to sync its copy of the database to the BCU when connected? Is there a way to make sure that this doesn't happen? At what times does the BCU try to sync its database?

I am also looking for some type of CPL manual. I am trying to set up a program for some VAV boxes with H.W. reheat. These VAVs do not have fans, and use straight AHU air with a heating min cfm. I need a way to have the VAVs ignore the heating min. whenever the boilers are off due to the OAT lockout. Does someone have a program like this in there library that I can use as a example to get started with? If not what have you guys done in the past with a situation like this?

Thanks A lot!

[Webbyz]

Would this laptop try to sync its copy of the database to the BCU when connected? Is there a way to make sure that this doesn't happen? At what times does the BCU try to sync its database?

We have this happen occasionally as well. Here is basically what happens...

When a PC connects to the site, the internal database on the BCU and the PC compare timestamps on their last database update. So if BCU-1 has a database timestamp of 6/17/12 12:34am and the PC has something prior to this, the PC will request the database from the BCU and "Sync" itself to the BCU. The BCU's timestamp will get updated anytime that you make a system change such as a setpoint change, make a new AI/BI, a new trend, ect.

Here is where the issue comes in that we have...

Say you have a few field techs who are working on the same job. Tech 1 programs all day, makes his last change at 5pm and goes home. Tech 2, who had not connected since 8am the same day, never got the changes that were made by Tech 1 on his laptop. But Tech 2 wants to do some offline programming at home. So he does some work on his laptop that night and gets in first thing in the morning and hooks up to the BCU. Here is the issue...

The BCU sees that Tech 2's laptop has a update at 6/17/12 9:00pm. The BCU's internal database stamp says it was last updated at 6/17/12 5:00pm. So the BCU will take the database from the PC since it sees that it has a newer timestamp on it. BCU now has a timestamp of 6/18/12 8:00am. Now all of Tech 1's work is gone.

Tech 1 connects to the site, his laptop sees that the BCU has a newer timestamp than his PC, and it sucks that database down on the PC. Now all his work from yesterday is gone (unless he was smart and did a .BDB backup).

So what i'm assuming happened was that someone on this old laptop that you are talking about made some type of change prior to them connecting it where is updated that timestamp and when they connected, the BCU got the old info pushed down to it becuase it saw a new timestamp.

There really is not a pre-defined time when the BCU will sync. I have been on a job working on my laptop making changes where there is a PC connected on site, and usually within about a minute tops, my changes are visable on the local PC.

If you want the CPL guide I can send it to you. Just shoot me an email. But I would assume that there is a binary point in your system that is a "Hot Water System Enabled?" point. Probably a BI or a BV on a controller. I would just reference the state of that point to the "Reheat Lockout" on the VAV. Should stop the box from using that setpoint.

Hope my rambelings made sence.

[apprentice3]

We have this happen occasionally as well. Here is basically what happens...

When a PC connects to the site, the internal database on the BCU and the PC compare timestamps on their last database update. So if BCU-1 has a database timestamp of 6/17/12 12:34am and the PC has something prior to this, the PC will request the database from the BCU and "Sync" itself to the BCU. The BCU's timestamp will get updated anytime that you make a system change such as a setpoint change, make a new AI/BI, a new trend, ect.

Here is where the issue comes in that we have...

Say you have a few field techs who are working on the same job. Tech 1 programs all day, makes his last change at 5pm and goes home. Tech 2, who had not connected since 8am the same day, never got the changes that were made by Tech 1 on his laptop. But Tech 2 wants to do some offline programming at home. So he does some work on his laptop that night and gets in first thing in the morning and hooks up to the BCU. Here is the issue...

The BCU sees that Tech 2's laptop has a update at 6/17/12 9:00pm. The BCU's internal database stamp says it was last updated at 6/17/12 5:00pm. So the BCU will take the database from the PC since it sees that it has a newer timestamp on it. BCU now has a timestamp of 6/18/12 8:00am. Now all of Tech 1's work is gone.

Tech 1 connects to the site, his laptop sees that the BCU has a newer timestamp than his PC, and it sucks that database down on the PC. Now all his work from yesterday is gone (unless he was smart and did a .BDB backup).

So what i'm assuming happened was that someone on this old laptop that you are talking about made some type of change prior to them connecting it where is updated that timestamp and when they connected, the BCU got the old info pushed down to it becuase it saw a new timestamp.

There really is not a pre-defined time when the BCU will sync. I have been on a job working on my laptop making changes where there is a PC connected on site, and usually within about a minute tops, my changes are visable on the local PC.

If you want the CPL guide I can send it to you. Just shoot me an email. But I would assume that there is a binary point in your system that is a "Hot Water System Enabled?" point. Probably a BI or a BV on a controller. I would just reference the state of that point to the "Reheat Lockout" on the VAV. Should stop the box from using that setpoint.

Hope my rambelings made sence.

Wow this is a lot of great information, thank you so much. So the reheat lockout should get rid of the heating minimum?

Thanks again!

[Webbyz]

Well it should at least make it so it won't try to use the Termainal Reheat if your zone temp gets too low where it would normally use it so you won't be aimlessly trying to reheat a zone with the miminum heating flow. Else you might have to do some setpoint manipulation to drop your heating setpoint to where it won't go into a heating control action.

[apprentice3]

Well it should at least make it so it won't try to use the Termainal Reheat if your zone temp gets too low where it would normally use it so you won't be aimlessly trying to reheat a zone with the miminum heating flow. Else you might have to do some setpoint manipulation to drop your heating setpoint to where it won't go into a heating control action.

Since you are so helpful.. I have another question for you. I have another building with a Tracer Summit system, and when the Trane Intellipaks go into Night Heat/Cool mode it sets the IGVs to 100%. I have verfied RTU setpoints, VAS settings, and Area Settings. They all appear to be normal. When the IGVs go to 100% the static pressure goes through the roof. What could be causing this to happen?

Thanks!

[ascj]

Since you are so helpful.. I have another question for you. I have another building with a Tracer Summit system, and when the Trane Intellipaks go into Night Heat/Cool mode it sets the IGVs to 100%. I have verfied RTU setpoints, VAS settings, and Area Settings. They all appear to be normal. When the IGVs go to 100% the static pressure goes through the roof. What could be causing this to happen?

Thanks!

Do the VAV's go 100%?

[apprentice3]

Do the VAV's go 100%?

No they do not. The box for drive vavs to max when VAS is in heat is checked. The system should be going into the cooling mode at night. The average zone temperature is getting up to 78-80 degrees. The SA temperature drops as if it is in cooling, but for some reason the IGV status is 100%. The static pressure setpoint is 2"w.c. at that time. The actual static pressure is 3.5"w.c. at the time.

[ascj]

No they do not. The box for drive vavs to max when VAS is in heat is checked. The system should be going into the cooling mode at night. The average zone temperature is getting up to 78-80 degrees. The SA temperature drops as if it is in cooling, but for some reason the IGV status is 100%. The static pressure setpoint is 2"w.c. at that time. The actual static pressure is 3.5"w.c. at the time.

Your unit us going to act like a CV unit during unoccupied. Your boxes should be 100% during unoccupied.

Sent from my C771 using Tapatalk 2

[Webbyz]

No they do not. The box for drive vavs to max when VAS is in heat is checked. The system should be going into the cooling mode at night. The average zone temperature is getting up to 78-80 degrees. The SA temperature drops as if it is in cooling, but for some reason the IGV status is 100%. The static pressure setpoint is 2"w.c. at that time. The actual static pressure is 3.5"w.c. at the time.

It sounds to me like you have a varience between the setpoints in the Area Control and the setpoints in the VAV's. First off, are you using UCM I/II/III/IV VAV's or Comm5 VV550/1's? Remember that Comm4 boxes do NOT go occupied during night heat/cool. They will use their unocc setpoints. Comm5 VAV use occupied setpoints during night heat/cool.

Typically your area control is what is responsible for telling the iPak to go into Night Heat/Cool.

I am going to "assume" this is what is happening with some generic values...

Building temp is 85 degrees.
Area unoccupied cooling setpoint is 85 degrees.
Area unoccupied cooling differential is 4 degrees.
VAV unoccupied cooling setpoint is 85 degrees.

The area tries to cool the building to 81 degrees but the VAV box sees that its unoccupied setpoint of 85 degrees is satisfied so it closes down the air valve.

The general rule of thumb is to set the unoccupied cooling setpoint to a setpoint of (area unocc cooling spt - area unocc differential). So in this case 85-4 = 81 degree unocc cooling setpoint on the VAVs. So then when the unit turns on, your VAVs will see that they are 4 degrees above setpoint and need to open their air valves to meet spec.

[apprentice3]

It sounds to me like you have a varience between the setpoints in the Area Control and the setpoints in the VAV's. First off, are you using UCM I/II/III/IV VAV's or Comm5 VV550/1's? Remember that Comm4 boxes do NOT go occupied during night heat/cool. They will use their unocc setpoints. Comm5 VAV use occupied setpoints during night heat/cool.

Typically your area control is what is responsible for telling the iPak to go into Night Heat/Cool.

I am going to "assume" this is what is happening with some generic values...

Building temp is 85 degrees.
Area unoccupied cooling setpoint is 85 degrees.
Area unoccupied cooling differential is 4 degrees.
VAV unoccupied cooling setpoint is 85 degrees.

The area tries to cool the building to 81 degrees but the VAV box sees that its unoccupied setpoint of 85 degrees is satisfied so it closes down the air valve.

The general rule of thumb is to set the unoccupied cooling setpoint to a setpoint of (area unocc cooling spt - area unocc differential). So in this case 85-4 = 81 degree unocc cooling setpoint on the VAVs. So then when the unit turns on, your VAVs will see that they are 4 degrees above setpoint and need to open their air valves to meet spec.

Thank you so much. This makes total sense. My area setpoints are set exactly what my VAV unocc. setpoints are at. I am using Comm 4 VAV boxes UCM III + IV. Will the IGV always go to 100% in Night heat/cool?

Thanks!

[roadgear16]

The property should already be referenced from the install, but their is a property called "VAS-Drive to Max" or something along those lines that needs to be referenced from the IPAK to the VAV's that it serves. This command is initiated anytime the IPAK (or Voyager) is going from SA static control to full speed fan (ie heating). The VAV's then drive to max flow, alleviating the over pressurization of the duct. I haven't done UCM II/III/IV's in at least 3 years so I don't remember the exact wording, but something along those lines.