Control System (CS) Object

Transcription

1 Metasys Network Technical Manual 636 Objects Section Technical Bulletin Issue Date 0101 Control System (CS) Object Introduction Page *3 Quick Start *3 Overview of Concepts *6 Software Models *9 Engineering Overview *15 Overview of Operation 15 Hardware Interface *16 Command Processing 19 NT Command and Display Attributes 23 COS Reporting *24 Triggers 25 Optional Mapping to AD and BD Objects 25 Database Generation *27 Overview 27 Mapping Points in the Controller to Software Model Attributes *27 Point Mapping Tables *33 Defining a CS Object with DDL *71 Defining a CS Object with Online Generation *77 Reference Tables *87 Attribute Table *87 Command Table *101 * Indicates those sections where changes occurred since the last printing Johnson Controls, Inc. 1 Code No. LIT

2 2 Objects Control System (CS) Object

3 Introduction The Control System (CS) object is the software representation of selected hardware and internal points in a controller. The selected points are attributes of the CS object. A CS object typically represents one control strategy (e.g., temperature control, static pressure control) located in a controller, though it may represent the control strategy for the entire controller. Currently, CS objects support the following N2OPEN, System 9100, and LONWORKS compatible devices: Air Handling Unit (AHU) controller, Unitary (UNT) controller, Variable Air Volume (VAV) controller, VAV Modular Assembly (VMA), Phoenix Lab and Fume Hood Interface Module (PHX), Metasys Integrator (MIG), Generic Vendor Devices (VND), N2 Dialer Module (NDM), Lab and Central Plant (LCP) Controller/DC9100, DX9100, DXECH, XT9100, Expansion Modules (XTM), DR9100, TC9100, LONTCU, LONTCUA, LONVMA, LONVMAA, LONDXA, LONDXAA, LONDXD, LONDXDA. Note: Some devices are unique to local markets and are not available globally. Quick Start Defining the CS Object This section tells you how to quickly define the CS object from the Operator Workstation (OWS). For information on the overall process of defining the controller, creating a software model, and then defining a CS object, see Database Generation later in this document. The CS object can be defined: either online at the OWS using the CS Object Definition window, or offline using Data Definition Language (DDL). See the DDL Programmer s Manual (FAN 630) for syntax and procedures. Objects Control System (CS) Object 3

4 HVAC PRO software (Release 5.10 or later) and the GX-9100 Configuration software (Release 3.0 and later) generate a DDL model file when the configuration is saved. For HVAC PRO and GX-9100 (Release 4.0 or later), you must select the Generate DDL on Save option when you save the configuration. This creates a model file with a.ddl extension for Application Specific Controllers (ASCs) and.dmo and.dnc extensions for Digital Expansion (DX) units. For GX-9100 Release 3.0, the files are generated automatically when you save the configuration. The automatically generated model file includes all the defined points in the controller. To customize the model file, delete and modify points as needed. For more information, see the appropriate configuration tool manual. To define a CS object online at the workstation: 1. Go to the summary of the system in which you want to add the object. 2. Select Item from the menu bar. Then select New from the Item menu. A dialog box for selecting object type appears. 3. Select Control System from the list of object types. Then, in the Hardware System and Hardware Object fields, type the system and object names of the controller the CS object will be mapped to. This must be a defined controller. Click OK. A dialog box for selecting a software model appears. A software model is a template for CS objects. When you define a CS object, you must reference an already defined software model. If the model does not exist, you must define it before you define the CS object. Defining software models is explained in this document, under Database Generation. If you are defining more than one CS object on a controller, each CS object must reference a different software model. And, if the same points are used in more than one model, only one model should allow the points to be commanded/adjusted. Otherwise, command conflicts can occur. 4. Select the software model and click OK. The CS Object Definition window appears (as shown in Figure 1). 4 Objects Control System (CS) Object

5 Control System Definition - AHU - 1 Item Edit View Action Go To Accessory Help HDQTRS NC-44 GROUP #1B GROUP2B GROUP #2B HARDWARB Hardware System HARDWARB System Name Object Name Expanded ID HARDWARB Comm. Disabled n Graphic Symbol # Operator Instr. # 0 0 Hardware: System Name Object Name Expanded ID HARDWARB N20-2 AHU-1 Flags Auto Dial-up Report Type Override n none Csobjnew Figure 1: Control System Object Definition Window Note that some of the fields are blank and some are already filled in. You must fill in the blank attribute fields (e.g., Object Name) because they do not have defaults. The attribute fields that are already filled in contain default settings, which you can either accept or change. The following table explains the attributes without default settings. The Attribute Table section at the end of this document describes all CS object attributes. The Operator Workstation User s Manual (FAN 634) explains in detail the procedures for entering and changing data. Table 1: Attributes without Default Settings Attribute Description Entry Object Name Expanded ID (optional) Display Attribute NT Command Attribute Identifies object (e.g., AHU-1, AHUTEMP). The object name cannot already exist in the system. Further identifies object (e.g., AHU Temperature Control). The attribute whose value appears as the CS object s Current Value in summaries, in the CS Object Focus window, and at the Network Terminal (NT). The one attribute that can be commanded from the NT. 8 alphanumeric characters 24 alphanumeric characters Use the attribute name/number as it appears in the software model (e.g., AI_1, AI_2, BI_3, BI_4). Use the attribute name/number as it appears in the software model (e.g., AI_1, AI_2, BI_3). 5. To save the new CS object, select Save from the Item menu. The new CS object is added to the operational database in the NC. Objects Control System (CS) Object 5

