CPL Problem

[jogas]

The following outside air changeover program is outputting an OCCUPIED status when linked to a binary output thru the outputs CPL referencer.
Looking at the program and comparing it to examples (thanks KWILL), it seems the integer defintion should read:
DEFINT On=1,
OFF=0

I think I'm doing something wrong with this CPL's output link to the Binary Output that I'm getting the OCCUPIED status from. Do I link the Binary Output to this CPL at the BOP Properties window?
Any help is GREATLY appreciated.
Here's the file:

PROGRAM CLG_CHNG

DEFINT On=1, Off

IF (({OUTSIDE AIR TEMP}.{Present Value} < {COOLING CHANGEOVER STPT}.{Present Value}) OR ({RTU-1 Auxiliary Control}.{Binary Var Local}[2] = Off))
THEN
CONTROL ({RTU1 COOLING STAGES}, {Present Value}, 0, 5, SET)
CONTROL ({HEATING LOCKOUT}, {Present Value}, Off, 5, SET)
ELSE
CONTROL ({RTU1 COOLING STAGES}, {Present Value}, 0, 5, RELEASE)
CONTROL ({HEATING LOCKOUT}, {Present Value}, On, 5, SET)
END IF
IF (({OUTSIDE AIR TEMP}.{Present Value} < {COOLING CHANGEOVER STPT}.{Present Value}) OR ({RTU-2 Auxiliary Control}.{Binary Var Local}[2] = Off))
THEN
CONTROL ({RTU2 COOLING STAGES}, {Present Value}, 0, 5, SET)
CONTROL ({HEATING LOCKOUT2}, {Present Value}, Off, 5, SET)
ELSE
CONTROL ({RTU2 COOLING STAGES}, {Present Value}, 0, 5, RELEASE)
CONTROL ({HEATING LOCKOUT2}, {Present Value}, On, 5, SET)
END IF
IF ({HEATING LOCKOUT}.{Present Value} = On)
THEN
CONTROL ({RTU-1 HTG ENABLE}, {Present Value}, Off, 4, SET)
CONTROL ({RTU-2 HTG ENABLE}, {Present Value}, Off, 4, SET)
ELSE
CONTROL ({RTU-1 HTG ENABLE}, {Present Value}, Off, 4, RELEASE)
CONTROL ({RTU-2 HTG ENABLE}, {Present Value}, Off, 4, RELEASE)
END IF

END

Does anyone see a reason why I could not write this program in the each of the RTU's MP580's ?
TIA,
Jogas

[square&level]

Jo
(reply to a separate topic) Do you have the servicepack 9 for rover? If not, go here to get it. You'll need it for the ZN 517

http://www.trane.com/Commercial/Equipment/Downloads.aspx

[willf650]

I don't quite get your question but you don't need to reference the CPL program from the binary outputs editor if thats what your asking. The CPL already controls the point from within the program in these lines
CONTROL ({example bo}, {Present Value}, 0, 5, SET)
with no further reference needed. The properties reference in the binary output editor is to control an output or property in the summit system. Many controlers have spare outputs that can be controlled from the summit system directly. You reference that point in the outputs editor property reference. When that binary output goes off and on in the BCU the actual point in the controller follows.

You also don't need to have the integer off defined as equaling 0 (defint off=0). If there is no specific value defined it automaticly equals zero.

As far as writing the programs in the 580s I don't see a reason to do so. All the points you are reading and controling(with the exception of two) are points in the BCU and not local to the 580 from what I can tell.

[kwillmech]

It is okay to leave the program in the BCU (as CPL) because the BCU will need to communicate the control to the Voyager units anyways. You will not be improving anything in the system unless you plan to bind the values from the mp.581s directly to the Voyagers. But then the customer in Summit cannot manipulate the control.

[jogas]

willf650,
Thanks for the reply.
I always say I ask the dumb questions until I get smart enough to ask the smart questions. And I'm really getting a crash course in how not to set up a Summit site.

Kwill, willf650
Thanks. After today, I'm thinking I'll leave the CPL and not try to duplicate it in the MP581.

Todays accomplishments: I was able to link the CPL results to the Binary Outputs previously created. I did this by choosing the "Not Defined" Property of each output defined as a SET or RELEASE value in the CPL program I started this topic with. When I ran the CPL Debug for this file, it had an error when it referenced the first BOP. That clued me in to the "Not Defined". For the first time, I was able to see the HEAT ENABLE and HEAT LOCKOUT at the proper values for todays Outside Air Temp. I also linked the Voyager HEAT and COOL mode properties to this CPL program. Both RTU's ran all afternoon in cooling mode with 1 compressor and 52-55 degree SAT for the first time in years.
Questions:
1. Please explain Database Synchronization. Am I supposed to be doing this
after any changes to the database?
2. When a Schedule has a Voyager RTU as a Member, should the RTU shut off
when the Schedule is off? RTU1 did not this afternoon even though it is a
Schedule Member. Does it take a while to happen?
3. Where does the Voyager RTU get it's Occupied command from? Is it the
Schedule? Where is this defined?
4. How does the VAS VAV's link to the RTU in an Area?

Lot's of questions....so little time.
TIA,
jogas

[mallron]

This thread is turning into Tracer Summit 101 ( that's a real class btw). :)

1.) Database sync occurs when the database on your workstation matches the database on your BCU(s). So let's say you make a change to a site on your labtop while you're offline, not connected. Now the database in your laptop is different than the one at the site. The next time you connect to the site your laptop will download your changes to the BCU's and the two databases will "sync". This also works in reverse. If you have a laptop that you never use, but the workstation onsite is always used to make changes, then the next time you connect with the laptop the current database will be downloaded to your laptop. I wouldn't make a habit of making changes to the database while offline if this is an existing site.

2.) Yes the RTU should shut down when TOD goes unoccupied if it is a heat/cooling member and there is a normal event in the TOD schedule.

3.) See answer #2 If the RTU didn't shut-down then check it's override screen and see what's controlling it and @ what priority.

4.) TOD occupies AREA, AREA occupies its VAV members ( in this situation the RTU SHOULD NOT be a member of AREA) VAS polls the occupied VAV's for their min. CFM, VAS tallies this info and when the VAV's reach the VAS min. CFM setpoint then VAS starts it's AHU/CSC/RTU etc.

Now I need a PO# :) :) :)

-JB

[kwillmech]

A little to add:

2. Check the BCU date/time. You can sync it to the workstation in Site Configuration. Double check the Schedule setup and type of start/stop. The TOD Schedule will control members based on the type of start/stop command and the member type. If the Voyager is a Normal member and you only have Optimal Start/Stop commands it will not respond. Also, a Voyager cannot respond to Optimal commands because it does not have unoccupied setpoint control. To be safe add the Voyager to an Area and have the Area in the TOD Schedule member list. An Area will respond to Normal and Optimal commands.

[willf650]

Voyagers also have no unoccupied setpoints as already mentioned so they need to be set up in an area to do unoccupied temperature control.


The schedule can also have member offsets which can turn on specfic members early and off late. In this event the schedule could be off and unit still run until the offset time expires.

Next question I see coming is how to set up an area and VAS