6 Modifying and Monitoring the CS Object Overview of Concepts Configuration Software Once a CS object is defined, you can modify its attributes online using the CS Object Focus window. You also use the Focus window to monitor and command the CS object. For more information on modifying and monitoring the CS Object, refer to the Operator Workstation User s Manual (FAN 634), under Using Object Focus Windows. This is the end of the Quick Start section. If you need information on the overall process of defining a controller, a software model, and then a CS object, see the Database Generation section of this document. If you need information on the purpose and operation of the software model and CS object, continue reading this section, which explains how these components work together. These concepts are briefly explained in this overview: configuration tools and configuration files CS objects software models hardware models The CS object and software model are explained in greater detail throughout the document. The AHU, UNT, VAV, VMA, PHX, NDM, and System 91 devices (LCP/DC9100, DX9100, DXECH, TC9100, XT9100, XTM, DR9100) are all configurable devices, meaning they are not preprogrammed. To program these controllers, you must use the appropriate configuration software. See Table 2. 6 Objects Control System (CS) Object

7 Table 2: Controller and Configuration Software Controller M-Tool Software Configuration File Protocol AHU, UNT, VAV, PHX, NDM HVAC PRO Software.PRN file* N2OPEN VMA HVAC PRO Release 7.0 or higher LCP/DC9100 LCP Configuration Release 3.2 or GC-9100 Release 3.2 DX9100, XT9100 DXECH (DX912x).PRN file* N2B.GPS configuration file System 9100 GX-9100.DXS configuration file System 9100 GX-9100 Release 4.01 or higher.dxs configuration file Echelon (N2E) XTM XTM Configurator Release 3.01.DBF and.hmc configuration files System 9100 DR9100 SM-9100 Module N/A System 9100 TC9100 HVAC PRO Software.PRN file System 9100 LONDXA, LONDXAA, LONDXD, LONDXDA (DX-9200)** GX-9100 Release 6.0 or later.dxs configuration file LONWORKS LONTCU**, LONTCUA** Factory Configured N/A LONWORKS LONVMA, LONVMAA M-Pro Software.NXE application file.xif interface file.exp configuration file MIG, VND N/A Vendor-specific application note LONWORKS N2OPEN * HVAC PRO software produces a.prn file. DOS versions of HVAC PRO software produce a.sym file. ** Contact Johnson Controls, Inc. for product availability. The configuration tools allow the programmer to select from a series of paths. Each path corresponds to an application supported by the controller (e.g., air handling unit, roof top unit). For a list of currently available applications, see the controller s technical bulletin. See the controller s documentation for information on configuration tools. (For example, for information on generating the.dxs file for a DX9100, see the GX-9100 Software Configuration Tool User s Guide (LIT ) in the System 9100 Technical Manual (FAN ) Configuration Files Once you configure the device, print a hard copy of the device s configuration. This printout lists the names and addresses of the configured hardware and internal points in the device. Use the information in the printout to create software models. (These files are explained later in this document, under Database Generation.) Note: For Metasys Integrator (MIG) devices, the vendor-specific application note contains the point mapping information for the controller. Objects Control System (CS) Object 7

8 Automatic Creation of Model File CS Objects HVAC PRO software (Release 5.10 or later) and the GX-9100 Configuration software (Release 3.0 and later) generate a DDL model file when the configuration is saved. For HVAC PRO and GX-9100 software (Release 4.0 or later), you must select the Generate DDL on Save option when you save the configuration. This creates a model file with a.ddl extension for ASC and a.dmo extension for DX. For GX-9100, the file is generated automatically when you save the configuration, and it has a.dmo extension. The automatically generated model file includes all the defined points in the controller. To customize the model file, simply delete and modify points as needed. For more information, see the manual for the configuration tool you are using. Though the controllers have standalone capability, you most likely will want their points available for monitoring and control from the Metasys OWS and Network Terminal (NT). By mapping to the controller, the CS object allows you to monitor and control selected points in the ASCs. When you define software models (which are used as templates for CS objects), you can select exactly which points in the controller to monitor and control. There may be more than 50 points in the ASC; however, you may want to monitor only 20 of these points at the OWS. Up to 16 CS objects can reference one device. For example, one CS object can represent the points in the controller involved in temperature control. Another CS object can represent the points in the same controller involved in static pressure control. If more than one CS object is mapped to one device, each CS object must reference its own software model. IMPORTANT: When more than one CS Object is defined for one controller, each of these CS objects must reference a separate software model. Otherwise, commands may be lost if the Network Control Module (NCM) loses power or is downloaded. Also, if the same points are used in more than one model, only one model should allow the points to be commanded/adjusted. Otherwise, command conflicts can occur. 8 Objects Control System (CS) Object

9 Software Models Hardware Models Software Models A software model is a template for CS objects. The software model contains default values that make the process of defining CS objects consistent and efficient. For example, you might be setting up a facility that contains 100 VAV controllers that are exactly alike except for their system\object names. You can define one software model for all of these VAV controllers. Then, when you define the CS object for each controller, you simply reference the appropriate software model and specify a unique system\object name. Software models are explained in detail in this document, under the Software Models section. Hardware models are internal to the system software; they cannot be changed by the user, unlike software models, which are user-defined. There is a hardware model for each type of Application Specific Controller (ASC). This model is a list of all the points in the controller and their addresses, controller point types (e.g., AI, ADF, BI), and whether or not each point is commandable. The hardware model is used internally to check the validity of a software model (it is not user-defined or user-modifiable). For example, when you define a software model for an LCP, you are flagged with an error if you define an attribute as commandable when the point it is mapped to is not commandable in the hardware model. When you define a CS object, you must reference an already defined software model. The software model specifies exactly which point in the controller each CS object attribute is mapped to and whether each attribute can be overridden or adjusted. Define a software model either offline using DDL, or online at the OWS. Find information on defining a software model in this document, under Database Generation, and in the Operator Workstation User s Manual (FAN 634). Figure 2 shows a Software Model definition dialog box. Objects Control System (CS) Object 9

10 Software Model Summary - Add Analog Inputs Analog Outputs OK Analog Data Setpoints Cancel Binary Inputs Binary Outputs Binary Data Analog Inputs Undefined Attr Hdw Ref Ovr Adj Description Units AI_1 Ai2 Y Y MIXED TP DEGF AI_1 Ai2 Y Y MIXED TP AI_2 Ai3 Y Y DISCH TP AI_3 Ai4 Y Y ZONE TMP AI_4 Ai5 Y Y RET TEMP AI_5 Ai6 Y Y RET DP AI_6 Ai7 Y Y ZONE RH AI_7 Ai8 Y Y AHU STAT DEGF DEGF DEGF DEGF IN WG PCT IN WG cs2 10 Objects Control System (CS) Object Figure 2: Software Model Definition Dialog Box When you define the model, specify: the name of the software model the type of device the model is for (AHU, UNT, VAV, VMA, PHX, MIG, VND, NDM, LCP/DC9100, DX9100, DXECH, XT9100, DR9100, TC9100, XTM, LONTCU, LONTCUA, LONVMA, LONVMAA, LONDXA, LONDXAA, LONDXD, or LONDXDA). A software model is valid for only one device type. names for the attribute groups you intend to use. The names are required, and though they can include blank spaces, they cannot be all blank spaces. If you are defining the model online, you also specify how many attributes are in each group. Also specify the following for each attribute: a hardware reference, which is the address of the point in the controller the attribute is mapped to whether the attribute can be overridden whether the attribute can be adjusted

11 IMPORTANT: If you are mapping a CS object attribute and a standard object to the same hardware reference, set both the Override and Adjust flags to No (False) for the CS object attribute. Similarly, if you are mapping more than one CS object attribute to the same hardware reference, make sure only one has the Override flag set to Yes, and only one has the Adjust flag set to Yes. This is to ensure that there is only one command path to the hardware reference. a name for the attribute units for the attribute. For Binary Input (BI), Binary Output (BO), and Binary Data (BD), units are required, and though they can include blank spaces, they cannot be all blank spaces. For Analog Input (AI), Analog Output (AO), Analog Data (AD), and Setpoint (SP) attributes, units are not required, can include blank spaces, and can be all blank spaces. For Multistate (MS) attributes, at least one of the five units are required, and though it can include blank spaces, it cannot be all blank spaces. IMPORTANT: For MS attributes, the Software Model Definition dialog box (Figure 2), displays an additional column titled State. When defining a Software Model for a LONWORKS compatible device, you must enter the integer number that equals the state in the field under the State heading. For example, enter 0 for the first state and 4 for the fifth state. Leave both Units and State empty for unused states. Refer to the appropriate point mapping table in this document for the State integer equivalent. Automatic Creation of Model File HVAC PRO Release 5.10 or later and the GX-9100 Configuration software (Release 3.0 and later) generate a DDL model file when the configuration is saved. For HVAC PRO and GX-9100 software (Release 4.0 or later), you must select the Generate DDL on Save option when you save the configuration. This creates a model file with a.ddl extension for ASC and.dmo and.dnc extensions for DX. For GX-9100, the file is generated automatically when you save the configuration. The automatically generated model file includes all the defined points in the controller. To customize the model file, simply delete and modify points as needed. For more information, see the manual for the configuration tool you are using. Objects Control System (CS) Object 11

12 Attribute Groups The software model is made of eight groups of attributes: AI, AO, BI, BO, AD, BD, SP, MS. A software model can use all or only some of the attribute groups. When you define the model, you name the groups you intend to use. For example, you might name the group of AI attributes Analog Inputs or Temperatures. These user-defined groupings are provided to help organize information within the CS object. The eight attribute groups can be further split into two major types: hardware and internal. Table 3 summarizes the eight groups. Table 3: Attribute Groups Attribute Group Maximum Allowed in Software Model Hardware Analog Input (AI) 16 Analog Output (AO) 16 Binary Input (BI) 16 Binary Output (BO) 16 Internal Analog Data (AD) 32 Binary Data (BD) 32 Setpoint (SP) 32 Multistate (MS) 2 Attribute Sequence IMPORTANT: Consider the following information on attribute sequence carefully. Attributes of CS objects are position-dependent and are commanded by processes according to their sequence. If you change the sequence in the software model referenced by the CS object (e.g., by deleting an attribute), this might change a process or Weekly Schedule that references the attribute. In the software model attribute groups, the attributes are ordered sequentially. For example, the AI attributes are numbered AI_1 through AI_16, and the BI attributes are numbered BI_1 through BI_16. The attributes are position-dependent. For example, let s say you have a model defined with five AI attributes (AI_1 through AI_5). If, using DDL, you modify a model by deleting attribute AI_3, the point associated with AI_4 moves to position AI_3, and the point associated with AI_5 moves to position AI_4. In this case, if a process had been commanding AI_5, the command does not take effect because the point associated with attribute AI_5 is now associated with attribute AI_4. 12 Objects Control System (CS) Object

13 When you define the software model online at the OWS, this sequencing is clear because the attribute numbers appear on the screen. However, when you define the model with DDL, the sequence is indicated only by the order in which you define the attributes. For example, the first AI attribute you define is AI_1, and the second you define is AI_2, etc. Since commands to CS object attributes are based on attribute sequence, it is important that you know the sequence when writing processes. Also, if you change the order in the software model (e.g., by deleting a point), make sure you understand the new sequence and make any necessary modifications to processes or Weekly Schedules. Non- Commandable Points Software Model Database For the MIG and VND, all controller points can be commanded. This means you can set the Override and Adjust flags to Yes for any attribute mapped to any point in these controllers. However, only overrides and adjusts to AO and BO point types are actually sent to the vendor controller. For the AHU, UNT, VAV, VMA, PHX, NDM, System 9100 devices (e.g., LCP, DX9100), and LONWORKS compatible devices (e.g., LONTCU), only some points in the controller can be commanded. When you set the Override and Adjust flags to Yes in the software model, the system checks to make sure the point can be commanded in the controller. The point mapping tables in the Database Generation section of this document tell you which points can and cannot be commanded. Software models are part of the archive database, and reside in file on the PC. file must be compiled before file that contains CS objects referencing software models. In facilities with more than one OWS, make sure all workstations have the file. For more information on the software model database, refer to the DDL Programmer s Manual (FAN 630). Objects Control System (CS) Object 13

14 Modifying a Software Model You can modify the software model online at the workstation, or offline using DDL. You must again download the CS objects that reference the software model if you change the model; if you do not download these again, the CS objects do not reflect the changes. Note: Another option is to delete and re-add the CS object. With this procedure, there is no need for a new download to the NCM. IMPORTANT: Remember that attributes in software models are position-dependent, and that processes and features reference attributes according to their positions (e.g., AI_3, AI_4). If you change the sequence of attributes in a software model (e.g., by deleting an attribute), make sure you make the necessary changes to any processes or Weekly Schedules that reference the attributes. Changing the Software Model Database with DDL If you make changes to file with DDL, you must do the following for these changes to take effect in the CS object that references the model: 1. Make the changes to file. 2. Recompile file. 3. Recompile file containing the CS object. 4. Do a download to the NC containing the CS object. Changing the Software Model Online at the Workstation If you make changes to a software model online using the Software Model dialog boxes, you must do the following for these changes to be reflected in the CS object that references the model: 1. Change the model. 2. Upload from the NC containing the CS object. 3. Download to the NC again. Note: Another method is to delete and then re-add the CS object. Do not use the Copy feature when re-adding the CS object. Be sure that the CS object has the same name as before so no other links are lost (i.e., GPL). 14 Objects Control System (CS) Object

15 Engineering Overview Overview of Operation CS object software functions can be divided into six basic categories: Hardware Interface--The CS object attributes are mapped to hardware and internal points in the controller. Command Processing--Commands to attributes are processed by software functions such as command prioritization. Display Attribute--You define one attribute of the CS object to be the Display attribute. This attribute s value is displayed as the CS object s current value in the CS Object Focus window and in summaries containing the CS object. Change-of-State (COS) Reporting--Overrides to CS object attributes can generate advisories. Triggers--The offline state of the CS object and the CS object s binary attributes can trigger control processes. Optional Mapping to AD and BD Objects--To allow COS and alarm notification and triggers, and to enable Point History for individual CS object attributes, map the attributes to standard AD or BD objects. Objects Control System (CS) Object 15

16 Functional Flow Diagram The following flow diagram illustrates the general operation of the CS object. The blocks represent the functions performed by the software. Each block is summarized after the diagram and then explained in detail throughout the document. Hardware Interface Command Processing Display Attribute COS Reporting Triggers Optional Mapping to AD and BD Objects COS Reporting Triggers Point History and other Features csflow1 Figure 3: CS Object Functional Flow Diagram Hardware Interface CS objects map to the following devices: AHU, UNT, VAV, VMA, PHX, MIG, VND, NDM, LCP/DC9100, DX9100, DXECH, XT9100, XTM, DR9100, TC9100, and LONWORKS compatible devices. This mapping means the attributes of the CS object are associated with specific hardware and internal points in the controller. The hardware interface is determined by the: device type software model you reference when defining the CS object. The model specifies which point in the controller each attribute maps to. 16 Objects Control System (CS) Object

17 Device Specify the device when you enter the hardware system/object names for the CS object. The system containing the device must reside on the same NC as the system containing the CS object. The device type must match the type specified for the software model referenced by the CS object. IMPORTANT: When more than one CS Object is defined for one controller, each of these CS objects must reference a separate software model. Otherwise, commands may be lost if the NCM loses power or is downloaded. Software Settings for Hardware Interface Unreliable and Communication Status To specify the device and software model, set the following attributes: Hardware System Name--Enter the name of the existing system in which the device resides. There is no default. Hardware Object Name--Enter the name of the already defined device to which the CS object is mapped. There is no default. Software Model--Enter the name of the already defined software model. There is no default. Unreliable Status The CS object may become unreliable due to an offline condition (communication break) or faulty field hardware. When the CS object is unreliable, the following attributes also become unreliable--unless the attributes are overridden, in which case they maintain the last, highest priority override value. (A description of these attributes is in the Attribute Table section at the end of this document.) AI_1 - AI_16 BI_1 - BI_16 AO_1 - AO_16 BO_1 - BO_16 AD_1 - AD_32 BD_1 - BD_32 SP_1 - SP_32 MS_1 - MS_2 DISPLAY NTCMDISP BISTATES BOSTATES BDSTATES MSSTATES If these attributes appear in a control process, their unreliability affects the control process. The unreliability might be propagated and passed to other objects via commands and shared variables. You can write a control process that checks for unreliability. Refer to the GPL Programmer s Manual (FAN 631) for information on control processes. Objects Control System (CS) Object 17

18 To find out if the CS object is unreliable, look at its Focus window or summaries containing the CS object (e.g., a System Summary). The Current Value fields for unreliable and offline CS objects display???? instead of a value. (The Current Value for a CS object displays the value of the one attribute that was defined as the object s Display attribute.) Communication Status The Comm. Status field in the object focus window is used for both online/offline status and disconnect status. (Disconnect status applies to NDM applications only.) An object is considered offline when there is a communications break between the controller the object is mapped to and the NCM or NDM the controller is connected to. If an object is offline, OFFLINE appears in the Comm. Status field of the object s focus window. Figure 4 shows a Focus window for an object that is offline and unreliable. In addition, an offline object appears in the Offline summary. If it is an NDM application and the remote NDM is disconnected from the local NDM, DISCONCT appears in the Comm. Status field. If the NDMs are connected, either Online or Offline appears in the field, depending on whether the controller the object is mapped to is online. Figure 4 shows an example of a Focus window for an unreliable, offline CS object. Note that the Current Value field displays????. Control System Focus - ahumod2 Item E dit V iew Action G o To Accessory HDQTRS 4-Floor CSAHU10 CS for AHU at Address 10 4-Floor System Name Object Name Expanded ID Current Value Graphic Symbol # Operating Instr. # 4-Floor CSAHU-10 CS for AHU at Address 10???? 0 13 Hardware: System Name Object Name Model Name 4-Floor AHU10 ahumod2 Reports Locked Trigger Locked Comm. Disabled Comm. Status S/W Override Flags Auto Dialout N N N Offline N N Report Type OVERRIDE NONE Display Attribute Decimal Position BI_1 NT Command Attribute BO_1 Figure 4: CS Object Focus Window focunrel 18 Objects Control System (CS) Object

19 Command Processing IMPORTANT: When more than one CS object is defined for one controller, each of these CS objects must reference a separate software model. Otherwise, commands may be lost if the NCM loses power or is downloaded. Also, if the same points are used in more than one model, only one model should allow the points to be commanded/adjusted. Otherwise, command conflicts can occur. The attribute values of the CS object are determined by the: value of the controller point (hardware or internal) the attribute is mapped to commanded value (a result of an Override, Adjust, or feature command) change default for N2OPEN/N2B only (an operator entered value that goes to the controller s permanent memory considered at Priority 4). For all CS object attributes, the software reads the value from the controller, unless the attribute has been commanded from the workstation or NT, or by a process or Weekly Scheduling. IMPORTANT: For a CS object attribute to be adjusted by a process or feature (at Priority 2 or 3), the attribute s Adjust flag must be set to Y (Yes) in the software model referenced by the CS object. For an attribute to be overridden by an operator at the workstation or NT, the attribute s Override flag must be set to Y (Yes) in the software model. Commands provide a way for you to change the value of CS object attributes either from the workstation or NT, through execution of a process, or by Weekly Scheduling. If the NC or controller goes offline, the commands are restored when the NC or controller goes back online. From the NT, only one attribute from each CS object can be commanded (either overridden or adjusted). This attribute must be defined as the NT Command Attribute when the CS object is defined. Any defined attribute can be overridden or adjusted from the OWS. Objects Control System (CS) Object 19

20 There are four levels of commands, with Level 1 having the highest priority. The following table explains command levels. You ll find information on command syntax for processes in the JC-BASIC Programmer s Manual (FAN 632) and GPL Programmer s Manual (FAN 631). You ll find procedural information on commanding objects in the Network Terminal User s Manual (FAN 633) and Operator Workstation User s Manual (FAN 634). Note: The Weekly Scheduling feature issues commands at Level 3 (to the specified attribute). Table 4: Override/Adjust Command Levels Command Level Workstation and NT Name Process and MC Object Command Name Workstation Release NT Release 1 Override N/A Auto Auto N/A 2 N/A SETCSAN, SETCSBN, SETCSMS at Priority 2 (specify attribute) 3 Adjust SETCSAN, SETCSBN, SETCSMS at Priority 3 (specify attribute) Process and MC Object Release N/A N/A REL_CS at Priority 2 (specify attribute) Release N/A REL_CS at Priority 3 (specify attribute) 4 Change Default N/A N/A N/A N/A Level 1 Command (Override) A Level 1 command is issued at the workstation or NT with the Override command option. To release a Level 1 command, use the Auto command from the workstation or NT. This is the highest level command; no other command takes effect until an Auto command from the workstation or NT releases the Level 1 command. For an attribute to be commanded at Level 1, its Override flag must be set to Yes in the software model. Note: If the CS object goes offline, and an attribute is overridden, the attribute maintains the last, highest priority override value (instead of going unreliable). 20 Objects Control System (CS) Object

21 Level 2 Command (Adjust) Level 3 Command (Adjust) A Level 2 command is issued by a process or Multiple Command (MC) object that specifies a SETCSAN, SETCSBN, SETCSSP, or SETCSMS command, the attribute, and Priority 2. To release a Level 2 command, use the REL_CS command (in a process or MC object), specify the attribute to be released, and specify Priority 2. If the attribute is overridden from the workstation or NT, the Level 2 command does not take effect until the attribute is released by an Auto command from the workstation or NT. For an attribute to be commanded at Level 2, its Adjust flag must be set to Yes in the software model. The Level 3 command provides a method of changing the initial values sent to the controller when the NC initially comes online. The adjusted value becomes the initial value for the attribute and replaces the value resident in the controller. If the NC is uploaded after a Level 3 command, the workstation database also contains the new adjusted value as the attribute s initial value. If no commands are in effect, the initial value for the attribute is the actual value resident in the controller when the NC comes online. At the workstation, issue a Level 3 command with the Adjust command option, or with Weekly Scheduling. At the NT, use the Adjust command option. In a process or MC object, use the SETCSAN, SETCSBN, SETCSSP, or SETCSMS commands, and specify the attribute and Priority 3. Commands from Weekly Scheduling are always issued at Level 3. To release a Level 3 command from the workstation, use the Release command option. To release a Level 3 command from a process or MC object, use the REL_CS command, specify the attribute, and specify Priority 3. A Level 3 command cannot be released from the NT. (However, a Level 3 command issued from an NT can be released by a process.) If the attribute is commanded at Level 1 or 2, the Level 3 command does not take effect until the attribute is released. For an attribute to be commanded at Level 3, its Adjust flag must be set to Yes in the software model. You might not want operators to be able to change the initial values for certain attributes (e.g., those mapped to AD controller points) because you want these attributes to always reflect the actual value in the controller. In this case, make sure the Adjust flag for the attribute is set to No. Objects Control System (CS) Object 21

22 Level 4 Command (Change Default) Software Settings for Commands The Action - Operation dialog box offers an option to write the operator entered value for ASC (including VMA) devices directly to controller memory. This operation is a lower priority than the Override and Adjust command levels. Any command or adjust operation pending is displayed instead of the default value. The controller default is not re-issued upon controller power failure or reset. Whether or not an attribute can be commanded is determined by the software model the CS object is based on. In the software model, you set Override and Adjust flags to Yes or No for each attribute. IMPORTANT: A hardware reference must be commandable from only one path. If you are mapping a CS object attribute and a standard object to the same hardware reference, set both the Override and Adjust flags to No (False) for the CS object attribute. Similarly, if you are mapping more than one CS object attribute to the same hardware reference, make sure only one has the Override flag set to Yes, and only one has the Adjust flag set to Yes. This is to ensure that there is only one command path to the hardware reference. Override--Set the Override flag to Yes if you want the attribute to be overridden from the workstation or NT. Adjust--Set the Adjust flag to Yes if you want commands from processes or MC objects (Level 2 or 3), Adjust commands from the workstation or NT (Level 3), or commands from Weekly Scheduling (Level 3) to be issued to the attribute. If this flag is set to No, processes or MC objects cannot command the attribute at either Level 2 or 3, and you cannot adjust the attribute from the workstation or NT. In addition, Weekly Scheduling cannot command the attribute. 22 Objects Control System (CS) Object

23 NT Command and Display Attributes Software Settings for NT Command and Display Attributes When you define the CS object (not software model), you specify the following attributes: NT Command Attribute--At the NT, only one attribute from each CS object can be overridden or adjusted. Specify the one attribute that you want to be overridden (Level 1) or adjusted (Level 3) from the NT. Display Attribute--You define one attribute to be the CS object s Display attribute. The value of this attribute appears as the Current Value of the CS object in its Focus window, in summaries containing the CS object, and at the NT. For example, for a CS object representing a temperature control strategy, you might want the attribute measuring room temperature to be the Display attribute. Then, when the System Summary containing the CS object is displayed, the room temperature is displayed as the CS object s value. The value of the Display attribute also appears as the CS object s value at the NT. The Display attribute can be different from the NT Command attribute. This allows you to monitor two attributes at the NT. However, from the NT, you are able to command only the NT Command attribute. If the CS object is included in a dynamic graphic, it is the Display attribute s value that appears as the CS object s value. (You can also graphically represent other attributes of the CS object. See Defining Graphics in the Operator Workstation User s Manual (FAN 634) for more information.) You specify the Display and NT Command attributes in the CS Object Definition window. Use the attribute name and number as it appears in the software model (e.g., AI_1, AI_2, BI_1, BI_2). You can modify these attributes in the CS Object Focus window. Objects Control System (CS) Object 23

24 COS Reporting Software Settings for COS Reporting When a CS object first changes into an overridden state (that is, when an attribute is overridden from the workstation or NT and no other attributes are overridden), a report is sent to the destination specified by the report type (as long as reports are not locked and communications are not disabled). Likewise, when the last attribute is released from override, a report is sent. The report type (Critical 1-4, Follow-Up, Status, or None) is specified when the CS object is defined. While any attribute of a CS object is overridden from the workstation or NT (Level 1 command), an Override prefix (SWO) appears to the left of the CS object in summaries, and the CS object appears in the Override Summary. On the NT, an asterisk (*) appears next to the name of an overridden CS object. In the CS Object Focus window, an asterisk (*) appears to the left of attributes commanded at Level 1; a 2 appears to the left of attributes commanded at Level 2; and a 3 appears to the left of attributes commanded at Level 3. To allow COS reporting for CS object attributes, map the attributes to standard AD and BD objects. This optional function is described in this document, under Optional Mapping to AD and BD Objects. This section explains the attributes you set for COS reporting. For complete information on COS reporting, refer to the Report Router/Alarm Management Technical Bulletin (LIT ) in this manual, under the Feature Software tab. The following attributes affect COS reporting: Auto Dial-up specifies whether or not (Y or N) critical reports (Crit1-Crit4) force a dial-out to a remote OWS. If Auto Dial-up is not enabled, critical reports are stored at the NC until the buffer is full, at which time they are sent to the appropriate remote workstation. To enable Auto Dial-up, set this attribute to Y. To disable Auto Dial-up, set this attribute to N. N is the default. Report Type specifies the type of report that generate when the CS object first goes into an overridden state (when a Level 1 command is issued from the workstation or NT), or when the last attribute is released from an override. The options are: Crit1-Crit4, Follow-Up, Status, and None. The default is None. If you specify None, the override state change does not generate a report. Report type determines the destination and priority for reports. For example, all Follow-Up reports could go to an NCM printer. All Critical reports could go to both local and remote workstations, depending on how the report destinations are set up for your system. 24 Objects Control System (CS) Object

25 Reports Locked specifies whether or not (Y or N) the object sends COS reports. You can lock and unlock reports using the Lock and Unlock Reports commands. The Reports Locked attribute, displayed in the CS Object Focus window, signifies which command is currently in effect. Triggers Locking and Unlocking Triggers Optional Mapping to AD and BD Objects The following CS object attributes can trigger control processes: Offline DISCONCT (Disconnected) all binary attributes (BD, BI, BO) This means that when the CS object changes from online to offline (or offline to online), it can cause a control process to trigger (execute) if it is not exempted. Or, when one of the binary attributes of the CS object changes from Start to Stop (or On to Off), it can cause a control process to start (assuming that the trigger has not been exempted or that the attribute has changed state reliably). For further information on triggers and control processes, refer to the GPL Programmer s Manual (FAN 631) or the JC-BASIC Programmer s Manual (FAN 632). You can lock and unlock triggers with the Lock Triggers and Unlock Triggers communication commands. When you lock triggers, triggerable attributes cannot trigger processes. When you unlock triggers, these attributes can trigger control processes. The Triggers Locked attribute, displayed in the CS Object Focus window, indicates which command is currently in effect. Mapping a CS object attribute to an AD or BD object (as an associated input application) is optional and is not actually a part of CS object functionality. However, by mapping attributes to ADs and BDs, you can allow: alarm analysis and COS reporting triggers point history The following is a general description of the functionality you gain by mapping CS object attributes to AD or BD objects. You ll find complete information in the AD and BD object technical bulletins in this manual. Objects Control System (CS) Object 25

26 Alarm Analysis and COS Reporting Triggers Point History Currently, the CS object does not support alarm analysis--it reports offline and override states only. To allow these functions, map selected attributes to AD and BD objects. For example, to perform alarm analysis on an AI attribute, map the attribute to an AD object. Then set up limits for the AD object. The AI s value becomes the current value of the AD that is used or configured as an associated input object. If the AD s value exceeds its limits, a report can be sent to the appropriate destination. In this way, you are informed when the AI attribute exceeds the values specified by the AD limits. Currently, the triggerable attributes of the CS object are its OFFLINE and DISCONCT attributes, and all of its binary attributes (BD, BI, BO). You can enhance trigger functions by mapping attributes of the CS object to AD and BD objects. For example, to trigger a process as a result of an AI attribute exceeding a certain value (changing state), map the AI attribute to an AD object and set up limits for the AD object. The Status attribute of the AD object is triggerable. If the AD s value (actually the AI attribute s value) exceeds its limits, its Status attribute changes, and this can trigger a control process. There is no Point History data collection for the CS object. You can set up Point History for an attribute of the CS object by mapping the attribute to an AD or BD object. For example, to set up Point History for an AO attribute of the CS object, map the AO attribute to an AD object. Then enable Point History for the AD. The AD object s Focus window displays Point History and Current Trend data for the AD (which is associated with the AO attribute of the CS object). Notes: Issuing a command (override or adjust) to an AD or BD object does not cause the associated CS object attribute value to change. If overrides/adjusts are issued to the AD or BD object, this object s point history records overrides/adjusts that do not reflect overrides/adjusts issued to the associated CS object attribute. Consider that extensive use of AD and BD objects can increase N2 Bus traffic and slow down COS reporting (because every 4 seconds all BD values are read and every 30 seconds all ADs are read.) 26 Objects Control System (CS) Object

27 Database Generation Overview Mapping Points in the Controller to Software Model Attributes This section provides instructions for the overall process of mapping CS objects to controllers. This process includes defining the controller, creating a software model, and defining the CS object. Before you define a CS object, make sure you understand the concepts discussed in the Introduction section. This section tells you how to map points in the controller to software model attributes. To do so, you need a printout of the points in the controller. Table 5 lists the file or document you need to print for the different controller types. Table 5: Controller and Configuration Software Controller M-Tool Software Configuration File AHU, UNT, VAV, PHX, NDM VMA LCP/DC9100 DX9100, XT9100 DXECH (DX-912x) XTM Protocol HVAC PRO Software.PRN file* N2OPEN HVAC PRO Release 7.0 or higher LCP Configuration Release 3.2, or GC-9100 Release 3.2 GX-9100 GX-9100 Release 4.01 or higher XTM Configurator Release 3.01.PRN file*.gps configuration file.dxs configuration file.dxs configuration file.dbf and.hmc configuration files N2B System 9100 System 9100 Echelon (N2E) System 9100 DR9100 SM-9100 Module N/A System 9100 TC9100 HVAC PRO Software.PRN file System 9100 MIG, VND N/A Vendor-specific application note LONWORKS Compatible Devices Refer to device-specific documentation. See device mapping table N2OPEN LONWORKS * HVAC PRO software produces a.prn file. DOS versions of HVAC PRO software produce a.sym file. For the AHU, VAV, VMA, PHX, NDM, and TC9100, refer to the HVAC PRO User s Manual (FAN 637.5) for information on generating printouts. Objects Control System (CS) Object 27

28 For DX, XTM, and XT9100 controllers, see the configuration tool manuals for information on printouts (e.g., for information on printing the.dxs file for a DX9100, see the GX-9100 Software Configuration Tool User s Guide (LIT ) in the System 9100 Technical Manual (FAN 636.4). Note: Mapping points in MIG and VND devices (the vendor controllers you are integrating with the Metasys Integrator unit) is the same as mapping points in any other ASC. For these devices, you ll also need the vendor-specific application note, which contains point mapping tables for the vendor s controller. For example, if the vendor controller is a Fireye device, use the point mapping tables in the Metasys Integrator Fireye Application Application Note (LIT ). The specific information you need from the printout and configuration file is the hardware reference (point type and point number) for the controller point. You ll use the controller point s hardware reference when mapping a software model attribute to the controller point. Automatic Generation of Model File.PRN Files HVAC PRO software (Release 5.10 or later) and the GX-9100 Configuration software (Release 3.0 and later) generate a DDL model file when the configuration is saved. For HVAC PRO and GX-9100 (Release 4.0 or later) software, you must select the Generate DDL on Save option when you save the configuration. This creates a model file with a.ddl extension for ASC and a.dmo file for DX. For GX-9100 (Release 3.0), the file is generated automatically when you save the configuration, and it has a.dmo extension. The automatically generated model file includes all the defined points in the controller. To customize the model file, simply delete and modify points as needed. For more information, see the manual for the configuration tool you are using. For AHU, UNT, VAV, VMA, NDM, TC9100, and PHX controllers, the.prn file is automatically created when you save the controller s configuration using HVAC PRO software, when the Generate.PRN on Save option is selected. The.PRN file can be printed from any text editor, or from within HVAC PRO software by selecting File, Print. Refer to the HVAC PRO User s Manual (FAN 637.5) for more information. Note: If you are using HVAC PRO for DOS software, the file has a.sym extension. 28 Objects Control System (CS) Object

29 Once you have the hard copy of the.prn (or.sym) file: 1. Highlight the points you want to include in the software model. Note the hardware reference for each point you are including. The hardware reference is the combination of the point type and point address as shown in the.prn file. 2. Look at the AHU, UNT, VAV, VMA, NDM, TC-9100, and PHX point mapping tables in this document to determine which software model attributes the hardware references can be mapped to. System 9100 Configuration File For the System 9100 devices, print the file by loading the controller s configuration into the configuration software. For the GX-9100 Release 3.0 or later, select the following menu options: FILE, PRINT, ALL ITEMS. (For earlier versions, select SYSTEM, PRINT, ALL DATA.) Once you have a hard copy of the configuration file: 1. Highlight (e.g., with a yellow marker) the points you want to include in the software model. 2. Note the description of the points you are including. For example, Analog Input #1 is the description of an analog input hardware point. Proportional Band is the description of the proportional band internal point of a control module. 3. From the description, use the appropriate point mapping table either in this document or in the appropriate technical bulletin to determine the hardware reference for the point, whether the point can be commanded, and which software model attributes the point can be mapped to. The following example shows portions of the DX configuration file. The commentary (in italics) to the left of the sample printout gives additional information on how to read the descriptions in the file. Objects Control System (CS) Object 29