Std Programming Reference

7/22/2019 Std Programming Reference

http://slidepdf.com/reader/full/std-programming-reference 1/525

Tridium, Inc.

3951 Westerre Parkway • Suite 350

Richmond, Virginia 23233

USA

http://www.tridium.com

Phone 804.747.4771 • Fax 804.747.5204

Technical Publications

Niagara Standard

Programming

Reference

Niagara Release 2.3.5

Revised: April 20, 2004

http://www.tridium.com/

http://www.tridium.com/



Copyright Notice: The software described herein is furnished under a license agreement and may be used only in

accordance with the terms of the agreement.

© Copyright 2004 Tridium, Inc. All rights reserved.

This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic

medium or machine-readable form without prior written consent from Tridium, Inc., 3951 Westerre Parkway, Suite 350,

Richmond, Virginia 23233.

The confidential information contained in this document is provided solely for use by Tridium employees, licensees, andsystem owners; and is not to be released to, or reproduced for, anyone else; neither is it to be used for reproduction of this

Control System or any of its components.

All r ights to revise designs described herein are reserved. While every effort has been made to assure the accuracy of this

document, Tridium shall not be held responsible for damages, including consequential damages, arising from the application

of the information given herein. The information in this document is subject to change without notice.

The release described in this document may be protected by one of more U.S. patents, foreign patents , or pending

applications.

Trademark Notices: BACnet and ASHRAE are registered trademarks of American Society of Heating, Refrigerating and

Air-Condit ioning Engineers. Microsoft and Windows are registered trademarks, and Windows NT, Windows 2000,

Windows XP Professional, and Internet Explorer are trademarks of Microsoft Corporation. Java and other Java-based

names are trademarks of Sun Microsystems Inc. and refer to Sun's family of Java-branded technologies. Communicator and

Navigator are registered trademarks of Netscape Communications Corporation. Echelon, LON, LonMark, LonTalk, andLonWorks are registered trademarks of Echelon Corporation. Tridium, Niagara, the Niagara Framework, Vykon,

WorkPlace Pro, Web Supervisor, JACE-4, JACE-5, JACE-NP, and JACE-NX are trademarks of Tridium Inc.

All other product names and services mentioned in this publication that are known to be trademarks, registered trademarks,

or service marks have been appropriately capitalized and are the property of their respective owners.

Niagara Standard Prog ramming Ref erence

Copyright © 2004, Tridium, Inc.

All r ights reserved.




Niagara Standard Programming Reference Revised: April 20, 2004ii i

P R E FA C E About This Document ix

Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Prerequisite Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Commonly Used Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi i

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Document Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

CHA P T ER 1 Station and Objects 1-1

A Station Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Niagara Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Object Model (Integration Platform) . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Object Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Object Name and SWID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Object Names (and Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Object Swid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Object Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Object Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Object Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Station Limits and Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

Monitoring JACE-NX, JACE-NP Environment Variables . . . . . . . . 1-27

Niagara Properties Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27

Host > Edit File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28

Archiving Properties Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30

List of Niagara Properties Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31

CHA P T ER 2 Data Species and Links 2-1

Data Species . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

C O N T E N T S




Niagara Standard Programming Reference Revised: April 20, 2004iv

Contents

Data Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Data Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Variable Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Property Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Link Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Link Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Link Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

Link Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Link Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Link Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

CHA P T ER 3 Commands and Views 3-1

Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Admin Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

All Available Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Standard Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

Special Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

All Available Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

CHA P T ER 4 Services 4-1

About Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Core Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Additional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

General Notes on Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

About Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Adding or Removing Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Common Service Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

AuditLogService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

BackupService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

ControlEngineService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

DatabaseService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

ErrorLogService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28

LogService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

MailService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36

NotificationService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39




Niagara Standard Programming Reference Revised: April 20, 2004

Contents

v

PollArchiveService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41

TimeSyncService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45

UiEngineService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

WebUiService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49

CHA P T ER 5 Control Objects 5-1

About Control Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

BACnet Heritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Selecting Control Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Common Control Object Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Trigger Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Debug Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

About Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

Common Control Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

Event-Type Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

AnalogInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15

AnalogOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23

AnalogOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29

BinaryInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33

BinaryOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42

BinaryOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53

Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57

Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-59

CpAnalogNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62

CpBinaryNode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-65

CpIntegerNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67

CpStringNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69

DateTimeTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71

FunctionGenerator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-73

IntToFloat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77

Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79

Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-83

Math. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-95

MultistateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-101

MultistateOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-112

MultistateOverride. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-124

PeriodicTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128

Totalizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-130




Niagara Standard Programming Reference Revised: April 20, 2004vi

Contents

CHA P T ER 6 Apps Objects 6-1

About Apps Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

BACnet Heritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Selecting Apps Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Common Apps Object Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

Common Apps Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

Log Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7

AdminTool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18

AnalogLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

BinaryLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32

Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35

IntegerLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41

MultistateLog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44

Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47

Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-52

StringLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-60

CHA P T ER 7 Container Objects 7-1

About Container Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Tree View Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Container Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Inputs and Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Layers in Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Browser Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Common Container Object Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Security Groups and Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Alarm and Alert Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Common Container Object Properties. . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Containers That “Composite” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

To Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Or Not to Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14

Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19

Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22

GxPage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24

PollAlways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29





Contents

vi i

PollOnDemand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31

ServiceContainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34

CHA P T ER 8 Gx Objects 8-1

About Gx Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Execution of Gx Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Gx Object Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Common Gx Object Things. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

Common Gx Object Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

General Gx Object Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

GxBarGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10

GxBoolean. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13

GxDamper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16

GxFan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18

GxFloat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

GxImage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

GxInteger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24

GxPipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26

GxSpectrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28

GxText. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30

GxTimePlot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33

CHA P T ER 9 Notification Objects 9-1

About Notification Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Recipients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Notification Schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Linking Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Common Notification Object Properties . . . . . . . . . . . . . . . . . . . . . . . 9-4

NotificationClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

ApiRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

MailRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9

PrinterRecipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13

RemotePrinterRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15

SnmpRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17

VasRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18




Niagara Standard Programming Reference Revised: April 20, 2004viii

Contents

CHA P T ER 10 Ndio Objects 10-1

About Ndio Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Ndio Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Ndio Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

Processor Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

Ndio UI objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5

Ndio outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

Common Ndio Object Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

General Ndio Object Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

NdioContainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10

NdioProcessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11

Ndio0to10VInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13

Ndio0to10VOutput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

NdioBinaryInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

NdioBinaryOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24

NdioHighSpeedCounterInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29

NdioResistiveInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33

NdioThermistorType3Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37

A P P END I X A Object Property Quick Reference A-1

Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Attribute Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Attribute Notation Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Property Quick References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

Resource Count Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-61

I N D EX




Niagara Standard Programming Reference Revised: April 20, 2004ix

About This Document

This document is intended to help you understand and use the standard Niagara

object set for programming a Niagara station. Included is reference information for

all objects in the standard tridium JAR, plus those in the tridiumx, ndio JAR.

This preface includes the following sections:• Intended Audience

• Prerequisite Knowledge

• Document Summary

• Formatting Conventions

• Commonly Used Terms

• Related Documentation

• Document Updates

Intended AudienceThe following people should use this document:

• Vykon systems integrators and installers responsible for initial setup and

ongoing configuration of JACE controllers and Web Supervisors.

• Vykon application programmers.





Preface About This Document

Prerequisite Knowledge

x

Prerequisite KnowledgeReaders of this document should know or have experience with the following:

• Basic Niagara concepts, such as stations, nodes (objects), properties and links.

• Niagara’s Java Desktop Environment (JDE, formerly called WorkPlace Pro),including the necessary tasks to provide system control and user interface.

Ideally, you should be Niagara-certified, that is, have successfully passed

Tridium’s formal Niagara Technical Certification Program.

Document SummaryThis document contains ten chapters and an appendix, summarized below.

Chapter 1, “Station and Objects,” —Provides an overview of how objects define a

Niagara station. Reference information is provided on the Station object. Also

included are some approximate limits and guidelines for station resources.

Chapter 2, “Data Species and Links,” —Provides an explanation of the data types

(data species) that object properties use. Information about links between input and

output properties is also included.

Chapter 3, “Commands and Views,” —Provides general explanations of commands

available in Niagara objects, plus available object views.

Chapter 4, “Services,” —Provides reference information on each of the standard

Niagara service objects, including property descriptions and available views.

Chapter 5, “Control Objects,” —Provides reference information on each of the

standard Niagara control objects, including property descriptions.

Chapter 6, “Apps Objects,” —Provides reference information on each of the standard

Niagara apps (application) objects, including property descriptions.

Chapter 7, “Container Objects,” —Provides reference information on each of the

standard Niagara container-type objects, including property descriptions.

Chapter 8, “Gx Objects,” —Provides reference information on each of the standard

Niagara Gx (graphical interface) objects, including property descriptions.

Chapter 9, “Notification Objects,” —Provides reference information on each of the

standard Niagara notification objects, including property descriptions.

Chapter 10, “Ndio Objects,” —Provides reference information on each of the Ndio

(Niagara direct input/output) objects, including property descriptions. These objectsare used if engineering a JACE with onboard I/O or with an I/O expansion module.

Appendix A, “Object Property Quick Reference,” —Includes a quick reference table

for each Niagara object type, listing all properties. Each property row shows the

property sheet tab, data species used, and attributes (read/write, user level).

Reference information on all data species (variable types and enumerations) is also

included.

An Index provides alphabetical reference to important topics in this manual.




Formatting Conventions


Niagara Standard Programming Reference Revised: April 20, 2004xi

Formatting ConventionsThis document uses the following text formatting conventions:

• Bold text indicates an important keyword, user entries, and so forth.

• CAPITAL letters are used for acronyms, such as WPP (WorkPlace Pro). Theyare also used to identify keyboard keys in instructions, such as press ENTER

or press CTRL-C.

• Italic text is used for emphasis. It is also used to refer to the titles of other

publications and document filenames.

• Italic text also appears for non-literal text that represents a variable, for

example, station_name or DONOFF_ n.

• “Quotation marks” are used to refer to other sections within the document.

• <text between brackets> means a variable placeholder or part of a general

running commentary, for internal Tridium use only.

Important Information Indicators

In addition to text formatting, this document uses two types of important information

indicators and three types of additional information indicators, as listed below:

Note Notes typically contain significant details related to the topic in the nearby text. They

alert you to important information that might otherwise be overlooked.

Caution Cautions remind you to be careful. There is a chance that you could perform an

action that cannot be undone, might produce unexpected results, or might cause lost

data. Cautions typically explain why the action is potentially problematic.

Addit ional Information Indicators—The following note additional information:

Refer to “Refer to” references point to other documents that contain additional information

on the current topic. The reference includes the name of the document, and if

applicable, the chapter name and number where the additional information appears.

Tip Means a best practice or other helpful instruction. Tips typically containrecommendations that will help you use the product more effectively.

Timesaver Means a shortcut. Timesavers typically tell you a quicker or shorter way to

perform a task. They might include keyboard combinations or buttons that can

be used instead of menu selections to perform the same action.






Commonly Used Terms

xi i

Commonly Used TermsThroughout this document, references are made to acronyms and terms encountered

with most any Niagara station. This section provides definitions for these terms and

is intended to ensure their consistent use.

active Generic term for one of two binary (boolean) states, typically synonymous with

“On,” “Run,” or “True.” The complimentary term is inactive.

Admin Tool The Niagara Framework software tool used for local and remote station

administration, including starting and stopping stations, station database

management, upgrades, and license file installation. Also provides network, user, and

time configuration for the selected host, and a Standard Output window used for

station troubleshooting. The Admin Tool can be run from inside the JDE, or as

standalone application. Not to be confused with the AdminTool object .

alarm An “off-normal” condition for an object when it meets alarm criteria, such as alarmlow (analog) or alarm state (binary or multistate). Alarms occur in event-type objects.

Alarm (as a term) also applies to alarm-type exception messages, which can be

generated upon detection of an alarm condition.

alert A “warning”-type exception message generated when an object reaches some

predefined limit, for example, hours of runtime or COV , COS count limit.

analog Data represented by a continuously-variable value, typically a floating-point (float).

Control object types AnalogInput, AnalogOutput, and AnalogOverride (among

others) use analog data.

apps objects Application objects. A class of Niagara objects that include global control objects

(Calendar and Schedule), various data logging (log) types, and the Program object.

BACnet® Building Automation Controls network. An ASHRAE®-developed “open”

communications protocol designed for the HVAC controls industry, where data is

modeled using a common set of “objects” and a standard set of “services.” Many

Niagara object types are closely modeled after BACnet objects. By default, all JACE

controllers are equipped for integration into a BACnet device network.

binary Data represented by only two discrete states (boolean), either active or inactive.

Control object types BinaryInput, BinaryOutput, and BinaryOverride (among others)

use binary data.

child object In general Niagara terms, any object contained inside another object’s Workspace.

A child object can be a primitive object or a container object (with its own children).

A primitive object is always a child object.




Commonly Used Terms


Niagara Standard Programming Reference Revised: April 20, 2004xiii

commands A station-user can give a command to a selected object to perform some predefined

action. Commands are either control-related (On, Off, setpoint adjust, etc.) or

administrative (clear log buffer, backup station database, etc.), depending on the

object type. The user requires command (security) privileges for that object.

container object If all lowercase (container), it refers to any Niagara container-type object, includingBundle, Composite, Container, GxPage, PollAlways, and PollOnDemand types. All

typically contain child objects. If capitalized (Container), refers to that specific type.

control objects A class of Niagara objects that provides a common object model for defining data and

control sequences, including alarm monitoring. Combinations of control objects and

shadow objects (plus apps objects) are typically referred to as control logic.

COV, COS Change-of-value, change-of-state.

data species Niagara data types, of which there are many. Data species include primitive data

types, data enumerations, and structured data types (variable types). Each property ofa Niagara object is implemented with a specific data species.

dependencies Requirements, particularly for child-parent relationships between object types. For

example, service objects have a parent dependency of (only) the ServiceContainer.

GxPage (container) objects have child dependencies of (only) Gx objects.

enumerations An enumeration is a numbered list of integers, where each number corresponds to a

specific state, condition, or other meaning (within that number group). An example

enumeration is 0 through 6 for the days of the week (Sunday through Saturday).

events Generally, an event is an exception to a normal condition or normal operation. A

number of control object types are event-type objects, meaning that they are capable

of generating an alarm (and in some cases, an alert).

inactive Generic term for one of two binary (boolean) states, typically synonymous with

“Off,” “Stop,” or “False.” The complimentary term is active.

input An object property designed for linking to the output of another object. Data received

on an input is typically used in the object’s algorithm (purpose).

JAR file Java ARchive file. A file format used to package all components required by a Java

application. Class files, images, sounds, etc., can be bundled into a single file. In

addition, JAR supports run-time data compression, which decreases download times. Niagara software modules install as JAR files.

Because component files remain packaged inside JAR files, a “virtual” file system is

seen in the Local Library —the tridium JAR and tridiumx folder cannot be found

directly in Windows Explorer, for example. In the case of the tridium JAR,

components reside mostly in the “\nre\modules\coreRuntime<release>.jar” file. To

simplify, however, this document refers to the tridium JAR file and tridiumx folder.






Commonly Used Terms

xiv

JDE Java Desktop Environment. The Niagara Framework PC application used to engineer

station databases, using objects described in this document. The JDE can also be used

to monitor stations. Formerly referred to as WorkPlace Pro (WPP).

links Data connections between objects, where each link connects the output of one object

to the input of another object. Links are the basis for data sharing, integration, andcontrol sequences. Links are engineered in the JDE using the Link Editor. Depending

on its category and type, each link appears in the JDE as a line or a pair of link boxes.

Local Library Folders and files that can be accessed through the Tree View of the JDE workstation.

All are local (on the workstation), and are located under the niagara\<release>

directory. Access includes actual directories, such as “stations,” plus “virtual”

resources, such as the tridium JAR file and tridiumx subfolder. Files and directories

can be created, deleted, copied, and moved as needed. Also see Remote Library.

LonWorks® The collective hardware and software technology originally developed by the

Echelon corporation. LonWorks provides an off-the-shelf, peer-to-peer, networking

platform for designing interoperable control networks. By default, JACE controllers

support a LonWorks network, using a LonWorks FTT-10 connection point.

multistate Similar to binary data (two discrete states), but with three or more discrete states. For

example, a two-speed fan has three multistate values: Off, On, Fast. Control object

types MultistateInput, MultistateOutput, and MultistateOverride use multistate data.

object In the context of Niagara, object can refer to a node at the lowest level of station

database hierarchy, such as a control object or apps object. In other words, a primitive

object. However, because the term node is also widely-used to mean a networked

device (particularly for LonWorks), this document consistently uses the term object

instead of node. This usage applies to the top-level Station object, and all childobjects that make up a station database.

object types Niagara objects are of particular known types. For readability purposes, leading and

internal caps are used when referring to object types—for example, AnalogInput,

GxPage, FunctionGenerator, and so on.

output An object property designed for linking to the input of another object. Data produced

at an output typically reflects the results of the object’s algorithm (purpose).

Ndio Niagara direct input/output. Niagara software module used by a station for a JACE

model with onboard I/O (JACE-4). Contains special control objects known as NdioObjects, used to interface with the hardware I/O points.

node Within the context of Niagara, nodes are synonymous with objects, where node

sometimes means a container-type object. Node is the common base class for all

Niagara objects. Node constructs are similar to JavaBean characteristics—each has

properties, a set of methods exposed to other objects, and events that can be fired.

Please note that this document consistently uses the term object instead of node.




Commonly Used Terms


Niagara Standard Programming Reference Revised: April 20, 2004xv

parent In general Niagara terms, a child object’s particular container (object). Refers to the

hierarchy of objects in a station database. For example, the Station object is the parent

of the ServiceContainer object. A primitive object is never a parent.

primitive In the context of objects, a primitive object is any object that is not a container—for

example, a control object, apps object, Gx object, or a notification object. Note that primitive does not mean “crude” however, as many primitive objects are quite

sophisticated (Loop or Schedule object, for example).

In the context of data species, a primitive is the most fundamental type of data.

Primitive data types are either boolean, float, integer, or string.

properties A property is a component of an object, representing some piece of data. Most objects

have both internal properties (configuration, status, visual, and security types) as

well as linkable properties (input properties and output properties).

resource count A measure of storage for objects in a station, where each object consumes some

number of resources. Roughly equivalent to RAM, resource counts relate directly to

“Java handles and objects” used by the station’s JVM (Java virtual machine). Each

object description in this document lists the object’s Resource Count Range.

Remote Library Folders and files on a remote JACE host that can be accessed through the Tree View

of the JDE. Access includes actual directories, such as “stations,” plus “virtual”

resources, such as the tridium JAR and tridiumx subfolder. Files and directories can

be created, deleted, copied, and moved as needed.

service A special class of Niagara object that publishes itself to other objects in the station,

providing specialized routines and functions. Every station has some number of core

services plus additional (optional) services.

sns Serialized Node Set (SNS). A compact file format for storing a station database (or a

portion, in the case of a container object copied to the Local Library).

Standard Output An Admin Tool option providing a special window to view and save a running

station’s activity. Standard Output displays JVM station requests and responses in

real time, including station startup messages. It is typically used for troubleshooting.

Standard Output also works with “debug” modes of various Niagara services.

station The JVM that hosts the running of objects, plus a station database containing all

object configuration. Provides the environment to configure, manage, and run a

single database of objects and the services required to support a control application.

swid System-wide identifier, or SWID (To improve readability, common usage is swid).

Each object (whether container, service, control object, etc.) in the station has a name.

Since all objects are part of a Station’s tree, names can be concatenated together to

create a unique system-wide identifier (swid), much like a path in a file system.

Syntax for a swid follows standard URL naming conventions, for example:

ht t p: / / <host nameOr I P>/ db/ <st at i onName>/ <cont ai nerName>/ <obj ect Name>






Commonly Used Terms

xvi

Tree View The left portion of the JDE window, showing the hierarchical structure of the station

database. Tree View in the JDE operates much like Windows Explorer, where you

expand container (parent) objects to see subordinate child objects. Tree View

timestamp Time (and date) stamp, typically generated within an object’s historical records. For

example, timestamps are included in samples of log objects (logs) and various status properties related to system or object actions, such as “timeOfStateCountReset.”

trigger An event-based data-sharing method, where a trigger-type output can be “fired,”

either by a user-command or a predetermined event. Receipt of a trigger pulse at a

linked trigger-type input results in that object performing some predetermined

function. This is a different model than used for most data sharing, as it is not

value-based . Most control and apps objects have at least one trigger property.

URL Uniform Resource Locator. The global address of a document or other resource.

Within the context of Niagara, a URL is similar to a swid . A swid defines a particular

object or resource in a station database, whereas a URL can include a swid or a

resource located elsewhere.

views Objects have views, each of which provide access to characteristics of the object. All

objects have a Properties view and Links view, for example. Container objects have

a Workspace view and WorkplaceEditor view. These are standard views. Some

objects also have special views. For example, a Calendar object provides a Calendar

view, to graphically review and edit holiday dates.

Web Superviso r The Niagara station (at a job) that runs on a PC, configured as the Supervisor station

(archive destination) for any networked JACE controllers. Typically this PC is also

running full suite of Niagara applications, including the JDE and the Alarm Console.

WebUiService Web User Interface Service. The Niagara service required by a station to provide a

full set of views to its objects when using a Web browser connection. The

WebUIService is a suite of servlets that use HTML and Java applets to provide a

browser user interface (BUI) to station data.

Workspace The runtime view for any container object, as it appears in the right side of the JDE

window. Also called monitor mode, it is where values update in real time and user

commands to child objects can be given.

WorkspaceEditor The edit view for any container object, as it appears in the right side of the JDE

window. Also called edit mode, it is where objects can be added, deleted, modified,linked and unlinked.




Related Documentation


Niagara Standard Programming Reference Revised: April 20, 2004xvii

Related DocumentationFor additional information, please refer to the following other Niagara Technical

Publications:

• Niagara Concepts Guide —Explains the various concepts and tools thatcomprise the Niagara Framework. This document is a good starting-point for

anyone new to Niagara and the JDE (Java Desktop Environment).

• JDE User’s Guide —Explains how to use the JDE, including the Admin Tool

and the Alarm Console. Procedures for common tasks used in engineering and

monitoring Niagara stations are provided.

• Using the Niagara Admin Tool —Explains features and tasks performed in the

Admin Tool, which can be run either standalone or within the JDE.

• Niagara Networking & Connectivity Guide —A complete guide on Ethernet/IP

networking, including configuration details for any Niagara host, firewall

considerations, modem (dialup) setup, reference data, and troubleshooting tips.

• Niagara Web Solutions Guide —Provides information about engineering a Niagara station optimized for web browser access. Discusses GxPages, HTML

templates and framesets, and other features provided by the WebUIService.

• Niagara BACnet Integration Reference —Provides details on engineering a

station with the BACnetService, including BACnet client operation (shadow

objects) and BACnet server operation (exposing standard Niagara objects).

• Niagara Modbus Integration Reference —Provides details on engineering a

station with any of the Modbus integration services, namely ModbusAsync,

ModbusTCP, and ModbusSlave. Includes reference data on all shadow objects.

• Niagara System and Power Monitoring, Engineering Notes—Provides details

on “sysmon” configuration for the JACE-NP and JACE-NX platforms,

including special shadow objects found in the tridiumx/systemMonitor JAR.

Document UpdatesUpdates to this document are listed below.

Date Update, Notes

11/15/2001 Initial document revision for Release 2.2.

05/09/2002 Revised document for Release 2.3.

05/14/2002 Minor update, still Release 2.3.

09/30/2002 Various corrections, still Release 2.3.06/13/2003 Initial document revision for Release 2.3.4.

For details about changes in Release 2.3.4 from the previous release, please referto the Release Notes document for Niagara r2.3.4.

03/24/2004 Initial document revision for Release 2.3.5. Object coverage expanded to include“CpStringNode,” page 5-68, “VasRecipient,” page 9-18, as well better details onengineering units (“About Units,” page 5-6). Various other small changes.

For details about changes in Release 2.3.5 from the previous release, please referto the Release Notes document for Niagara r2.3.5.






Document Updates

xviii

04/14/2004 Revision. Minor change in Note about entering characters plus (“+”) or semicolon(“;”) in edit dialog of CpStringNode object when using a browser connection.Pagination remains unaffected.

04/20/2004 Revision. Minor change in Appendix A, “Object Property Quick Reference,” adding

enum type “DatabaseTypeEnum” and updating DatabaseService properties list.

Date Update, Notes





CHAPTER

1–1

1

Station and Objects

A Niagara station runs in a JVM executing a station database defined by nodes

(objects). What makes one station unique from another is the specific collection of

objects used, their specific configurations, and their defined relationships.

Although every station database will be unique, the object building blocks used are

common and reusable. In addition, the way information is structured in a Niagara

station follows a definite pattern—whether primitive values, property structures,

object entities, or services provided.

This section provides the following main topics:

• A Station Overview

• Niagara Objects

– Object Model (Integration Platform)

– Data Modeling

– Object Hierarchies

• Object Name and SWID– Object Names (and Rules)

– Object Swid

• Object Categories

• Station Object

– AddressBook View

– UserAdmin View

– ActiveUsers View

– Alarms View

• Station Limits and Guidelines

• Monitoring JACE-NX, JACE-NP Environment Variables

• Niagara Properties Files





Chapter 1 Station and Objects

A Station Overview

1–2

A Station OverviewA Niagara station runs in a specific host, the platform being either a JACE controller

(JACE-NP, JACE-NX, JACE-5, JACE-4) or a Web Supervisor (PC). With few

exceptions, the target host platform makes little difference in how you use the JDE to

engineer a station database. The same standard Niagara objects and libraries apply.

One notable exception is the DatabaseService, which provides an SQL application

database for archiving log data, alarms, and alerts. Due to the significant storage

requirements for archiving this data, the DatabaseService cannot run in a JACE-4/5

station. However, any Niagara station (including one in a JACE-4/5) can be

configured to archive remotely to another Niagara station running the

DatabaseService. Typically, the archiving station is the Web Supervisor.

Another notable exception is the ndio module (Ndio objects), which provide the

station interface to the physical onboard I/O points on a JACE-4 or JACE-IO

expansion module (or any future JACE model with onboard I/O). Currently, Ndio

applies only to a JACE-4 station.




Niagara Objects


Niagara Standard Programming Reference Revised: April 20, 20041–3

Niagara ObjectsObjects are the building blocks of a Niagara station database. Each object type is a

defined data structure with a predictable behavior. Objects represent every level of

the database, starting with the “root” Station node (object).

Each object is a collection of properties. Depending on its type, each object also has

some number of available commands or special views. Objects can be linked to other

objects, where links provide sharing of data and control.

In the JDE, each object has a right-click Property Sheet and Links Sheet to access

properties and links (Go > Properties and Go > Links). Detailed information about

object properties, commands and views, and links is provided in subsequent chapters

about specific object types.

The following topics apply to a general understanding of Niagara objects:

• Object Model (Integration Platform)

• Data Modeling• Object Hierarchies

• Object Name and SWID

• Object Dependencies

Object Model (Integration Platform)

A Niagara station uses a common object model to provide an integration platform for

exchange of information with foreign devices, including a common user interface.

The different libraries of Niagara objects include “standard” objects, described in this

document, plus other integration objects, such as LonWorks and BACnet objects.

Integration objects expose foreign devices (and contained information) using thesame familiar patterns used by standard objects. In general, most integration objects

“shadow” devices and/or values in devices that are physically networked with a

JACE controller. For this reason, integration objects are often called shadow objects.

Note Niagara integration (shadow) objects are beyond the scope of this reference manual.

Integration is performed by JACE controllers. Each JACE provides a number of

standard communications ports. These include a LonWorks port (FTT-10 LonTalk

transceiver), a 10/100 Mbps ethernet port, and at least one RS-232 serial port and

RS-485 port. Typically, one or more of these communications ports are used to

network the JACE with some number of other foreign (non-Tridium) devices.

By combining integration objects with standard objects, you can quickly build

applications that draw from multiple vendor devices (and protocols). Furthermore,

because of the common object model, integrated devices are represented in the

station database with common behaviors.






Niagara Objects

1–4

Although not covered in this document, most Niagara integrations include these

types of objects:

• Service object—provides the necessary communications-subsystem support

for the integration, plus protocol support. Typically, this object has

configurable settings for device status monitoring and debug.

• Network-level object—provides a container for all foreign device-types

objects specific to an integrated network.

• Device-level objects—each provides a shadow object representing a particular

device. Depending on the integration, this object may be a container object that

contains data-level objects, or instead may contain a number of properties

(inputs and outputs) for device data.

• Data-level objects—each provides access to a specific I/O point or software

value in the foreign device.

Data Modeling

The Niagara object model structures data between three distinct levels:

• Primitive —A data primitive is either a boolean (binary) value, integer value,

floating-point value, or a string. Primitives are the building blocks for all data

structures. Combinations of primitives are used to define variable types (data

species).

• Object —The data structure that represent the granularity of data most often

used in Niagara. Objects can be configured, linked, copied, and stored in

custom libraries for future reuse. In any running station, objects are executed

by “engine services” that perform control and interface functions.

• Station —The combination of a database, Web server, and object engines that

processes all objects. A job (site) may consist of one station (JACE controller),or may contain multiple stations (JACE controllers) and a Web Supervisor.

Using this model, data flow is bidirectional—primitives are gathered and represented

in objects (status monitoring), and control is provided for changing primitives in

devices.

Object Hierarchies

Depending on its type, an object can have “child” objects, that is, be a “parent” that

contains other objects. The obvious example is the Station object, the parent of all

other objects in the station. All other objects are children of the Station object. Bydefinition, all container-type objects are intended to be parent objects.

Many levels of hierarchies are possible in a station database, where parent objects can

contain other parent objects, and so on. In this tree-like hierarchy, objects at the

lowest level in any branch are objects that are only child objects ( primitive objects).

An example of primitive objects are the standard “control” objects, which represent

a piece of data or a data function. Other primitive objects include all apps objects, Gx




Object Name and SWID



objects, and notification recipient objects. Most integration objects are also primitive

objects, which shadow data values, commands, or status in a foreign (integrated)

device. Examples include most LonWorks objects and BACnet objects.

Object Name and SWIDIn a Niagara station, each object has a name and an associated SWID (system-wide

identifier). To improve readability, all other references to the system-wide identifier

will use lower case, that is swid.

• Object Names (and Rules)

• Object Swid

Object Names (and Rules)

Niagara object names must follow these rules:

• Letters, numerals, and underscores (_) are the only allowable characters.

(This means spaces are not permitted.)

• The name must begin with a letter.

• The object’s name must be unique within its Workspace, that is, within its

parent container (level of hierarchy in the station’s database). However, within

a station there may be many objects with the same name. Each object is at a

different level (branch) of the station database.

For example, there may be many objects named SupplyFan in a station.

However, each object will have a unique swid, because the path of the object

will vary from one instance to another.

• It is recommended that no child object be given the same name as its parent

container object, to avoid a possible name duplication error.

Notes • Names are case-sensitive. For example, SupplyFan and supplyFan are

considered different names.

• The JDE automatically enforces the uniqueness of object names when you

duplicate or copy objects in the same container. This is done by appending a

unique numeral to object names, for example, SupplyFan_1 and SupplyFan_2.

• When naming objects, brevity is encouraged. This is particularly true for

parent (container) objects, which are included in the swid for any child object.See the related Caution in the next section.

• With one exception, the JDE allows you to rename any object in the station.

The exception is the Station object, named only in the New Station wizard.

• You typically rename objects as needed only when first engineering a station.

Renaming an object after a station database is engineered may cause problems,

particularly if there are URL (swid) references to that object in other objects.






Object Name and SWID

1–6

Object Swid

An object’s swid includes the object’s name, but is more—a complete and unique

address of where it resides in the station database. It is similar to both a file path and

a URL (uniform resource locator), due to the Web-server nature of a Niagara station.

For any Niagara object, a swid uses the following format:

htt p: / / <host I P or name>/ db/ <st at i on name>/ <path of obj ect >

• The first part of the swid indicates what protocol to use, namely, http:/.

• The next part specifies the IP address (or the domain name) of the Niagara host.

• The next part is always /db for any Niagara object.

• The next part is the station name.

• The last part reflects the station hierarchy of the object. This includes not only

the object (by name), but also its complete tree location. In other words, before

the object’s name are the names of any proceeding parent (container) objects.

Consider the following swid for a NotificationClass object named class0.

ht t p: / / 192. 168. 1. 34/ db/ Net Sup2000/ ser vi ces/ Not i f i cat i onServi ce/ cl ass0

This swid shows that the object “class0” is a child of the object named

“NotificationService”, which in turn is a child of the object named “services”. The

station’s name is NetSup2000—meaning that the foundation (Station) object named

NetSup2000 contains all other objects.

Caution Keep object swids under 128 characters, inclusive of the station name. Do this by

using shorter names for objects (particularly container objects) and fewer levels of

containers. Table and index views list objects by swid, and are easier to use this way.

Also, a log object with a swid over 128 characters can cause archive problems.

Swid in PropertySheets

A variety of Niagara objects have internal properties that accept a swid, for example,

hyperlinkUrl and boundUrl (most Gx objects) and rootNode (AdminTool object).

When entering a swid that references another object in the station, the swid format is

shortened to drop the leading “http://<hostname or IP address>” portion. Instead, the

swid begins with the “/db” string portion (root of the station’s database).

As an example (instead of the complete URL), a swid used as the property value:

/ db/ Net Sup2000/ ser vi ces/ Not i f i cat i onSer vi ce/ cl ass0

Tip To avoid manually typing a swid in a property sheet field, you can simply use

Tree View to select the target object, right-click, and choose “Copy.” You can

then paste the properly-formatted swid in the property field, using CNTRL-V.




Object Dependencies



Object DependenciesIn general, objects of different types can be placed in most levels of a station

database. However, there are cases in which some types of objects have

dependencies. For example, any service object must be located within the

ServiceContainer object, of which there can be only one instance per station. Inaddition, the ServiceContainer object must be in the root level of the station.

Using the New Station wizard in the JDE, these particular object dependencies are

automated such that the ServiceContainer object and the selected service objects are

correctly created and ready to modify, as needed.

Parent (container) objects may have dependencies as well. For example, a GxPage

object (a type of container object) may contain only Gx objects, and no other object

types. However, Gx objects can be children in other container-type objects as well.

The JDE enforces object dependencies when you are engineering a station. In each

object description included in this document, “Parent Dependencies” are listed.

“Child Dependencies” (for container objects that have them) are also provided.

Object CategoriesStandard Niagara objects are organized in categories, reflected by category names

when using the JDE. When adding a new object in the WorkspaceEditor (Figure 1-1),

you select objects from within these categories.

Figure 1-1 “New” menu in WorkspaceEditor groups object types by categories.

The different object categories are:

• Foundation —Only one type, the Station object. Each station has only one.

• Control Objects —Several standard types, used to handle values and status

received by communications subsystems (provided by some services) and

provide a common control logic model for system integration. Different types

of control objects provide various control algorithms, and can be individually

configured and linked together to provide complex control sequences.

Object categories seen when

adding new objects.






Object Categories

1–8

Note Niagara control objects have many characteristics of BACnet objects.

Several Niagara object types can be exposed directly as BACnet

objects, and the station itself exposed as a BACnet device.

• Apps Objects —Several standard types, used to provide scheduling control,data logging, and other global control functions. One type, the Program object,

allows you to create a custom application for use with control objects.

• Gx Objects —Several standard types, each can be used as a component of a

graphical view built to show real-time values and status (user interface).

• Container Objects —Several standard types, used to hierarchically organize

and provide specific functionality to contained objects (children).

• Notification Objects —Several standard types, each provides unique functions

to a station’s NotificationService (a particular type of service object).

• Services —Several standard types, explained ahead. Service objects publish

their functionality for other station objects to use.

Object Libraries

Most standard Niagara objects are distributed in the tridium JAR file, including the

Station object, all control, apps, container, and Gx objects, and most service and

notification objects. These objects are covered in detail in this manual.

In addition to these standard object types, various integration and lib(rary) objects are

distributed within the tridiumx folder. The tridiumx folder includes many JAR files,

primarily for foreign device integrations. This includes both “standard” integrations

(BACnet, LonWorks, and various vendor-specific LON types) as well as optional

integration types. This latter group includes a few Modbus (open-protocol)integrations, and various proprietary integrations, such as Johnson Controls N2

network, Invensys GCM and DMS, and several others. Each JAR file contains

various objects to support the integration (ranging from a service object to data

objects). These integration objects are covered in separate documents, and are

outside the scope of this manual.

Aside from the JAR files for these device integrations, the tridiumx folder also

contains a lib JAR file. The lib JAR contains two especially important folders:

• programs —Holds various pre-engineered Program objects for standard use in

data and unit conversions, HVAC routines, and other purposes. The purpose of

each Program object is explained in “comments” of its TRIPL program code.

In addition, a lib /docs/libdocs.html document provides an overview for eachavailable Program object.

• applications —A collection of various pre-engineered applications, each with

one or more graphics (GxPages) linked to standard Niagara control objects.

For more details, see the lib /docs/applicationInstructions.html document.






Station

1–9

StationQuick reference for all properties: Table A-72

The Station object is the parent (root)

container for all other objects in a Niagara

station. Every station has one Station object.

A Station object has various properties, but

no inputs or outputs. Object views include

those typical to any container, such as the

Workspace, WorkspaceEditor, Properties,

Links, and Report views.

In addition to these views, each Station object

has these “Go” views in the JDE:

• AddressBook

• UserAdmin

• ActiveUsers• Alarms

The AddressBook and UserAdmin views are

especially important for job configuration.

A Station object provides various runtime

commands. These commands perform station

database backups or restart/reboot the station

or station host.

Resource Count Range: 89 to 200, plus the sum of all other objects.

Trigger Properties None.

CommandsUsers with Command, Admin privileges have the following available command:

• BackupXML —Causes the selected station to locally backup its running

database to XML format (backup “there”). Applicable for JACE-NP and Web

Supervisor stations only (and not JACE-4/5s, which store only in SNS format).

• BackupSNS —Causes the station to locally backup its running database to

SNS format (backup “there”). Applies to any selected Niagara station,

including a JACE-4/5.

• BackupSubordinatesXML —Applies if the selected station is configured as

supervisor (typically, Web Supervisor). Backs up the running station databasein each subordinate-designated station, to the appropriate stations subfolder, in

XML format (a global-backup “here”). All station types are supported.

• BackupSubordinatesSNS —Applies if the selected station is configured as

supervisor (typically, Web Supervisor). Backs up the running database in each

subordinate-designated station, to the appropriate stations subfolder, in XML

format (a global-backup “here”). All station types are supported.

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for Station Object(only input and output types, see Table 1-1 for all properties)

Type Label Property Name Data Species

input — — —

output — — —

Station Icon Meanings (Tree View)

Icon Description Typical Meaning

Station icon isblack.

Station is open and online.

Station icon is gray. The station is a subordinate of another opened station(or) a station that was open when the JDE was last exited.Double-click (or expand) to open it online.

Gray cylinder. Station is open off line.

Gray cylinder withred shading.

Station is open offline, and changes have been made butnot saved.

(none)






Station

1–10

• Restart —Causes an immediate restart of the selected station. If this command

is given from the JDE, a “Confirm” dialog appears first. Applies to JACE-NP

and Web Supervisor stations only (not JACE-4/5 stations).

Note Restarts are not typically needed, except after adding a new service.

• Reboot —Causes an immediate system reboot of the station’s host machine. If

this command is given from the JDE, a “Confirm” dialog appears first. Applies

to all station types.

Typically, this command is given only to a JACE-4/5 station, as the method of

restarting the station.

Note A reboot command to a Web Supervisor or JACE-NP station is the same

as restarting Windows on that host! Generally, not recommended.

• Stack Dump —Causes a dump of all station threads for use as an aid to debugdeadlocks and CPU usage. Currently, this command is for internal

(development) use only, as a non-standard JVM is required.

• dump —Causes a dump for the Station object to be sent to Standard Output.

PropertiesTable 1-1 Stat ion ob ject proper ties.

Tab Property Name Description Valid Values Default Notes

S t a t u s

objectType Read Only: The object type. Station Station

statusFlags Read Only: Current state of the object’sstatus flags. A “normal” state (no flags set)

is where the statusFlags value is “ok.”

okor

down

ok

description Read-Write: Permits a user-defineddescriptor for the station. Any printablecharacters are allowed.

See Descrip. Niagarastation.

currentTime(date) at (time)

Read-Write: The current time and date forthe host running the station.

Format is:date: dd Mon yyyy (ex: “18 Oct 20001”)time: hr:min AM/PM (ex: “8:21 AM”)

Allows review/change of system (host) time,as in System Time tab of the Admin Tool.

valid timeand date

— Unlike when usingthe Admin Tool toset system time, thetime zone is notmodifiable here.

bootTime Read Only: Timestamp of the last stationstartup. (Station has been running since.)

See Notes — (for each) format is:hh:mm dd-mo-yyyyTimeZonelastDownTime Read Only: Timestamp of when the station

last stopped (prior to recorded bootTime).See Notes —

lastAliveTime Read Only: Timestamp of last station“health” check. Should be within 1 minute ofthe currentTime.

See Notes —

isRunning Read Only: Indicates whether station isrunning properly.

False, True True






Station

1–11

S t a t u s ,

c o n

t .

osArch Read Only: Operating system architecture.Is “x86” for JACE-NP or Web Supervisor, or“ppc” for JACE-4/5.

x86or

ppc

SeeDescrip.

osName Read Only: Operating system name. Is“Windows NT” for JACE-NP, NX, or WebSupervisor, and “VxWorks” for JACE-4/5.

Windows NTor

VxWorks

SeeDescrip.

osVersion Read Only: Operating system version.JACE-NP (NT) is 4.0JACE-NX (XP) is 4.0 or 5.1.Web Supervisor (NT, 2000, or XP) is 4.0,5.0, or 5.1, respectively.If JACE-4/5, will be latest VxWorks version.

See Descrip. SeeDescrip.

and Note.

At time of 2.3.5release, VxWorksversion is 5.4.2.

javaVendor Read Only: Vendor of JVM used. Currently,is” Sun Microsystems” for r2.3.5 JACE-NX,JACE-NP, or WebSup. If a JACE-4/5, either“Insignia Solutions Inc.” or “Wind RiverSystems Inc.”


Prior to r2.3.5,Win32 platformsused Microsoft’sJVM.

javaVersion Read Only: Version of JVM used by station.At 2.3.5 release time, version is 1.4.1 (SunHostspot) or 1.1 (Wind River Systems).


release Read Only: Niagara Release level in use.For example, 2.301.507.v1

valid releaselevel

SeeDescrip.

C o n

f i g

httpPort Read-Write: Number of logical port used forTCP/UDP connections in HTTPD access.Applies to normal station communications.

The JDE and browsers, by default, assumethe “well known” port of 80. If you assign adifferent port, you need to append thisnumber (with colon) after the hostname or

IP address when opening the station in theJDE, or when accessing in a browser.

For example: http://192.168.1.25:85for a browser connection on port 85.

80(recommended)

or otherunused port

80 If using a port otherthan 80, you also need a line in thestation.properties file, for example:

httpPort=85

Otherwise, you will

not be able to doDbAdmin functions.

An httpPort changebecomes activeafter station restart.

httpsPort Read-Write: (Future Use) Number of logicalport for TCP/UDP connections in HTTPSaccess. Applies if enableSSL is True.

Port 443 is the “well known” standard.

443

or otherunused port

443 SSL will besupported in afuture Niagararelease.

enableSSL Read-Write: (Future Use) Allows SSL(secure socket layer) HTTPS connections.

Requires the Niagara SSL service plusadditional configuration, including certificate

from a Certificate Authority (CA).

False, True False

defaultPage Read-Write: Specifies the HTML page (orstation swid) to display with browser accessto the station, if no specific URL is provided.

Applies if the user has no “Browser Home”entry (UserAdmin view, General Tab).

Absolute references or release directory "/"should be used for linking in all interfaces.

valid swid toHTML page orGxPage, for

example

—

Table 1-1 Station object propert ies. (continued)







Station

1–12

C o n

f i g ,

c o n

t .

pstoreFlushTime Read-Write: Applies to JACE-NP and WebSupervisor stations only. Specifies theinterval, in milliseconds, between automatic

saves of persistently-stored properties.Updates the Config.db file in the properstations subdirectory, at this frequency.

1000 toMAX_VALUE

5000(ms)

Does not apply to aJACE-4/5.

Only properties

modified since thelast flush are saved.

snsBackupTime Read-Write: Specif ies the interval, inminutes, between automatic backups of thestation database to sns (serialized nodeset)format. All persistently-stored properties aresaved.

Each backup updates the Config.sns file inthe proper stations subdirectory. Theprevious Config.sns is renamed toConfig.sns.old.

For a JACE-4/5 or Web Supervisor station,

if the Config.db database cannot be loaded,the Config.sns is automatically used(sometimes called “Auto Restore”).

integer, 1 to n

for snsbackups

0 or negativeto disable auto

sns backup

180(minutes)

Applies to Niagarastation on any hostplatform.

interstationSendTime Read-Write: Specifies the interval, inmilliseconds, between sending change ofvalue updates to external subscriptions(external links, i.e., links between stations).

integer,500 to n

5000(ms)

More propertiesthat affect externallinks are adjusted insystem.properties.

membershipGroups Read-Write: (Future use) niagaraR2 niagaraR2 These propertiesare related to afuture release ofNiagara software.

Their applicationwill be explained ata later date.

announcementTTL Read-Write: (Future use) — 3

enableAnnouncement Read-Write: (Future use) Leave at False(default) to avoid unnecessary messaging.

False, True False

minAnnouncementFreq Read-Write: (Future use) Minimumannouncement frequency.

— 55000(ms)

maxAnnouncementFreq Read-Write: (Future use) Maximumannouncement frequency.

— 65000(ms)

A l a r m

S e

t u p

alarmText Read-Write: The (final) top-level alarmTextavailable for any alarmable child objects.

For child objects to use this, their alarmTextproperties must have only the defaulthyphen (-). See “Alarm and Alert Text” onpage 7-5 for more information.

(for each)

255 charactersmaximum.

Any text string,including

spaces andmixed casecharacters.

- The alarmTextvalue is not used in“change-of-state”events of Station objects. Instead,the messageText inalarm records forthese events usesthe enumerateddescriptor , such as“stationDown” or“stationUp.” See“Station AlarmTypes” onpage 1-23.

alertText Read-Write: The (final) top-level alertTextavailable for any alert-capable child objects.

For child objects to use this, their alertTextproperties must have only the defaulthyphen (-). See “Alarm and Alert Text” onpage 7-5 for more information.

-








Station

1–13

A l a r m

S e

t u p , c o n

t .

notificationClass Read-Write: The notification class used forchange-of-state events for the station (forexample, coming “Up” after going “Down”).

This class is also used in notifications ofstation events occurring for remote stations,meaning those “monitored” by this station(AddressBook view).

If a JACE-NP on JACE-NX and environmentmonitoring is enabled (1-27), associatedalarms are sent to this notification class.

0 to8388607

0 A NotificationClass object with thissame notification

class number isrequired in thestation’sNotificationService container.

V i s u a

lposition Read-Write: Has no practical application for

the Station object. — -2147483648

x 0

alarmPageUrl Read-Write: (Future Use) Specifies the URLto display on alarm.

— — Not currentlyimplemented.

E n g

i n e e r i n g

nextHandle Read Only: Shows the handle (number) thatwill be automatically assigned to the next

object added to the station database. Eachobject has a unique handle.

The 0 handle is reserved for the Stationobject. Handles are seen in StandardOutput following a “dump” command.

<integer>greater than 0

— The integer value ofnextHandle

approximates thenumber of objects inthe station.

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the Station object is assigned.

In the JDE, these security settings affectaccess to the Station object, and not all childobjects (unlike with other container objects).

A JDE user without any rights to the Stationobject can still expand the station in TreeView and see other container objects

(assuming that rights exist tosecurityGroups assigned to those objects).

Any mix ofthese types:

• General

• HVAC

• Security

• Life Safety

• Group 4

• Group 5• Group 6

• Group 7

General A JDE user withonly operator-levelproperty readaccess to theStation object canstill use UserAdminto change theirlogon password,JDE Home, andBrowser Home.

strongPasswords Read-Write: Specifies whether station userseach require a “strong” password (True).

The rules for entering a strong password (inthe UserAdmin view of the station):

• Must be a minimum of 8 characters, withno spaces permitted.

• At least 1 character must be uppercase.

• At least 1 character must be lowercase.

• At least 1 character must be a specialcharacter, meaning either a numeral 0 to

9, or one of the following: ! @ # $ %Some examples of strong passwords:

J%ohn9Tv 1toGoHome GroovyBaby!

False, True False If strongPasswordsis enabled after users are alreadycreated, existing(non-strong)passwords willcontinue to workOK.

However, nochanges for a user(UserAdmin view)

can be made until astrong password isassigned to them.








Station

1–14

Station NotesSpecial “Go menu” views of a Station object are described in the following sections:

The following additional topics, while not specifically about the Station object, are

closely related.

• “Station Limits and Guidelines,” page 1-24, provides information about the

capacities of the various Niagara host platforms.

• “Monitoring JACE-NX, JACE-NP Environment Variables,” page 1-27,

provides information on configuring a JACE-NX or JACE-NP to allow a

hosted station to monitor the internal (CPU) temperature and voltages. It

applies to these Niagara platforms only.

• AddressBook

• UserAdmin

• ActiveUsers

• Alarms






Station

1–15

AddressBook A Station object’s AddressBook stores information about other Niagara stations that

are part of a job, and describes relationships among them.

Figure 1-2 AddressBook view lists currently defined remote stations.

• For a Web Supervisor station, entries are required for each JACE station.

• For each JACE station, an entry is required for the Web Supervisor station, at

a minimum. If external links are made between JACE stations, entries are

required for those stations too. Figure 1-3 shows an example edit dialog.

Station Access: This section has the following fields:

• Station Name —The Niagara station name of the remote station. Must be

unique from other station entries in the AddressBook.• User Name —An existing user account in the remote station. This user requires

admin-read (General) security rights to support the backupSubordinates

command and “Status Index” from a Web Supervisor.

Note By convention, a “gdp” user is often created in each station and

assigned General “Admin read” rights and also a password . This user

is referenced in AddressBook entries in other stations.

Figure 1-3 Edit dialog (Add Address/Change Address) has several sections.

Entry fields are in main sections:

• Station Access —Informationabout the remote station,including its name, a useraccount, and user password.

• Network —IP address/hostnameof the remote host running thestation. If not HTTP port 80, alsothe HTTP port number n, as “:n ”

• Dialup —Applies only if modemdialup access is required toconnect to the remote station.

• Poll Archive Group —Appliesonly if the local station is runningthe PollArchiveService.

• (Station relationship) — Peer,Subordinate, or Supervisor.Defines the relationship of theremote station.

• Monitor —Whether the localstation should monitor (ping) theremote station, and what“non-response” time is toleratedbefore an alarm occurs.






Station

1–16

• Password —Password for the user in the remote station. See the Note above.

• Confirm Password —Same password again, repeated.

Network: One field, namely:

• Host Address —IP address (recommended) or hostname for the remote

station’s host. If that station is using a “non-default” http port (other than 80),it must be included (with a colon delimiter). For example: 192.168.1.211:85

If using dialup access, leave this field blank unless the remote station is using

a “non-default” http port (other than 80). Then, include a “:<port>”, e.g: :85

Dialup: This section is typically left blank, unless a dial-up modem connection is

required to connect to the station.

Notes • Dialup connection to a station requires configuration of its host’s RAS (remote

access service). For more information, refer to the Niagara Networking &

Connectivity Guide, Chapter 4, “Connecting with Direct Dial.”

• External links between stations are not supported by dialup connections.

However, dialup connections support archiving of logs, receiving alarms, and

dialup access using the JDE.

• Phone # —Phone number to dial into the remote host machine.

• Host User Name —Logon user name for the host machine.

• Host Password —Password for the user name above, to access the host

machine.


Poll Archive Group: Applicable only if this station has the PollArchiveService.

Provided is a drop-down list of poll archive groups—each remote station can beassigned to any (including disabled). See “PollArchiveService” on page 4-40.

(Station relationship): Drop-down list with description of the remote station’s

relationship to this station. Selections include:

• Peer —Typical between JACE controllers, where data is exchanged between

stations. Less typical (but possible) is a peer also used as the archive

destination, providing that it has the DatabaseService.

• Subordinate —When in the AddressBook of a Web Supervisor station, this is

typical for each JACE station entry.

• Supervisor —When in the AddressBook of any JACE controller station, this is

typical for the Web Supervisor station entry.

Monitor: Whether or not the remote station is to be monitored (pinged), and what

“non-response” time (in minutes) is tolerated before a “stationDown” alarm occurs.

For the AddressBook of a Web Supervisor station, this is typical for each JACE

station entry. Optionally, JACE stations can also monitor each other as well.

Alarms generated by monitoring other stations can be reviewed in the Station object’s

Alarms view.






Station

1–17

UserAdmin The UserAdmin view is especially important for any Niagara station. It is used to

add, modify, and delete user accounts for accessing the station. A station can have up

to 256 users. Each station user has specific security privileges (rights), plus other user

preferences, such as home page defaults and hot links.

Figure 1-4 UserAdmin view lists currently defined user accounts for the station.

The following subtopics apply to adding and changing station users:

• The Administrator

• Edit Tabs (General, Hot Links, Security)

The Administrator

The New Station wizard creates a single Administrator user, with default user name

of “admin” (and whatever password was entered). Consider this account the “super

user” for the station, as it has fixed (full) security and administrative privileges.

Moreover, the administrator user can never be deleted , although the password can be

changed and other user preferences adjusted.

Note A JDE user logged on as the default administrator can effectively “replace” the

administrator account, using the menu bar command UserAdmin > Change AdminUser. This allows changing the “User Name” of this special account, but also clears

the password, and prior user preferences (“home” settings, logoff period, hot links).

Edit Tabs

When adding or modifying a station user in the JDE, three tabs are available:

• General Tab

• Hot Links

• Security Tab

Note Starting in r2.3.4, browser access to station user administration is available. The

Niagara host (Web Supervisor or JACE) requires the t r i di umx/ webuser JAR

installed, and the station must have the WebUserAdminService in its services

folder. Most functionality found on the General and Security tab is available,

including the ability to add new station users and/or change security rights.

The URL to access the Web User Administration feature is: http://<host>/user

For more information, refer to the Niagara Browser Access Guide.






Station

1–18

General Tab—The General tab provides user password access and “home page”

logon preferences.

Figure 1-5 Example General tab of a user selected in UserAdmin view.

Entry fields are as follows:

• User Name —The user name, as used in the station. Case-sensitive, it must

begin with a letter, and have no spaces. It must be unique among user names in

the station. A user logs on using this name (often, a user’s initials are used).

Once created, this name cannot be changed—only the entire account deleted.

• Full Name —A descriptive name for the user, it is editable by the user. Initially,

it is set to match the entered user name for a new user.

• Java Desktop Environment Home —(optional) Swid to object (for example,

GxPage) to display in the JDE Workspace after user logon, or whenever the

standard “Go” menu option “Home” is selected. Editable by the user.

• Browser Home —(optional) Swid or URL to object, HTML page, or other

resource to display in a Web browser after user logon. Editable by the user.

If left blank, the Station object’s defaultPage swid or URL is used.

• Password —User’s login password. Unless strong passwords are enabled, can

be any number of characters needed, including 0 (blank, or no password).

Password is case-sensitive, cannot have spaces, and uses letters or numerals.

Editable by the user. Also see the property “strongPasswords,” page 1-13.


• Logoff Period (mins) —Specifies the time, in minutes, in which a user’s JDE

session with the station must be inactive before the user is automatically

logged off. A popup warning with a 15-second countdown appears at the end

of this period (allows the user to cancel the logoff, resetting this period).Editable only by the administrator or a user designated as a “Security

administrator.” Can be any positive integer, in minutes, up to 999999999.

Note If set to 0, automatic logoff is disabled (the user is never logged off due

to inactivity).






Station

1–19

Hot Links—The Hot Links tab provides a method of adding “Go” menu options,

available to the user when using the JDE (Figure 1-7). Editable by the user.

Figure 1-6 Example Hot Links tab for a user (a new hot link is shown being added).

Toolbar controls in the Hot Links tab are as follows:

When adding or changing a hot link, the two fields in the Hot Link dialog are:

• Name —How the link appears listed on the JDE “Go” pull-down menu, below

the “Previous”, “Next”, and “Home” menu options (Figure 1-7).

• Target —The swid of the object to display in the JDE Workspace when this

link is selected. Typically copied in Tree View, and then pasted in this field.

Figure 1-7 Example Go pull-down menu showing hot l inks.

Add Hot Link

Produces the“New Hot Link”

dialog box.

Delete

Deletes theselected hot link.

Move Up

Moves theselected hot link

up in the JDE“Go” pull-down

menu.

Move Down

Moves theselected hot linkdown in the JDE“Go” pull-down

menu.

Hot links appear listed in the JDE’s“Go” menu, either user right-clickaccess (as shown here) or from theGo menu on the JDE menu bar.






Station

1–20

Security Tab—The most critical edit tab for any user. A user’s security rights

(Security Mask) apply whether the user is logged onto the station using the JDE or

using a Web browser.

Figure 1-8 Example Security tab of a user selected in UserAdmin view.

Note For any user except the administrator (or a user assigned as a “Security

administrator”) all fields in the Security tab are read-only (cannot be modified).

Entry field sections are:

Account enabled: Checked, by default, for any user. If cleared, the user will not be

able to logon to the station (using either the JDE or a Web browser).

Security administrator: Cleared, by default, for any user except the defaultadministrator. If checked, the user will have full security administrator privileges.

Note Without regard to any other security rights, a user with security administrator

privileges can change their own security settings, as well as those for any

other user . In addition, a security administrator can add and delete users.

For these reasons, be careful about assigning security administrator rights.

Security Mask: Applies to the eight separate security groups that can be assigned to

any Niagara object. Each object must belong to at least one security group. A newly

created object defaults to the “General” group. See “About Security” on page 1-21.

For each security group, three main categories of security access apply:

• Admin —Gives the user Read (R), or Read and Write (W) permissions for all

properties of the object, including admin-level properties. In an object’s

property sheet, most (Config, Alarm Setup, Visual tabs) are admin-level.

Admin-level write is also needed for edits of Calendar and Schedule objects.

Note that selecting R or W for “Admin”-level automatically includes the same

access for “Operator”-level properties.






Station

1–21

• Operator —Gives the user Read (R) or Read and Write (W) permissions for

any operator-level properties of the object. In an object’s property sheet, these

are typically only properties on the Status tab.

• Command —Gives the user access to various commands or actions, depending

on selections, as follows:

– Std —Standard level commands. Applies to right-click, priority-level 8(Manual) commands for object types AO, BO, MSO.

Also applies to various right-click commands for other object types,

including AnalogOverride, BinaryOverride, Command, DateTimeTrigger,

Loop, MultistateOverride, and PeriodicTrigger.

– Alarm —Alarm acknowledgment. Gives the user alarm acknowledgment

permissions for alarmable objects.

– Emer —Emergency level commands. Applies to right-click, priority-level

1 (Manual Life Safety) commands for object types AO, BO, MSO.

Note that if a user is given rights for emergency-level commands,

standard-level (Std) commands are automatically included too.– Admin —Administrator commands. Applies to system-administration

type commands of various objects. Example commands include “clear,”

“archive,”, and “clearLast Archive” (log objects), “cleanupSpecials”

(Schedule object), various backup commands, “restart,” and “reboot”

(Station object).

Note that if a user is given rights for Admin-level commands, rights are

automatically given for the other three types (Std, Alarm, Emer) as well.

About Securi ty

The eight security groups are independent of each other and their meaning is a local

matter. This means that there is no prioritizing or “weighting” of any security group.Any object can be assigned to any combination of the eight security groups through

its securityGroups property. Each object must belong to at least one group. In this

way, many different security permissions can be defined simultaneously.

A user's access rights to an object are determined by combining his or her rights for

each group that is checked in the object's securityGroups property. If the object is

assigned to any securityGroup providing access to that user, the user has those rights.

Also (when working in the JDE), if a user has rights to a container type object, some

rights are automatically applied to its child objects.

• If a user has Operator read rights to a container, child objects are visible in its

Workspace.• If a user has Admin write rights to a container, all the edit (WorkspaceEditor)

right-click menu features are available for child objects, except Go menu items.

Child objects can be linked, cut, copied, duplicated, deleted and renamed.

In sections ahead on different object types, descriptions for object commands note the

security rights needed. The security access-level required for each property of

standard objects is included in the “Attribute Notation” of all properties listed in each

object as they appear in the “Property Quick References” section on page A-3.






Station

1–22

ActiveUsers A Station object’s ActiveUsers view lists all currently connected JDE users.

Figure 1-9 ActiveUsers view lists all JDE users that have the station open.

Each row shows the station’s user name, full name, host machine name (IP address)

on which the JDE is running, and the station logon time.

User Messages

In the station’s ActiveUsers view, you can send messages to other JDE users, using

one of the ActiveUsers pull-down options from the menu bar, or these toolbar icons:

Either selection produces a dialog box in which you can enter text for the message.

When you type your message and click OK:

• Send Message—The message appears as a pop-up at the selected user’s JDE.

• Broadcast Message—The message appears as a pop-up on the JDE of all users.

In either case, the message popup remains “on top” of the JDE until acknowledged by a remote user. Figure 1-10 shows an example broadcast message being sent (left)

and received (right).

Figure 1-10 ActiveUsers view lists all connected JDE users.

Send Message

When a single user is selected (highlighted)

Broadcast Message

A user does not need to be highlighted.






Station

1–23

Alarms The Alarms view of a Station object lists only station alarms that have occurred since

the last station startup. Each includes a timestamp, event type, and alarm message.

Figure 1-11 A Station object’s Alarms view lists only station alarms.

Figure 1-11 shows an Alarms view for a station that is monitoring another station. It

contains three alarms: its own startup alarm, and separate “stationDown” and

“stationUp” alarms for a remote station (being monitored by this station).

Note Unless the station is configured to monitor other stations (AddressBook setup), oftenonly a single alarm exists—a “stationBoot Down ...Up” alarm with a timestamp of

when the station was last started.

There are relatively few types of station alarms—all are “change-of-state” event

types. The following types exist:

Station Alarm Types

(StationAlarmEnum)

For any station alarm, the enumeration’s description appears in the “message” field

of the alarm record.

Note If a JACE-NP configured for sysmon (internal environment monitoring), additional

types of station alarms are possible. These alarms can apply to the JACE-NP’s CPU

temperature, various voltage levels, or CPU fan speed. For more information, see

“Monitoring JACE-NX, JACE-NP Environment Variables,” page 1-27.

stationUp 0

stationDown 1

stationBoot 2powerLost 3

powerLostShutdown 4

powerRestored 5

batteryTestFailed 6

batteryTestPassed 7






Station Limits and Guidelines

1–24


Refer to Refer to the Engineering Notes document, Niagara Capacities, for a more complete

discussion about this topic. Also, please note that capacity information for the

“newer” JACE platforms (JACE-NX, JACE-NX-UPS, JACE-403, 404, 405, others)

may be included in a later revision of that document, but is currently not available.

Due to the flexibility of the Niagara Framework, it is risky to set arbitrary limits on

the makeup of a station database. However, limits in Table 1-2 establish some rough

guidelines, according to host platform (PC, JACE-NP, JACE-5 models, JACE-4).

These limits apply to the four areas of resource boundaries, namely:

• RAM memory—The station operates from RAM, consumed (roughly)

according to the number of objects in the station. A more accurate yardstick is

resource count , available (whole or in part) from a running station. See

“Checking Object Count” and “Checking Resource Count.”

• CPU Utilization—The ability of the host processor to execute the necessary program threads that allow the station to perform work.

Of the three resource factors, this is the most important for the newer JACE

controller models (JACE-401 and JACE-51x). It is also important for

JACE-50x models (in addition to resource count). See “Checking JACE-4/5

CPU Utilization.”

Table 1-2 Rough limits for station resource allocations, by Niagara platform.

Niagara Platform Resource Count CPU utilization Disk/Flash Space External Links

PC (Web Supervisor)500MHz PIII, 256MB RAM

1GHz P4, 512MB RAM

1,000,0001

2,000,0001

1. PC (Web Supervisor) maximum resource count limits are predicated upon (typical) DatabaseService resource loads.

Not applicable. 2GB minimum. 25,000

50,000JACE-NP (earlier, 64MB) 400,0002

2. Tridium Systems Engineers (who provide technical support to the field) think these numbers are more realistic than ones previouslypublished, which were: 600,000 for earlier (64MB) JACE-NP and 1,000,000 for current (128MB) JACE-NP.

Not applicable. Not applicable. ?

JACE-NP (current, 128MB) 600,0002 Not applicable. Not applicable. ?

JACE-401 600,0003

3. Chances are that various engines (control, ui) and poll threads will need to be slowed down to reach this600,000 resource count for aJACE-401 or JACE-51x. Refer to the Engineering Notes document, Niagara Capacities, for more detailed information.

20% (or greater) CPUIdle is required by all

embedded JACEs.

A JACE-501 or 502 isalso constrained by

resource count.

CPU utilization is thekey constraint for any

Jeode VM-basedJACE (40x, 51x).

n KB free /tffs Some free fi lespace (n KB) is

required toallow database

backups.

See “CheckingJACE-4/5 Flash

Space” onpage 1-26.

?

JACE-501,JACE-502

300,000

n KB free /tffs4

4. JACE-501 and JACE-502 models without WebUI are the most prone to flash memory limitations (database space limitations).

?

JACE-501-UI,JACE-502-UI

n KB free /tffsn KB free /sm

?

JACE-511,JACE-511-UI,JACE-512,JACE-512-UI

600,0003n KB free /tffs

n KB free /sm?

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-







1–25

• Disk storage—Typically not an issue for a Web Supervisor or JACE-NP, this

relates mostly to flash memory availability for a JACE-4/5. See “Checking

JACE-4/5 Flash Space.”

• External links —Typically extensive in a Web Supervisor station, where

graphics (Gx objects in GxPages) or log objects are linked to control logic.

Limits shown in Table 1-2 are extremely high (25,000 or more)—a dedicatedEthernet LAN would likely be needed to ensure network availability.

Checking Station Resources

The following station resource checks are available:

• Checking Object Count

• Checking Resource Count

• Checking JACE-4/5 CPU Utilization

• Checking JACE-4/5 Flash Space

• Checking External Links

Checking Object Count—The total number of objects in a running station are

reported by the Prism servlet:

http://<stationHost>/prism

The object count is in the line “nodeCount=n.”

Checking Resource Count—Check the resource count for a running station by

opening it in the JDE, selecting the station (or a portion of) in the Tree View, and

selecting Search > Resource Count from the menu bar (or use the ALT-R shortcut).

The Prism servlet also provides resource count statistics, using the URL:

http://<stationHost>/prism/resources

– The “ Total Obj ect s n” line provides the station’s total resource count.

– The “Chi l dr en” section provides individual resource counts and

percentages of total resource counts.

Checking JACE-4/5 CPU Util ization—Check the CPU utilization of a station

running in a JACE-4/5 by opening the “spy” utility with a browser connection to the

JACE-4/5 host , using the URL:

http:<JACE-4/5 IP address>:3011/system/spy

(enter the host username and password, for example, “tridium” and “niagara”)

The spy utility provides a “snapshot” of different tasks (threads) run by the CPU,

including a “total %” column that gives some relative indication of CPU utilization. Near the bottom of this window, the line “IDLE” should read 20%, as a minimum.

Notes • Failure conditions (less than 20% IDLE) typically result in:

– Slow or sluggish station.

– Many timeout messages in Standard Output.

– Devices being marked up or down.

http://-/?-

http://-/?-







1–26

• During station boot and immediately thereafter, the “tJmain” task may appear

to consume an excessive amount of CPU time. This is normal. It is the main

JVM thread, and loads all of the classes and the station database.

Checking JACE-4/5 Flash Space—Use the Admin Tool’s Summary tab to

check free file space on a JACE-4/5. This panel lists that total number of bytes lefton the primary /tffs drive and (according to JACE model) an /sm drive.

A total of 128KB is reserved on each flash disk. The number reported via the

AdminTool is actually total space minus the 128 KB reserve.

Free file space requirements depend on the JACE-4/5 model and the size of the

station database (stored by the JACE in two files, config.sns and config.sns.old):

• Models with the /sm drive must have enough free space on the /sm drive.

• Models without the /sm drive must have enough free space on the /tffs drive.

In either case, the required free space, when added to the 128KB reserve, must exceed

the station’s config.sns file size.For example, if config.sns is 144KB, the minimum required free space is >16KB.

where 144KB - 128KB(reserve) = 16KB

Notes • A config.sns file typically grows during runtime, due to logging activity.

• Typical failure symptoms of having insufficient flash memory space are:

– Failure to install a new module / upgrade (not applicable to a JACE-511 or

JACE-512).

– Database backup failure (particularly if a JACE-501 or JACE-502 without

WebUI).

• The database backup failure should be rare. The 128 KB reserve should handle

all but the largest databases.

• The newer JACE-511 and JACE-512 models have increased storage for

Niagara modules, as shown on the /tffs drive. However, you should not install

any “extraneous” (unused) modules. Extra installed modules consume RAM

otherwise used by the station, and slow station startup.

Checking External Links—Use a browser connection to a station to quickly see

the state of its external links, which are listed in a subscriptions table and a

publications table. This feature is part of the prism servlet, common to any station.The URL is: http://<stationHost> /prism/externalLinks

• The subscriptions table is posted first , with a total number of subscriptions

listed in brackets [n].

• The publications table is posted next (the total number does not appear).






Monitoring JACE-NX, JACE-NP Environment Variables

1–27

Monitoring JACE-NX, JACE-NP Environment Variables

A station in a JACE-NX or JACE-NP has the ability to monitor the JACE’s internal

main-board temperature and other environment variables (various voltages, CPU fan

speed), and generate Niagara alarms upon reaching critical limits. Alarms generated

by the sysmon feature are automatically sent to the Station object’s notification class(property sheet Alarm Setup tab, notificationClass).

The full name of this feature is the “Win32SysMonDriver.” However, it is typically

referred to simply as “sysmon.” Use of this feature is optional. Sysmon setup in a

JACE-NX or NP is configured in the JACE’s drivers.properties file.

In r2.3.4 and later, additional sysmon support was added. A “systemMonitor” JAR

can be installed in the JACE-NX or JACE-NP, which provides an available

“SysMon X ” object that you can place in the station’s database. Linkable outputs

provide currently monitored environment variables, including alarm indications.

Refer to For up-to-date configuration details for sysmon and power monitoring, please referto the Engineering Notes document: Niagara System and Power Monitoring.

That document also contains details on the optional SysMon X and PowerMon2

objects found in the tridiumx/systemMonitor JAR file.

JACE-NX-UPS,UPS Monitoring

A “power monitoring” feature is also available for the JACE-NX-UPS, the

JACE-NX model with integral UPS (uninterruptable power supply). Monitored

items include UPS battery level, operating load, and various other variables.

As in sysmon, alarms generated by power monitoring are automatically sent to the

Station object’s notification class. Also like sysmon, power monitoring is configured

in the JACE-NX-UPS’s drivers.properties file. In r2.3.4 and later, the

systemMonitor JAR also provides a “PowerMon2” object that you can place in the

station’s database. This object has linkable outputs that provide currently monitored

UPS variables for the JACE-NX-UPS, including alarm indications.

Niagara Properties FilesWith Niagara r2.3.5, even more features have been added that you can adjust by

editing various “properties” files. These are simple ASCII text files that reside on the

Niagara host, and they invariably affect station operation.

Use the Admin Tool to access these files. For example, drivers.properties can beedited on a particular host by opening a connection to it in the Admin Tool, selecting

the host, and on the Installation tab selecting Edit drivers.properties.

The following topics apply to Niagara properties files:

• Host > Edit File

• Archiving Properties Files

• List of Niagara Properties Files






Host > Edit File

1–28

Host > Edit File

Since Niagara build 2.301.330, the Admin Tool has also provided an “extensible”

method of adding/editing many remote properties files, using a “Host > Edit File”

menu command (Figure 1-12). A pull-down menu lists possible properties files that

you can edit (including create new, if not existing) using a text editor in the JDE.

Figure 1-12 Host > Edit File command in Admin Tool.

Figure 1-12 shows five possible properties files: System Properties, Gx Properties,

BACnet Properties, Status Color Properties, and Time Zones— the “default” r2.3.5

installation for the JDE.

This menu is “driven” by the file adminfiles.txt, in your JDE (PC’s) directory:D:\niagara\<release>\nre\lib (or equivalent). A “standard” r2.3.5 file is this:

Menu choices “System Properties” and “Gx Properties” always appear (even if you

remove adminfiles.txt), but the other three (BACnet Properties, Status Color

Properties, and Time Zones) are being sourced from this text file.

#

# adminfiles.txt

#

# This is a list of files that can be edited using the AdminTool.

# The entries in the list appear as menu items under the

# Host->Edit File menu of the AdminTool.

#

# The format of the lines is:

# [Menu Item Text;]file path

#

# The menu item text is optional. If excluded the menu item

# text is the name of the file.

#

BACnet Properties;/rel/nre/lib/bacnet.properties

Status Color Properties;/rel/nre/lib/statusColors.properties

Ti me Zones; / r el / nre/ l i b/ t i mezones. t xt






Host > Edit File

1–29

If necessary, you can define additional properties files to allow editing or creation on

a JACE. For example, you may wish to modify niagarad.properties on a host.

In this case, using the syntax

[Menu Item Text;]file path

add the following line to adminfiles.txt: Niagarad Properties;/rel/nre/lib/niagarad.properties

so that the uncommented portion of adminfiles.txt would look like this:

BACnet Properties;/rel/nre/lib/bacnet.properties

Status Color Properties;/rel/nre/lib/statusColors.properties

Time Zones;/rel/nre/lib/timezones.txt

Niagarad Properties;/rel/nre/lib/niagarad.properties

Then, after saving adminfiles.txt, you must close and restart the JDE. Thereafter,

when you select a JACE in the Admin Tool and use the Host > Edit File command,

you will have access to the new properties file you added.

Figure 1-13 Host > Edit File command in Admin Tool, showing added Properties file.

Notes • The adminfiles.txt file resides only your Niagara PC (Web Supervisor, JDE

engineering workstation, BACnet Supervisor, etc.), and not on a JACE.

• This is an important feature, especially for properties files on JACE-4/5 hosts,

as previously you had to use (and enable) FTP on the JACE to “put” or “get”

some of these properties files (gx.properties, bacnet.properties, etc).

FTP can be a security risk—and now you can disable it (system.properties

file on the JACE).

• In general, you should not edit any properties file on a Niagara host unless you

have been specifically directed.






Niagara Properties Files

1–30

Archiving Properties Files

With the sole exception of station.properties, all Niagara properties files are actually

“host” files (do not reside under a station directory). Whenever you upgrade Niagara

in a JACE, all existing properties files are left undisturbed . This allows for proper

station operation when the host reboots, reading the host’s license.properties file,drivers.properties entries, and so forth. However, be aware that you may need to

make changes (or add) properties files after upgrading Niagara or adding a module.

Archiving JACE properties files

If a need arises to replace a JACE, you must re-create properties files in the new

(replacement) JACE, as only station.properties is restored when you install a station.

Therefore, it is recommended that you save all previously-edited properties files.

Note This does not apply to license.properties, the digitally-signed file specific to a

particular host (JACE). That file must be obtained directly from Tridium.

Procedure 1-1 Archiving JACE properties fi les (drivers.properties, etc.)

Step 1 Open the JACE host in the Admin Tool.

Step 2 Using the recommended access method for that properties file (Table 1-3), open that

properties file in the editor.

Step 3 Click in the edit window and press CTRL-A (to select all).

All lines in the properties file should be highlighted.

Press CTRL-C (to copy to the Windows clipboard).

Step 4 Open Notepad (or similar text editor) to start a New file.

Step 5 Click in the Notepad editor and press CTRL-V (to paste from clipboard).

Step 6 Use the Save As feature of Notepad to save the copied properties file to your local

Niagara PC. Use the navigation controls and New Folder control, if needed.

It is recommended that you use a filename with a JACE-specific-prefix, for example:

JACE-NP_Floor4_drivers.properties

Step 7 Repeat steps 2 through 6 for each properties file you need to preserve.

Now, if you need to re-create properties files on a replacement JACE, you will have

copies that you can cut and paste from, as needed.

Web SupervisorConsiderations

By design, each new Niagara build installation on a PC is directed to a new build

<release> folder. Therefore, Niagara properties files are automatically archived.

Following a new Niagara installation, you typically copy any properties file that you

previously edited (from the previous niagara\<release>\nre\lib folder), along

with the existing license.properties file and adminfiles.txt. This may be

especially important for files such as drivers.properties or bacnet.properties.

http://-/?-

http://-/?-







However, first you may wish to save copies of all the new “default” properties files

before overwriting them. This allows you to compare between the old and new

versions, and possibly add new entries if needed.

List of Niagara Properties Files

Various Niagara properties files are listed alphabetically in Table 1-3. Each entry

includes the recommended method of access and a brief description. This list does

not include Niagara properties files that are exclusively “auto-generated.”

Table 1-3 Niagara properties fi les, listed alphabetically.

File Name Access Method Description / Notes

bacnet.properties Admin Tool, command

Host > Edit File

(default in r2.3.4 and laterAdmin Tool)

Applies only if the Niagara host is running a station with the BACnetservice. In the initial r2.3.5 release of BACnet, very few parameters areaccessed through the host’s bacnet.properties file. However, as laterr2.3.5 build updates become available, this may change.

For more information about bacnet.properties, refer to the NiagaraBACnet Integration Reference, r2.3.4 or later.

ddns.properties Admin Tool,Network Settings tab,Edit DDNS Properties

Starting in r2.3.4, DDNS (dynamic domain name service) support wasextended to include LAN/WAN support, in addition to the previous RAS(dialout with captive ISP). This configuration file holds the DDNSparameters.

More information may be found in the Niagara Networking &

Connectivity Guide, 2.3.x (as an updated version becomes available).

drivers.properties Admin Tool,Installation tab,Edit drivers.properties

This is an essential file for any Niagara host.

It is used to configure/specify various low-level communicationsdrivers used by the Niagara host and the JDE. You may need to editthis file on various Niagara hosts, with some examples listed:

JDE engineering PC: If configured for BACnet/Ethernet, must be

edited with Ethernet adapter name (see Niagara 2.3.x BACnet docs).Same applies if a BACnet Supervisor.

JACE-NX or NP: To configure sysmon, power monitoring limits. Referto Engineering Notes doc, Niagara Sysmon and Power Monitoring.

JACE-4/5: To configure power monitoring limits, BACnet MS/TP driverfor VxWorks.

Some integration drivers for JACEs may also require editing ofdrivers.properties (details in specific Niagara Integration documents).

Note: If your PC-based Niagara host (Web Supervisor/JDEengineering PC/BACnet Supervisor) requires edits todrivers.properties, after upgrading to a new Niagara build, you shouldcopy and paste the old (edited) drivers.properties into the newniagara\<release>\nre\lib folder, replacing the “default” one installed

by Niagara. This also applies to your license file (license.properties),plus any other properties file that you have especially edited.

This does not apply to any JACE you have upgraded, as the oldproperties files are retained.

Note: Changes to drivers.properties do not become effective for astation running on the host until the station is restarted.

http://-/?-

http://-/?-







1–32

gx.properties Admin Tool, command

Host > Edit File

Applies if the Niagara host is running a station with the WebUiService.Currently, this file allows you to specify a small delay between servingGx objects to a client browser, useful to avoid issues with animated .gif

files. For more details, refer to “gx.properties File,” page 8-15.license.properties Read Only!

Admin Tool,Installation tab,View License

Lists the features licensed for the Niagara host, plus other informationabout the host.

You should never edit this file. If you do, you will render yourNiagara host unusable!

mime.properties Admin Tool, command

Host > Edit File

(can add entry, see notes)

Typically, you do not need to edit this file on any Niagara host. It is usedby the web server to notify client browsers about the mapping of fileextensions to MIME file types, so that client browsers can useappropriate applications.

If you decide to add it to adminfiles.txt, use this entry:

Mime Properties;/rel/nre/lib/mime.properties

ndio.properties Read Only!

Menu access not recommended. Found in therel/nre/lib folder of a JACE-4,with other properties files.

Starting in r2.3.4, it applies only to JACE-4 hosts—either models withonboard I/O or that accept I/O expansion modules. It is used by theJACE and its ndio module to map indexes of Ndio objects correctly.

You should never edit this file. If you do, you will render I/O onthe JACE-4 or JACE-IO-XX as inoperable!

niagarad.properties Admin Tool, command

Host > Edit File

(can add entry, see notes)

Typically, you do not need to edit this file. Includes optional parameterto specify the TCP “Admin Port” for the host (default port is 3011). Thisis the port used for most operations from the Admin Tool.

adminPort=nnnn (where nnnn is TCP port number).

Another parameter is for the initial buffer-size, in charcters, of aStandard Output window (opened for a station running on that host):

bufferSize=5000

Another parameter can specify the name of the NT Administratorgroup, typically for non-US installations (localization). For French, e.g.:

adminGroup=administrateurs

If you decide to add this to adminfiles.txt, use this entry:

Niagarad Properties;/rel/nre/lib/niagarad.properties

nre.properties Menu access not recommended.

Found in the nre/lib folder ofany r2.3.5 Win32 host.

Applies only to Win32 hosts, to specify which JVM is used.Automatically set upon r2.3.5 installation, where the default (andsupported) setting is:

vm=hotspot

port.properties Admin Tool,Network Settings tab,Edit Port Properties

Applies only to JACE-4 hosts, to specify how serial port assignmentsCOM1 and COM2 are mapped to physical ports RS-232, RS-485, andinternal modem. Refer to the Niagara Networking & Connectivity

Guide, or to the Installation Instructions document for that JACE-4.

ras.properties Admin Tool,

Network Settings tab,Edit Modem Properties

Sometimes referred to as “modem.properties.” Applies only to JACE-4

or JACE-5 hosts. Used to both configure modems and enable thedirect-dial function on the JACE-4/5. Refer to the Niagara Networking

& Connectivity Guide for more details.

In r2.3.5, support was added for CHAP (Challenge AuthenticationProtocol), used to authenticate a user of dialup (PPP) connection.Previously, PAP (Password Authentication Protocol) was the onlyconfiguration option. Certain limitations apply to this feature.

For more details, please refer to issue #3182 CHAP support in ther2.3.5 Release Notes document (section Core, dialup).

Table 1-3 Niagara properties files, listed alphabetically. (continued)








station.properties Admin Tool, command

Station > Edit > Properti es

(station must be selected)

Unlike other properties files, which configure the host, this file isspecific to a selected station, and is stored under that station directory.Included is whether the station “auto starts” (after a host reboot),

and/or “auto restarts.” (Note that “Auto start” is configured using acheckbox dialog, with Admin Tool command Station > Configure.)

If the station is configured to use an HTTP port other than the defaultport 80, (Station object, config property: httpPort), a line is needed thatspecifies this same port (to support DB Admin functions), for example:

httpPort=85

Note: Changes do not become effective until the station is restarted.

statusColors.properties Admin Tool, command

Host > Edit File

(default in r2.3.4 and laterAdmin Tool)

Starting in r2.3.4, this file allows global customizing of the status colorsused by any station running on that host. Status colors are reflected inobject and object output colors in the JDE, linked Gx objects inGxPages (JDE and browser) and in the status servlet (browser).

Both status background (bg) and foreground (fg) colors are adjustable.

• Default status bg colors, by status/color are: alarm/red, fault/orange,down/yellow, overridden/magenta, outOfService/cyan.

• Default status fg colors, by status/color are: alarm/white, <any otherstatus>/black.

In this file, you specify status colors by their hexadecimal RGB values.For example, to change override status to show as pink (fg) on darkgray (bg) from the defaults black (000000) on magenta (ff00ff):

overridden.fg=ffafaf (pink)overridden.bg=404040 (dark gray)

See the comments in the statusColors.properties file for more details.

system.properties

(continues next)

Admin Tool, command

Host > Edit File

In earlier releases, this file was primarily used to enable or disable FTPand Telnet in embedded (JACE-4/5) hosts; this usage still applies.

For example:ftpEnable=falsetelnetEnable=false

In Niagara r2.3.3 (2.3), various “timeout” properties were added, andthe file had wider host applications (all JACEs, Web Supervisor). Also,a “garbage collection” daemon property became available for use witha host running a station with the DatabaseService and Cloudscape.

In Niagara r2.3.4, more properties were added, including several thataffect publications (sending) of external links (interstation links) andcontrol the number of processing threads to the station’s web server.

Note: Starting in r2.3.4, changes to the following properties becomeimmediately effective, without a system reboot:connectionTimeout

requestTimeout

readTimeoutsessionTimeoutgc.daemon

webServer.traceLevel

webServer.resolveIPAddress

interstationLink.reassert

interstationLink.reassert.traceinterstationLink.maxSendTime.enable

interstationLink.maxSendTime.lo

interstationLink.maxSendTime.hi

Table 1-3 Niagara properties fi les, l isted alphabetically. (continued)








1–34

system.properties(continued)

Admin Tool, command

Host > Edit File

In Niagara r2.3.5, more properties were added, including one fordisabling DirectX on Windows platform (to prevent Sun JVM conflict),a method to disable UTF-8 encoding by the MailService, and

properties to aid operation of master/slave interstation links betweenhosts running different Niagara releases.

Log archive tracing was also added, as was a configurable “steadystate delay” to permit a station, upon startup, to allow all objectsadequate execution time before enabling web server operation.

Note: Starting in r2.3.5, the system.properties entry:gc.daemon=n

is no longer necessary, as the Sun Hotspot JVM has no relatedmemory leak (DatabaseService with Cloudscape appdb). Be sure todisable this entry if present, otherwise, station performance may slow.

See the comments lines (#) in the r2.3.4 and later system.propertiesfile for explanations of the various properties. Please note thatadditional coverage of when (and why) you would change properties inthis file are planned in a future Engineering Notes document.

Note: Changes to the following properties added in r2.3.5 becomeimmediately effective, without a system reboot:archive.trace

mail.useUTF

masterSlave.checkRelease

masterSlave.releaseSpoofing.enabled

Also starting in r2.3.5, any running station provides a debug servletavailable from a browser using the URL:

http://<host>/debug

Included is “System Properties” link, with this URL (also in r2.3.4):

http://<host>/prism/systemPropertiesto review currently effective system.properties values.

time.properties Menu access not recommended.

For r2.3.5 host only, in nre/libfolder if Win32, or /sys folderif JACE-4/5 host.

Reflects the currently selected Java time zone for the Niagara host, bytime zone ID. The host’s time zone database is customizable, and isstored locally in a file named timezones.txt.

timezones.txt Admin Tool, command

Host > Edit File

> Time Zones

(default for r2.3.5 and laterAdmin Tool)

New in r2.3.5, not exactly a “.properties” file, but the host’s source timezone database, stored in its nre/lib folder as a plain text file. Usefulmainly for localization scenarios. Applies to all Niagara platforms.

Allows editing of individual time zones, where each line represents onetime zone. Each time zone begins with a time zone “ID”, which is visiblewhen selecting the host’s time zone in the Admin Tool (System Time

tab). Time zone ID is also seen in all timestamp data in the station, e.g.log records, alarms and alerts, and time-based object properties.

Other parameters in each time zone line determine the UTC offset inmilliseconds, and various start/end changeover points for DaylightSavings Time (if DST is used at all). All parameters in each time zoneare delimited using the pipe (|) symbol.

For more details, including “translated” values for each available timezone in the standard r2.3.5 timezones database, please refer to thelocalization document “Java Time Zones for Niagara r2.3.5.”

Table 1-3 Niagara properties files, listed alphabetically. (continued)






CHAPTER

2–1

2

Data Species and Links

A Niagara object is a collection of properties. Each property represents a piece of

data, and is typically a name/value pair. Properties are implemented using data types,

known in Niagara as data species. Properties that are inputs or outputs are linkable.

This chapter explains the components of properties, including data species and

attributes. Links between objects are also explained.

The following main topics are provided:

• Data Species

• Property Attributes

• Links

Data SpeciesProperties are implemented with data types (species), which fall under three general

classifications:

• Data Primitives

• Data Enumerations (Enums)

• Variable Types (Types)

Note This section explains Niagara data species, but provides only a few examples. For a

complete listing of all documented variable types and enumerations, refer to

Appendix A, “Object Property Quick Reference.”





Chapter 2 Data Species and Links

Data Species

2–2

Data Primitives

A primitive is the most basic of data types. A property implemented as a primitive

has a value expressed as one of the following:

• boolean —Either false or true.

• float (floating-point)—IEEE floating-point standard 754, 32-bit single

precision. Very small and large numbers are possible.

• int (integer)—a signed 32-bit integer, within the following ranges:

minimum: -2,147,483,648 to maximum: 2,147,483,647

Note In object property sheet fields, the integer minimum and maximum

limits above are represented as MIN_VALUE and MAX_VALUE.

• String —an ASCII text string (no theoretical character limit).

For example, the property description (a property of most object types) uses a dataspecies of type String. This is a read-write property that you can use to describe the

object. For most object types, the default value of this property is empty.

Data Enumerations

Some data species use enumerations. An enumeration is simply a numbered list with

a choice of values. There are about 40 documented enumerations used among data

species. Refer to the “Enumerations” section on page A-53 for a complete listing.

For example, WeekdayEnum is an enumeration for days of the week, with the

following definition:• Sun (0)

• Mon (1)

• Tue (2)

• Wed (3)

• Thu (4)

• Fri (5)

• Sat (6)

As with primitives, some properties are implemented with just one enumeration. For

example, the property eventState, a status property in many control objects, uses a

data species of EventStateEnum. This enumeration is defined as follows:

• normal (0)

• fault (1)

• offnormal (2)

• high_limit (3)

• low_limit (4)

• unknown (64)




Data Species



Variable Types

Like data primitives, enumerations can be used as “pieces” in other data species,

called structured types. Structured data species are defined by some combination of

data primitives, enumerations, and sometimes other (nested) structured data types.

Structured data species are classified as variable types, along with the four primitivedata types. There are about 32 documented variable types. Refer to the “Variable

Types” section on page A-49 for a complete listing.

For example, the DateTimeTrigger object has an engineering property, lastTrigger,

that uses the variable type DateType. This data species is structured with the

following data fields in its definition,

where: rw means read-write capable, and r means read-only:

• year rw int

• month rw MonthEnum

• day rw int

• weekday rw WeekEnum

• nextDay r DateType

• prevDay r DateType

Note that data fields year and day are primitives (int), while fields month and

weekday are enumerations. Data fields nextDay and prevDay both use the definition

of the variable type DateType.

Status andPriority Types

Among the variable types are two important classes used for many input and output

(linkable) properties, particularly among control objects. These two classes of

variable types are:

• Status Types —Each is a primitive value and a “status flags” enumeration.

• Priority Types —Each is a primitive value and a control-priority enumeration.

Status Types

Status-variable types are used in object input and output properties named

“statusInput” (sIn) and “statusOutput” (sOut), and include these variable types:

• booleanStatusType

• floatStatusType

• integerStatusType

Each has two components, the primitive data value and a status flags component. The

status flags component provides a general indication of “health” of the received

property value (if a statusInput), or of the object itself (if a statusOutput).

Note Status flags for a statusOutput (sOut) property are reflected by the object’s

statusFlags property (visible on the objects property sheet, Status tab).






Data Species

2–4

Status flag enumerations include: inAlarm, fault, overridden, outOfService,

unackedAlarm, down. Depending on object type, these may be set in combination.

The normal or “ok” condition is for all status flags to be cleared. If viewing objects

in the JDE Workspace, any statusOutput in “ok” condition shows the value, in normal

color. However, if status flag(s) become set, this is indicated by color change of the

statusOutput and the object shape, as follows:

• orange —fault

• yellow —down

• red —inAlarm

• cyan (light blue)—OutOfService

• magenta —overridden

Note If a fault or down condition is received at a linked statusInput (or other input using a

“status type” data species), the object uses its configured “default” input value, if

available. Object types such as AnalogInput, BinaryInput, Comparison, IntToFloat,

Logic, Loop, Math, MultistateInput, and Totalizer, have such configuration

properties.

Priority Types

Priority-variable types are used in object input and output properties named

“priorityArray” (pIn) and “prioritizedOutput” (pOut), with these variable types:

• BooleanPriorityType

• FloatPriorityType

• IntegerPriorityType

Priority variable types each have these three components:

• value —The primitive data, either boolean, float or integer.

• auto —A boolean, true only while all control-priority slots are empty.

• priority —The active control priority-level, whether received (priorityArray),

or generated from the object itself (prioritizedOutput). Control priority

enumerations include 16 levels, from highest (1) to lowest (16).

Objects that have both priorityArray inputs and prioritizedOutputs include the

“commandable” types, such as AnalogOutput, BinaryOutput, and MultistateOutput.

Other objects have prioritizedOutputs, including the BinaryOverride, Comparison,

FunctionGenerator, Logic, Loop, Math, MultistateOverride, and Schedule objects.

Note For an explanation of how the Niagara control priority scheme operates, refer to the

“Priority Levels” section on page 5-46. Although this explanation references the

BinaryOutput (BO) object, priority levels are evaluated in the same way for the

AnalogOutput and MultistateOutput objects (objects with priorityArray input).




Property Attributes



Property AttributesApart from the data species a property uses, it also has a number of attributes. These

attributes determine the following about the property’s usage:

• Read/Write access—read-only (status) or read-write.• Station storage options—Property’s value is either:

– stored to disk (flash), that is: persistent

– operating only in RAM, that is: transient

– typically stored to disk (flash), but may be subject to change in a shadowed

foreign device. A fetch command may be necessary to update the station

with the latest value. This is called on_demand_transient.

• Input/Output/Internal—whether the property is available as a linkable input or

output (or not). If available, whether it appears by default on the object shape.

• User (Security) Access—whether the property is accessible to a station user

with Operator-level property access, or only Admin-level property access.

For example, a property may be either readable or both readable and writable. It may

be persistently stored. It may be a linkable input or output, or an internal value only.

It may be accessible (on the JDE property sheet) at both the Operator and Admin

levels, or only the Admin level.

Refer to Appendix A, “Object Property Quick Reference,” for listings of each

property’s attributes, as well as an explanation of “Attribute Notation.”

Links

Most Niagara objects have one or more properties that you can link to another objectto establish data relationships. Examples include control objects, apps objects, Gx

objects, and integration (shadow) objects.

Note Some objects are not typically linked, for example, Container objects.

A linkable property is typically either an output or an input, and a link connects an

output to an input.

The following link-related topics are explained ahead:

• Link Editor

• Link Categories

• Link Types

• Link Rules

• Link Data Flow

• Link Resources






Links

2–6

Link Editor

The JDE provides a Link Editor you use to establish links between any two selected

objects. The Link Editor simplifies link choices by indicating, by color, which

properties of an object are available (after you select a property of the other object).

As shown in Figure 2-1, selecting the first property (in this case, prioritizedOutput)

of one object results in the isolation (using the color green) of the properties in the

other object can be selected for a link. In this case, only one property is available for

linking, namely, the priorityArray input.

Properties that cannot be selected are colored red. Reasons for properties showing as

unlinkable (red) include:

• Incompatible data species, which must match (except for Gx object links).

• An input property is already linked, and can accept only one source (typical).

Figure 2-1 Link Editor pre-validates links by showing only linkable properties as green.

After you select a compatible property in the second object, the link to be made

appears listed in the right-side, showing the link type, object names and properties

(the “Service” column applies only if a LonWorks shadow object is involved).

You can select multiple links to be made before selecting the OK button, if needed.

An OK makes the link between the selected properties and closes the Link Editor.

Note In the property lists, the arrow icons must point in the same direction for a link.

Color of the arrow icons indicates the general type of the property, either boolean,

float, integer, or trigger. In the JDE, these property colors are adjustable, using the

menu bar options View > Options > Property Colors.

After selecting two compatibleproperties, the pending link is listedon the “Links” side. This lists the linktype and the properties to be linked.




Links



Links View In addition, for any object, a right-click Links view is available when using the JDE

(Go > Links), as shown in Figure 2-2.

Figure 2-2 Links view of a selected object lists all links to and from the object.

The Links view lists all existing links for the selected object, including each link’s:

• Type

• Property

• Other swid

• Other Property

• Service (typically applies only if a LonWorks-related link)

Note The Links view for any object is also available from a Web browser connection, providing that the station has the WebUIService. The URL requires the station swid

of the object, ending with string “$Links”.

For example:

ht t p: / / 192. 168. 1. 2/ db/ demoR2/ Si m/ Logi c/ Ai r Handl er/ cool i ngCoi l $Li nks

Link Categories

A link connects two Niagara objects. From a connection standpoint, any link can be

categorized as one of the following:

• Local Link

• Internal Link

• External Link

A typical Niagara station is engineered with many local and internal links. Unless it

is a standalone JACE station (no Web Supervisor), there are typically external links

as well.






Links

2–8

Local Link A link between objects in the same container . When using the JDE and viewing the

container in the either the Workspace or WorkspaceEditor, each link shows as a line

connecting the two objects (Figure 2-3).

When you mouse over the link, the status bar reports the logical type of the link,

either “normal”, “ui”, or “trigger.”

Figure 2-3 Local l inks are the only kinds visible in the Workplace view.

Internal Link A link between two objects in the same station, but in different containers. When

using the JDE and viewing either object in the WorkspaceEditor, the link appears at

the object’s input or output as a small shaded box with a letter, “a” to “z” (or if

needed, “aa” to “az”) as shown in Figure 2-4.

When you mouse over the link box, the status bar shows the swid of the linked“object.property”.

Figure 2-4 Internal links show in the WorkspaceEditor as shaded boxes with letters .

Status bar shows thetype of local link whenyou mouse over.

Status bar shows “InternalLink” and the target swidof the linked propertywhen you mouse over.




Links



External Link Sometimes called an interstation link, an external link is between objects in different

stations. When using the JDE and viewing either object in the WorkspaceEditor, the

link appears at the object’s input or output as a small box with a numeral (0 to n). The

default color of the link box is white.

When you mouse over the external link box, the status bar shows the link as either:

• externalSubscription (at an input), plus the swid of the linked object.property.

• externalPublication (at an output), plus the swid of the linked object.property.

Figure 2-5 External links show in the WorkspaceEditor as shaded boxes with numbers.

Notes • External link processing requires AddressBook setup in both stations. Refer to

the “AddressBook” section on page 1-15.

• Only receiving (externalSubscription) link configuration is persistently stored

in a station database. Output (externalPublication) links are transient, and are

visible only while an external station is actively subscribed.

• The interstationSendTime property of the Station object specifies the wait time

used before pushing change-of-value updates to externally linked objects in

subscribed stations. The default send time is every 5 seconds (5000 ms); the

minimum send time is every 500ms. In r2.3.4 and later, other parameters

affecting interstation links can be set in the host’s system.properties file.

• The prism servlet provides a special “snapshot” listing of external links in a

station, useful for troubleshooting purposes. It is available from the JDE or aWeb browser connection to any Niagara station, at URL:

ht t p: / / <host >/ pr i sm/ external Li nks (also from new r2.3.5 debug servlet).

• No more than 50,000 external links should be made in a Web Supervisor

station. This limit was empirically established based on data from actual jobs.

• See the “Link Rules” section on page 2-11 for special restrictions that apply to

external links.

Status bar shows the target swid of thelinked property when you mouse over.






Links

2–10

Link Types

Links are further categorized logically, with the following types possible.

• Normal

• UI• Trigger

• Composite

• LonTalk Local Bindings

• LonTalk Network Bindings

Normal: A normal link describes most links made between objects except one

including a Gx object. This includes links between other object types, typically

control objects, apps objects, and integration objects. When using the JDE and

looking at the Links sheet for either object, the link type shows as “normal.”

UI: User Interface—any link between a Gx object and another type of object.

Typically, the other object is a control object, apps object, or integration object. When

using the JDE and looking at the Links sheet for either object, the link type shows as

“ui.”

Trigger: A link between trigger-type properties of the two objects. Trigger links

initiate actions of objects, instead of moving data (values, status, strings). When

using the JDE and looking at the Links sheet for either object, the link type shows as

“trigger.”

Composite: A link to an object inside a Bundle, Composite, or GxPage container

that allows it to be exposed on the parent object. This scheme allows “encapsulation”

of important inputs and outputs to be represented on a simplified object (the parent

Bundle, Composite, or GxPage object).

When using the JDE and looking at the Links sheet for the exposed child objects and

the parent object, the link type shows as “composite.”

LonTalk Local Bindings: A link between a standard Niagara object (typically a

control or apps object) and a Lon device (shadow) object. The Lon shadow object

resides under the LonTrunk container in the station database. When using the JDE

and looking at the Links sheet for either object, the link type shows as

“localLonBind.”

LonTalk Network Bindings: A link between two Lon device objects. The Lon

device objects reside under the LonTrunk container in the station database. When

using the JDE and looking at the Links sheet for either object, the link type shows as“lonNetBind.”




Links



Link Colors In the JDE menu bar option View > Options > Link Colors, you can assign each link

type a color. Link colors apply to all link categories, meaning local link (lines) and

link boxes (internal and external links). Usually, link colors are left at defaults.

It is helpful to learn link colors, so you can quickly distinguish link types when

viewing containers in the WorkspaceEditor.

Note Link colors is a JDE “tool” setting, not associated with any particular station.

Figure 2-6 Link colors are editable from the JDE menu bar View > Optio ns menu.

Link Rules

In most cases, in order for two properties to be linked, they must use the same

data species. In a link, one object’s output supplies the value (or trigger) used by

the other object with the receiving input. The Link Editor in the JDE enforces this

rule when you select a property on one side of the window to link.

Note An exception to the need for matching data species occurs when linking Gx objects,which have only inputs. For example, the “binding” input of a GxText object can be

linked to any internal (configuration property) of another object, in addition to most

output properties. When linked to an internal property, a GxText object displays text

showing the value of that property.

Unlike “normal” links, Gx object links are considered user-interface (“ui”) links, not

part of “control logic.” Instead, they provide the building blocks of a user interface.

The “Background” color for each link type is themain color used.

The default Background color for each link typeis as follows:

Link Type Color

normal link blue

trigger link black

Lontalk Local Binding black

Lontalk Network Binding green

ui link gray

composite link yellow

external link white






Links

2–12

The Link Editor also enforces additional link rules, which you may wish to know

when attempting links.

1. You can link as many inputs to a single output as needed (“one-to-many”).

2. For any input property that is already linked, no further link to it is permitted

unless the property is a priorityArray type or trigger type (or certain types ofLon properties). Only then is a “many-to-one” link allowed.

3. External links (between stations) have further restrictions. The following types

of external links are not permitted (nor are they shown in the Link Editor):

a. Links between prioritizedOutputs and priorityArray input properties.

b. Links between properties using triggerType data species.

c. Links from a GxText object to an internal property of another object (only

inputs or outputs are available).

Link Data Flow

All links are configured the same way, using the Link Editor in JDE. However, data

flow in a link occurs in one of several ways, depending on linked properties. All data

flow in a link occurs as one of the following:

• Pull data

• Push data

• Event-based (trigger) data

• Master/slave data

Pull data: This is the typical method of data transfer in a link. When an object

executes, it reads all of its inputs, and pulls the data into its input properties. The input

(receiving side of the link) can be linked to only one object output. However, any

output can be, and often is, linked to multiple inputs (one-to-many).

Push data: This occurs when linking prioritizedOutputs to priorityArray inputs.

The priority array scheme allows an input to receive a command plus a priority level

from more than one source, that is, the input can be linked to multiple outputs

(many-to-one). The command at the input with the highest priority “wins” control of

the object. (Priority levels are from 1-to-16, highest-to-lowest).

When you link multiple prioritizedOutputs to the priorityArray input of a

controllable object (for instance, a BO, AO, or Loop), these links push values

(active/inactive/auto) into their respective array slots of the input.

Event-based (trigger) data: This occurs when linking a trigger-type output and

input. A “fired” trigger typically initiates an action in another object. For example,

each log-type object has two special trigger-type inputs (doArchiveTrigger and

doClearTrigger) that perform special actions (as named). These inputs can be

connected to the trigger-type outputs available in the Command, PeriodicTrigger,

and/or DateTimeTrigger object, as needed. Note that trigger-type properties are

similar to priority-array properties in that “many-to-one” links are allowed.




Links



Master/slave data: The Calendar, Schedule, and NotificationClass objects have

masterOut and slaveIn properties for establishing special links between like-type

objects. This feature allows changes in the master object to be replicated in slave

objects. These properties are especially suited for linking between different stations

(external links). Note that if the communications link between stations is broken, the

slave object retains its current configuration and continues its operation.

Link Resources

Each link between objects consumes a small amount of RAM memory. In the JDE, a

running station’s usage of RAM is measured with “resource count.” The resource

count is a numerical value that can be viewed for the entire station, or any

object-level portion of it.

In further sections where each object type is described, a “Resource Count Range”

figure is provided. For example, an AnalogInput (AI) object is listed as having a:

Resource Count Range: 63 to 116

It is important to note that this range does not include link resources, only what

resources are consumed by the object itself (by editing internal properties from

default values). Each link to (or from) the object consumes additional RAM,

incrementally adding to resource count. While values at the object-level are small

(typically a resource count of 2 or 3 for each link) it is worth noting.

Remembering that a link affects two objects, the following resource count values

show the approximate station-level resource counts, per link.

Check the resource count for a station by opening it in the JDE, selecting the station

(or portion of) in the Tree View, and selecting Search > Resource Count from the

menu bar (or use the ALT-R shortcut).

For related topics on station resources, refer to the “Station Limits and Guidelines”

section on page 1-24.

Table 2-1 Link resource counts, station-level, per l ink.

normal ui trigger composite external

5 5 8 12 3






Links

2–14





CHAPTER

3–1

3

Commands and Views

Niagara objects have various commands, depending on the object type and signon

level of the station user. In addition, objects have “standard” views to access their

properties and links. Some object types also have special views for other purposes.

The following general topics are explained in these sections:

• Commands

• Views

CommandsCommands for objects in a running Niagara station vary by object type. Commands

can provide control functions, such as with a BinaryOutput object or administrative

(admin) functions, such as with a Station object.

The following topics apply to commands:

• Control Commands

• Admin Commands

• All Available Commands

Control Commands

Control commands apply mainly to “commandable” control objects. Commands are

available only if the user has “Std” (standard) or “Emer” (emergency) level command

rights for a security group assigned to that object.

For example, if a JDE user is signed on with sufficient command privileges, aBinaryOutput (BO) object provides the user with right-click commands to set it

active, inactive, or in auto (Figure 3-1, left). If the object is linked to a Gx object in

a GxPage, the same command menu is available from a browser, by right-clicking on

a linked Gx object (Figure 3-1, right).

Note Command access through a Gx object is validated using the Gx object’s

securityGroups property. Refer to “Providing Command Access,” page 8-6.





Chapter 3 Commands and Views

Commands

3–2

Figu re 3-1 Righ t-c li ck Control commands are available for many Niagara objects.

Admin Commands

Administrative ( Admin) commands apply to various standard Niagara objects,

including the Station object, and various apps, service, control objects. For example,

if a JDE user is signed on with sufficient command privileges, an AnalogLog object

provides the user with right-click commands to clear (the log buffer), archive, or

clear the last archive (Figure 3-2, left).

If the object is linked to a Gx object in a GxPage, the same command menu may be

available from a browser, by right-clicking a linked Gx object (Figure 3-1, right). Gx

object securityGroup settings apply (see “Providing Command Access,” page 8-6.)

Figu re 3-2 Righ t-c li ck Admin commands are available for many Niagara objects.

Note Typically, these commands are available only if the user has Admin-level command

rights for a security group assigned to that object (or to the Gx object).

Admin-level commands are available in the JDE using two methods:

• From the pull-down Command menu on the JDE menu bar, when the object’s

property sheet is displayed in the Workspace. All commands are included.

• From a right-click menu for the object, from its Workspace (monitor mode).

Depending on the object type, not all Admin commands may be available on

an object’s right-click menu (for example, with the BinaryOutput object).

However, commands that are right-click-accessible are also typically available

through a linked Gx object, using a Web browser connection.




Commands



All Available Commands

Table 3-1 alphabetically lists all standard (and Ndio) Niagara objects that have

runtime commands. Included are default commands, whether they are available as

right-click commands or from the JDE only, and the user’s required security rights.

Notes • Control commands require “Std” or “Emer” level security command rights.

Admin commands typically require “Admin” level security command rights.

• Control commands for AnalogOutput, BinaryOutput, and MultistateOutput

objects have editable command tags. Menu commands provided in Table 3-1

are merely defaults.

• “Dump” commands are not listed. A “debug-type” command, it is available for

most objects (from the JDE menu bar). It has development use only.

Table 3-1 Commands for standard (and Ndio) Niagara objects.

Object Type Default Menu CommandsRight

Click

JDE

Only

Security “ ommand ” Rights

Std Alarm Emer Admin

Adm inTool searchAndReplace — — — AnalogInput resetAckedTransitions — — — AnalogLog clear

archiveclearLastArchive

— — —

AnalogOutput resetAckedTransitions — — — SetAuto

— — —

Emergency SetEmergency Auto

— — — —

AnalogOverride overridecancelsetOverrideValue

— — —

Aud itLogServ ice clear archiveclearLastArchive

— — — —

BackupService ForceBackupCancelBackup

— — — —

BinaryInput resetAckedTransitionsresetChangeOfStateCount

resetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — — —

BinaryLog clear archiveclearLastArchive

— — — —






Commands

3–4

BinaryOutput resetAckedTransitionsresetChangeOfStateCountresetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — — —

ActiveInactiveAuto

— — — —

EmergencyActiveEmergencyInactiveEmergencyAuto

— — — —

BinaryOverride override Activeoverride Inactivecancel

— — —

Command

*(commands do notappear unless theseproperties are edited)

(outputTriggerTextA)*(outputTriggerTextB)*(outputTriggerTextC)*(outputTriggerTextD)*

— — — —

ControlEngineService resetStatistics — — — —

CpAnalogNode (commandText)* CpBinaryNode (commandText)* CpIntegerNode (commandText)* CpStringNode (commandText)* DatabaseService Open

Close

DateTimeTrigger clear — — —

ErrorLogService clear archiveclearLastArchive

— — — —

IntegerLog clear archiveclearLastArchive

— — — —

LogService clearLastDailyArchivearchiveAll

— — — —

Loop resetAckedTransitions — — — — enableDebug

disableDebug

— — —

MailService deleteOutbox — — — — MultistateInput resetAckedTransitions

resetChangeOfStateCountresetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — — —

Table 3-1 Commands for standard (and Ndio) Niagara objects. (continued)


Click

JDE

Only

Security “ omma nd” Rights





Commands



MultistateLog clear archiveclearLastArchive

— — — —

MultistateOutput resetAckedTransitionsresetChangeOfStateCountresetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — —

SetAuto

— — — — —


— — — —

MultistateOverride overridecancelsetOverrideValue

— — — —

Ndio0to10VInput resetAckedTransitions — — — Ndio0to10VOutput resetAckedTransitions — — —

SetAuto

— — —


— — — —

NdioBinaryInput resetAckedTransitionsresetChangeOfStateCountresetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — — —

NdioBinaryOutput resetAckedTransitionsresetChangeOfStateCountresetActiveTimesetChangeOfStateAlertLimitsetRuntimeAlertLimit

— — — —

ActiveInactiveAuto

— — — —

EmergencyActiveEmergencyInactiveEmergencyAuto

— — — —

NdioHighSpeed

CounterInput

resetAckedTransitions — — — resetCounter

NdioResistiveInput resetAckedTransitions — — — NdioThermistorType3

Input

resetAckedTransitions — — —

PeriodicTrigger reset — — —

Schedule cleanupSpecials — — — — ServiceContainer Restart Station — — —



Click

JDE

Only

Security “ ommand ” Rights







Views

3–6

GeneralCommandNotes

In general, commands are particularly important with control objects, apps objects,

integration objects, the Station object, and in some instances, service objects.

Commands are less important for container-type objects, and do not apply to

notification objects.

Gx objects have no commands. However, remember that if linked to another object

(typically a control object or apps object), the Gx object effectively assumes the

identity (including commands) of the linked object during runtime. Commands are

explained in context for each particular object type, in sections ahead.

Views Niagara objects have different views, which appear in the right pane of the JDE.

Some views are also accessible using a Web browser connection.

Object views can be generally classified into two classes:

• Standard Views

• Special Views (facets)

Note Each object type has a default view. The default view that appears in the right pane

of the JDE after you double-click the object in the Tree View.

Standard Views

When working in the JDE, every Niagara object has the following standard “Go”

menu views:

• Properties —The object’s Property Sheet . This is the default view for many

object types, including all control objects. Depending on your security rights

for the object, all or only some properties may be shown and/or modifiable.

Station Backup XMLBackup SNSBackup Subordinates XMLBackup Subordinates SNSRestartRebootStack Dump

— — — —

StringLog clear archiveclearLastArchive

— — — —

TimeSyncService syncToServer — — — — Totalizer resetTotal — — — — UiEngineService resetStatistics — — — —



Click

JDE

Only

Security “ omma nd” Rights





Views



• Links —Lists all links made to (and from) the selected object, as shown in

Figure 2-2. Not the default view for any object type.

• Report —Provides a form in which you choose items about the selected object

to be “printed” in a text report. Also not the default view for any object type.

Selectable items include properties, links, and child objects. Text from a

generated report appears below the report form, and can be exported (saved) toa file or directed to a printer.

Note If a station has the WebUiService, read-only versions of properties and links views

are available for any object from a Web browser connection. The URL requires the

station swid of the object, ending with string “$Properties” or “$Links”.

For example:

ht t p: / / 192. 168. 1. 2/ db/ demoR2/ Si m/ Logi c/ VAVs/ VAV1/ Damper$Pr opert i es

StandardContainer Views

For all container-type objects (except for the ServiceContainer), the followingadditional JDE “Go” views are also available:

• Workspace —Also called “monitor mode,” this is the runtime view showing

the container’s child objects, with values updating in real time. This is the

default view for most container-type objects.

• WorkspaceEditor —The “edit mode” for the container, where child objects

can be added, linked, cut, duplicated, and so on. Available only if the user has

Admin write privileges for the container object.

Note Using a Web browser connection, only GxPage objects offer a Workspace view

(default view). The station must have the WebUiService for this feature.WorkspaceEditor views are never browser-accessible (the JDE is always required).

Special Views

Some object types have special views. Sometimes called facets, these views provide

a graphical representation of the object’s configuration or status. For example, when

using the JDE, the following objects have default views:

• Schedule objects have a ScheduleEditor view. This view allows the user to

review and adjust schedule event times for the selected object using the mouse.

• Log objects (AnalogLog, BinaryLog, IntegerLog and MultistateLog) providea LogChart view to show the object’s log data visually graphed, complete with

controls for zooming, time scaling, and various other adjustments.

• Calendar objects have a Calendar view for reviewing and entering calendar

dates.

If the station has WebUiServices, the equivalent graphical views for the objects

above (Schedule, Calendar, log-types) are provided to a user accessing the station

using a Web browser.






Views

3–8

JDE-OnlySpecial Views

Other types of objects have special views that are accessible only when using the

JDE. Typically, these are system-configuration views, such as the Station object’s

AddressBook and UserAdmin views.

Some special views are called “managers.” For example, the ServiceContainer object

has a ServiceManager view ( page 7-35) shows a tabular listing of all station services,

providing central access to commands for any selected service.

Manager views are also typical for integration services, such as for LonWorks and

BACnet. For example, the LonWorksService object has three right-click views:

• LonDeviceManager

• LonLinkManager

• LonUtilityManager

Refer to the appropriate integration reference for more details on manager views.

All Available ViewsTable 3-2 alphabetically lists all standard (and Ndio) Niagara objects with available

views. Included is each object’s default view and any special views.

Notes • A minimum of Operator-level read privileges is needed to access most

standard and special views.

• Admin-level write privileges are needed to access:

– Any container object’s WorkspaceEditor view.

– The Station object’s AddressBook view.

– The DatabaseBrowser view for DatabaseService. – A Program object’s Program Editor and Program Debugger views.

• Admin-level write privileges are also needed to add, delete, or modify Calendar

or Schedule events, using those objects’ special views.

Table 3-2 Available views for standard (and Ndio) Niagara objects.

Object Type Default ViewSpecial Views

(* if JDE Only)

Standard Views

Properties Links Report Workspace Workspace

Editor

AdminTool Properties — — —

AnalogInput Properties — — —

AnalogLog LogChart LogChartLogTable

— — —

AnalogOutput Properties — — —

AnalogOver ride Properties — — —

ApiRecip ient Properties — — —

http://-/?-

http://-/?-




Views



Aud itLogServi ce LogTable LogTable — — —

BackupService Properties — — —

BinaryInput Properties — — —

BinaryLog LogChart LogChartLogTable

— — —

BinaryOutput Properties — — —

BinaryOverride Properties — — —

Bundle Workspace — Calendar Calendar Calendar

CalendarSummary*EntryList*

— — —

Command Properties — — —

Comparison Properties — — —

Composite Workspace — Container Workspace — ControlEngineService Properties — — — —

CpAnalogNode Properties — — —

CpBinaryNode Properties — — —

CpIntegerNode Properties — — —

CpStringNode Properties — — —

DatabaseService DatabaseBrowser DatabaseBrowser* — — —

DateTimeTrigger Properties — — —

ErrorLogService LogTable LogTable — — —

FunctionGenerator Properties — — —

GxBarGraph Properties — — —

GxBoolean Properties — — —

GxDamper Properties — — —

GxFan Properties — — —

GxFloat Properties — — —

GxImage Properties — — —

GxInteger Properties — — —

GxPage Properties — — —

GxPipe Properties — — —

GxSpectrum Properties — — —

GxText Properties — — —

Table 3-2 Available views for standard (and Ndio) Niagara objects. (continued)


(* if JDE Only)

Standard Views


Editor






Views

3–10

GxTimePlot Properties — — —

IntegerLog LogChart LogChartLogTable

— — —

IntToFloat Properties — — —

LogService Properties — — — —

Logic Properties — — —

Loop Properties — — —

MailRecipient Properties — — — —

MailService Properties — — — —

Math Properties — — —

MultistateInput Properties — — —

MultistateLog LogChart LogChartLogTable

— — —

MultistateOutput Properties — — —

MultistateOverride Properties — — —

Ndio0to10VInput Properties — — —

Ndio0to10VOutput Properties — — —

NdioBinaryInput Properties — — —

NdioBinaryOutput Properties — — —

NdioContainer Workspace —

NdioHighSpeedCounter

Input

Properties — — —

NdioProcessor Workspace — NdioResistiveInput Properties — — —

NdioThermistorType3

Input

Properties — — —

NotificationClass Properties — — —

NotificationService Workspace — — PeriodicTrigger Properties — — —

PollAlways Workspace — PollArchiveService Workspace — PollOnDemand Workspace — PrinterRecipient Properties — — — —

Program Properties ProgramEditor*ProgramDebugger*

— — —

RemotePrinterRecipient Properties — — — —



(* if JDE Only)

Standard Views


Editor




Views



General ViewNotes

Views are discussed in context for each particular object type, in sections ahead. In

particular, all properties for each object (as grouped on property sheet tabs) are

explained.

Schedule ScheduleEditor ScheduleEditor EventCalendar*

— — —

ServiceContainer ServiceManager ServiceManager* — — —

Station Properties AddressBook*UserAdmin*ActiveUsers*Alarms*

StringLog LogTable LogTable — — —

TimeSyncService Properties — — — —

Totalizer Properties — — —

UiEngineService Properties — — — —

WebUiService Properties — — — —



(* if JDE Only)

Standard Views


Editor






Views

3–12





CHAPTER

4–1

4

Services

This chapter provides information on each of the standard Niagara service objects,

including all those provided in the tridium JAR file of the local library. General

information on services is provided first, as follows:

• About Services

– Core Services

– Additional Services

• General Notes on Services

– About Licensing

– Adding or Removing Services

– Common Service Object Properties

Individual service object descriptions follow, arranged alphabetically as follows:

• AuditLogService

• BackupService1

• ControlEngineService

• DatabaseService

• ErrorLogService

• LogService

• MailService

• NotificationService

• PollArchiveService2

• TimeSyncService

• UiEngineService

• WebUiService

Refer to Refer to the Vykon Alarm Service Installation and Configuration Instructions for

details about the VykonAlarmService, included with a Web Supervisor.

1. Requires Niagara release 2.2 or higher.

2. The PollArchiveService is found in the tridiumx folder, under the “multisite” JAR file.





Chapter 4 Services

About Services

4–2

About Services Niagara services are special types of objects that publish themselves to other objects

in a station. As plug-in modules, they enable a station to accomplish its application

mission. There are two basic categories of Niagara service:

• Core Services

• Additional Services

Core Services

The following services be considered “core,” as they exist by default in any station’s

ServiceContainer (added automatically by the New Station wizard). This applies to

any Niagara station, regardless of platform (Web Supervisor, JACE-NP, JACE-4/5).

• NotificationService —Alarm delivery to supervisor.

• ControlEngineService —Execution engine for most objects (control included).

• UiEngineService —Execution engine for Gx objects.

• LogService —Provides log support.

• AuditLogService —Logs user modifications made to the station database.

• ErrorLogService —Logs configuration and software errors.

Core services are licensed by the “coreRuntime” entry in the license.properties file.

See the “About Licensing” section on page 4-3 for more information.

Optional CoreServices

In addition to the “basic” core services listed above, optional core services can also

be added. These include the BackupService, MailService, and TimeSyncService.

You can select them when running the New Station wizard, or add them anytime later by copying and pasting from the Local or Remote Library.

Note The New Station wizard preselects the WebUiService by default, as well. However,

be aware that for a JACE controller, this service requires a host license, and the

necessary hardware configuration (models ready and licensed for the WebUiService

have a “UI” model-number suffix, such as JACE-512-UI, JACE-401-UI, and so on).

Additional Services

A Niagara station will have additional services besides just core services. Theseadditional services vary by the host platform.

• A Web Supervisor station includes the DatabaseService and WebUiService,

which are individually licensed features. A Web Supervisor also typically has

some number of optional core services.

Starting in r2.3 (build 2.301.330b), a Web Supervisor also included the

VykonAlarmService, and in r2.3.4 and later could (optionally) include

Ethernet-connected Protocol Services such as BACnet or OPC.



Chapter 4 Services

General Notes on Services



• A station for a JACE controller may (or may not) include the WebUiService

and/or DatabaseService, depending on its model type (the DatabaseService is

not supported by a JACE-4/5 controller). More importantly, a JACE controller

station will have one or more Protocol Services.

ProtocolServices

JACE controller stations require additional services for protocol support ofnetworked devices. An example is the BACnetService, which is licensed for any

JACE controller. In addition to this service, other open protocol services may be

required, such as the ModbusAsyncService or LonWorksService. Vendor-specific

protocol services are also available for many legacy control systems.

Note Device-support protocol services (commonly called “drivers”), are not covered in

this document. For more information on these services, please refer to the

appropriate Niagara integration document.

General Notes on Services Niagara services have common characteristics that are explained in this section. The

following topics apply to all services:

• About Licensing

• Adding or Removing Services

• Common Service Object Properties

About Licensing

Niagara services must be licensed in the host running the Niagara station. Licensing

is done using a license.properties text file, which resides in the nre/lib folder under

the Niagara release directory of the host machine (Web Supervisor PC, JACE-NX,

JACE-NP, or JACE-4/5 controller).

Caution Each license.properties file is a “digitally-signed” file, and is specific to its particular

host machine. Changes to this file, if any, must be performed through Tridium. Any

other attempt to alter or copy this file will render the Niagara software unusable.

In the license.properties file, the “features” line is where licensed services appear.

Your can use the Admin Tool to open a connection to any Niagara host and view itslicensed features, as shown in Figure 4-1.

Note Licensed features are separated from each other by a semicolon (;).





Chapter 4 Services


4–4

Figure 4-1 Niagara services are licensed by inclusion in the “features” line of the host’s license.properties file.

All services explained in this document are licensed by the “coreRuntime” entry in

the features line of license.properties, with the following exceptions:

• WebUiService —Requires a feature line entry of: webUi

• DatabaseService —Requires a feature line entry of: database

• PolledArchiveService —Requires a feature line entry of: multisite

Note The Admin Tool provides an “Install New License” command from its main menu.You should use this whenever installing an updated license.properties file that you

have received from Tridium.

Adding or Removing Services

Add a service to a running station by opening the station in the JDE and then using

the Tree View to copy the service needed from the Local Library (or Remote

Library). Paste the copied service in the ServiceContainer in the root of the station.

Notes • A newly-added service will not be active until you restart the station.

Often, you may wish to define service properties before you perform a station

restart. This way, the service will initialize and operate in the intended manner.

• The host must be licensed for the service. See “About Licensing,” page 4-3.

• Services are “one-only” in a station. Do not add a service that already exists.

• The BackupService is intended only for stations running the DatabaseService

(Web Supervisor or possibly a JACE-NP). It has no use in a JACE-4/5 station.

This license.properties is for a JACE-NP, which in addition to coreservices (coreRuntime) and device-related services, is licensed forthe WebUIService and DatabaseService (webUi, database).

features=lonworks;bacnet;webUi;coreRuntime;vlon;database



Chapter 4 Services




You can remove a service, if needed, by simply opening the station in the JDE and

using the Tree View to select and “cut” it. However, you should be careful about

deleting services, particularly if the station has been operating with it.

Common Service Object PropertiesService objects each have a small group of properties standard to most Niagara

objects. They are explained in Table 4-1, which lists common properties organized in

the property sheet tab in which you can find them. In the case where some property

variation exists for a particular type of object, that difference is noted in the property

table for that object type.

Table 4-1 Common propert ies for al l service objects.


S t a t u s

objectType Read Only: The service object type. Bydefault, a newly added service uses this

string in its name (unless renamed).The full string for the object type is shown,for example, BackupService or LogService.

See description reflectsobject type

statusFlags Read Only: Current state of the object’sstatus flags. A “normal” state (no flags set)is where the status flags value is “ok”.

The only status flag that can be set is:

• down—The station is down or offline.

either:

ok (no flags)

or

down

ok Unlike some other objecttypes, service objects donot have alarm states.

description Read-Write: Permits a user-defined textdescriptor for describing the service. Anyprintable characters, including spaces andmixed case characters, are allowed.

See description —

V i s u a

l

position Read-Write: For other object types, this isthe x-y coordinates (in pixels) for theobject’s position on the JDE Workspace.

However, the position property does notapply to service objects.

— -2147483648

x

0

Because the parent(ServiceContainer)object has noWorkspace, the positionproperty for any servicehas no real application.

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the object is assigned. A user musthave the appropriate privileges in at leastone security group to view and modifyproperties and issue commands.

Refer to the “Security Tab” section onpage 1-20 (Station object UserAdmin topic)

for more details on how securityGroupssettings apply.


•General

•HVAC

•Security

•Life Safety

•Group 4

•Group 5

•Group 6

•Group 7

General Also refer to the “AboutSecurity” section onpage 1-21.





Chapter 4 Services

AuditLogService

4–6

AuditLogServiceQuick reference for all properties: Table A-7

abbrev: (none); AuditLogService

The AuditLogService keeps a record of

configuration and operator changes to thestation database. All changes are logged,

even “position” changes for objects. The log

for each change includes a timestamp, user

name (of the “changer,”) swid of the source,

and a description of the change action.

The default view for the AuditLogService is

its LogTable, which lists the most recent

changes (stored in the object’s buffer). As

with other logs, the LogService provides

archive support for the accumlated log data.

This allows the station’s audit logs to be periodically archived to an application (SQL)

database in the supervisor station.

Parent Dependencies: ServiceContainer

Only one AuditLogService per station.

Resource Count Range: 38 to 1043, depending on the bufferSize (138 if default bufferSize of 100).

Trigger Properties The AuditLogService has two available trigger-type inputs:

• doArchiveTrigger —A received pulse causes the log data currently held in the

object’s log buffer to be archived (sent to the LogService archive destination).

• doClearTrigger —A received pulse causes all log data currently held in theobject’s log buffer to be cleared.

In addition, there are 2 available trigger-type outputs, described as follows:

• recordedTrigger —Fires upon each recorded change (log).

• archivedTrigger —Fires each time the object’s log buffer is archived.

Note Although this service object has no Workspace shape in the JDE, you can still link

to its trigger properties listed above, if needed. Use the Tree View and the right-click

“Link From” or “Link To” menu commands.

CommandsUsers with “Command, Admin” privileges have the following available commands:

• clear —Clears all log data currently held in the object’s log buffer.

• archive —Archives all log data currently held in the object’s log buffer.

• clearLastArchive —Resets the status property lastArchiveTimestamp from a

valid timestamp value to a “null” value. A subsequent archive will add all log

records to its archive (duplicate and out-of-sequence records are possible).

Inputs

Object Shape

Outputs

doArchiveTrigger

doClearTrigger

recordedTrigger

archivedTrigger

Input / Output Property Reference for AuditLogService Object(only input and output types, see Table 4-2 for all properties)


input — doArchiveTrigger TriggerType

input — doClearTrigger TriggerType

output — recordedTrigger TriggerType

output — archivedTrigger TriggerType

(none)





Chapter 4 Services

AuditLogService

4–7

Properties

AuditLogService NotesEach log record created by the AuditLogService has the following fields:

• tstamp —Timestamp of the recorded change, for example,

“10:05:20 4-Sep-2001 EDT.”

• userName —Station user that affected the change, for example, “admin.”

• source —Swid of the changed object, for example,

“/demoR2/Services/Notification.”

• auditAction —Description of the database change (with new value), for

example, “Property changed: "debug" = "true".”

Table 4-2 AuditLogService proper ties.


S t a t u s

objectType,

statusFlags,description

See Table 4-1 on page 4-5 for information on

these properties common to all service objects.

— — description default

Logs records ofuser modifications.

lastArchiveTimestamp Read Only: Shows a date/timestamp for whenthe last archive occurred. Shows “null” if therehave been no archives or if theclearLastArchive command was given.

validtimestamp

or null

null

C o n

f i g

bufferSize Read-Write: Defines the number of loggedchanges that can reside locally (in RAM).

An allocation of “resource counts” (RAM) is setaside based upon the entered number.

1 to 1000 100

stopWhenFull Read-Write: If set to True, logging stops whenthe number of logged changes equals theconfigured bufferSize. If set to False (the

default), the log buffer rotates—this means thatthe oldest recorded change is overwritten aseach new change continues to be recorded.

False, True False

archiveSetup Read-Write: Defines the events that cause theobject’s log data to be archived. Flags can beset in any combination.

• nearFull —Archive occurs at 80% of the logbuffer size.

• daily —Archive occurs daily, at the timeconfigured in the LogService.

• polled —Applies only if another (remote)Niagara station is configured with the PolledArchive (multisite) service.

selection ofany or all:

nearFull,daily,polled

daily

V i s u a

l

position Read-Write: See “position,” page 4-5. — -2147483648x 0

S e c u r i t y securityGroups Read-Write: Shows the security groups to

which the object is assigned. For more details,see “securityGroups,” page 4-5

General,

7 others

General





Chapter 4 Services

BackupService

4–8

BackupServiceQuick reference for all properties: Table A-8

abbrev: (none); BackupService

The BackupService1 “zips up” a station’s

entire directory into a WinZip-compatiblefile. It is recommended for a Web Supervisor,

or any JACE-NP with the DatabaseService. It

is not intended for a JACE-4/5.

During a backup, station operation continues

normally, and the station’s connection with

its application (SQL) database remains

coordinated. Configuration allows for a daily

zip file to be created at an assigned time.

Backup zip files are placed in a

<niagaraRelease>\backups\<stationName>

directory. Two backups are stored: the last

(backup.zip) and previous (backupOld.zip).

Typically, you should c o p y t h e b a c k u p .z ip

file t o r em o va b l e me d i a o n a d a i l y b a s i s .


Only one BackupService per station.



Commands Users with “Command, Admin” privileges have the following available commands:

• ForceBackup —Performs an immediate zip of the entire station’s folder into a

file named backup.zip. The previous backup.zip file is renamed

backupOld.zip. The previous backupOld.zip file is overwritten.

• CancelBackup —Useful only if the station’s DatabaseService databaseType is

not Cloudscape (MSDE or MS SQL Server). Allows user breakout if a backup

is taking an excessive amount of time due to ongoing archive traffic.

Properties

1. Requires Niagara release 2.2 or higher.

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for BackupService Object(only input and output types, see Table 4-3 for all properties)


input — — —

output — — —

(none)

Table 4-3 BackupService proper ties.


S t a t u s

objectType,statusFlags,description

See Table 4-1 on page 4-5 for information onthese properties common to all serviceobjects.

— — description default:

Backup Support.

lastBackupTime Read Only: Shows a date/timestamp forwhen the last backup zip file was created.Shows “null” if there have been no backups.

— null





Chapter 4 Services

BackupService

4–9

BackupService NotesThe BackupService is strongly recommended for archiving Web Supervisor stations,

as opposed to performing a direct backup of the running station using another method(tape backup, copy to CD, etc.). It zips everything under the running station’s station

directory, including the entire “app” (application database) folder.

Note By default, the BackupService is added when using the New Station wizard and the

“Is this station going to be a server?” option is selected.

Backup zip files are placed in a <niagaraRelease>\backups\<stationName> directory,

as shown in Figure 4-2.

C o n

f i g

backupEnabled Read-Write: Toggles the ability to perform adaily backup as On (True) or Off (False).

False, True True If False, a manual“forceBackup”command still

works.scheduledBackupTime Read-Write: Specifies the time of day, in

24-hour format, for the BackupService tocreate the backup.zip file for this station.

00:00to

23:59

00:00

(midnight)

V i s u a

lposition Read-Write: See “position,” page 4-5. — -2147483648

x 0


which the object is assigned. For moredetails, see “securityGroups,” page 4-5

General,

7 others

General

Table 4-3 BackupService propert ies. (continued)


Figure 4-2 The “ backups” directory is created under the Niagara <release> directory.

Two backups are stored: thelast (backup.zip) andprevious (backupOld.zip).

Typically at a job, thebackup.zip file is copied toremovable media on a dailybasis.

If a failure scenario requiresa restore, the most recentbackup.zip file can beunzipped back to theNiagara host.

Note: To restore, unzip the

backup.zip to the root of theNiagara release directory,with the “Use Folder Names”option selected.





Chapter 4 Services

ControlEngineService

4–10

ControlEngineServiceQuick reference for all properties: Table A-19

abbrev: (none); ControlEngineService

The ControlEngineService is the main

service run by a Niagara station. This serviceexecutes most objects in a Niagara station,

including standard control objects, apps

objects, and executable container objects.

Each object executed by this service has

configurable execution parameters,

including “frequency” for a continuously

cycling-type execution (normal, slower,

faster, or fastest). The target cycle time for

each frequency group is a configuration

property of the ControlEngineService.

Numerous status properties provide statistics,including the station’s object counts (by

assigned frequency group) and associated

execution times. A “profileNodes” feature

can be used to make all executed objects

locally store their minimum, maximum, and

average execution times.


Only one ControlEngineService per station.



CommandsUsers with “Command, Std” privileges have the following available command:

• resetStatistics —Clears (zeroes) accumulated statistics for each of the four

execution frequency groups, found on the Status tab of the property sheet. This

includes execution cycle counts, overruns, average execution times. Also

cleared are the accumulated lateStarts.

Properties

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for ControlEngineService

Object(only input and output types, see Table 4-4 for all properties)


input — — —

output — — —

(none)

Table 4-4 ControlEngineService propert ies.


S t a t u s




Execution enginefor control objects.

startTime Read Only: Shows the time of the last stationstartup. Status statistics accumulate from thispoint (until a resetStatistics is given).

— — format is:hh:mm dd-mo-yyyyTimeZone

http://-/?-

http://-/?-





Chapter 4 Services


4–11

S t a t u s ,

c o n

t .

totalObjectCount Read Only: The total number of objectsexecuted by the ControlEngineService. Thisequals the sum of all objects grouped by

execution frequency (fastest, normal, etc.).

— — Equals the totalnumber of objects inthe station, minus

Gx objects andsimple containertypes.

fastestObjectCount,fasterObjectCount,normalObjectCount,slowerObjectCount,onTriggerObjectCount,minutelyObjectCount

Read Only: Shows the number of objects ineach execution frequency group, includingthe continuous-types (fastest, faster, normal,slower) and others (onTrigger, minutely).

(each)

integer,0 to

— minutely typesinclude all Calendarand Scheduleobjects.

fastestCycles,fasterCycles,normalCycles,slowerCycles,minutelyCycles

Read Only: The accumulated number ofexecution cycles for each frequency grouplisted. The “minutelyCycles” value equals thenumber of minutes of operation that thestatistics are based upon.

(each)

integer,1 to

— Statistics globallyupdate every 10seconds.

totalOverruns Read Only: The total number of overrunscounted, across all four of thecontinuous-type frequency groups.

Equal to the sum of the next four overrunproperties (fastest, faster, normal, slower).

integer,0 to

—

fastestOverruns,fasterOverruns,normalOverruns,slowerOverruns

Read Only: The overruns counted for eachindividual execution frequency group.

An overrun is counted when the actual cycletime for a group exceeds its target executiontime, as defined by executionFrequenciesproperty settings (on the Config tab).

integer,0 to

—

fastestAverageExecuteTime,

fasterAverageExecuteTime,

normalAverageExecuteTime,

slowerAverageExecuteTime,

minutelyAverageExecute

Time

Read Only: For each repeating-typeexecution group, shows the averageexecution time (in milliseconds) for onecomplete object cycle.

floating pointvalue

— If profileNodes isenabled (for a shortperiod only), eachobject accumulatesits individual average executiontime. The sum ofthese times, perfrequency group,equals the values inthese properties.

lateStarts Read Only: The number of object executioncycles that started later than “anticipated,”(after the next cycle should have begun).

LateStarts occur as a result of other

asynchronous events that require processortime. Examples are performing a databasebackup, or the periodic “garbage collection”performed by the JVM.

integer,0 to

—

Table 4-4 ControlEngineService properties. (continued)






Chapter 4 Services


4–12

ControlEngineService NotesThe ControlEngineService executes all executable objects in the station except for

Gx objects (executed by the UIEngineService). Within the Java virtual machineexecution of a station, processor time is typically dedicated with the running of these

two services, plus whatever ongoing device integration (polling) services exist.

Notes on the ControlEngineService are in the following subsections:

• Object Execution

• Scheduling Execution

Object Execution When an object is executed by the ControlEngineService, usually there are three

phases of processing:

1. Read inputs1 —Values are “pulled” from outputs linked to inputs.

2. Calculation —The object’s algorithm, using its configuration properties.

3. Write outputs1 —Values are updated at outputs.

All three phases occur within the object’s execution time.

C o n

f i g

executionFrequencies Read-Write: Target execution cycle times foreach frequency group.

Default values for each group are:

• fastest: 500 ms

• faster: 1 seconds

• normal: 2 seconds

• slower: 5 seconds

Rules for values:fastest <= faster <= normal <= slower

100msto

999 seconds

(See Rules)

100ms stepsup to 2

seconds,thereafter 1

second steps

Seedescrip.

Cycle times set tooshort are reflectedby numerous

overruns. For anygroup, if the numberof overruns stays“lock step” with thenumber of cycles,the cycle time is setmuch too short.

profileNodes Read-Write: If True, causes all objectsexecuted by the ControlEngineService tolocally maintain their own execution statisticsin properties minExecuteTime,maxExecuteTime, and avgExecuteTime(found on the Engineering tab of each

object’s property sheet).

False, True False Do not leave at Truefor extendedperiods (usesstation resources).

displayDots Read-Write: If True, causes a period (dot)written to Standard Output after eachcompletion of the object execution cycle.

False, True False

V i s u a


x 0



General,

7 others

General

Table 4-4 ControlEngineService properties. (continued)


1. For shadow (integration) objects, outputs are written directly from the Poll service runningfor each particular integration.





Chapter 4 Services


4–13

Note The third phase (write outputs) is skipped whenever the difference between the

object’s calculated value and its last written value is less than the object’s configured

“covIncrement” value (assuming the object is so configured).

Station-wide, you can use this efficiency by assigning objects with a “covIncrement” property to a non-default (not 0.0) value. This results in fewer property changes

propagated to objects linked “downstream,” thereby reducing total system load.

For example, AnalogInput objects assigned a covIncrement of “0.1” (if suitable)

typically improve station efficiency. Other object types with covIncrement include

the AnalogOutput, Loop, Math, and the various Ndio UI objects.

An object’s behavior is usually determined by its object type and the settings of its

configuration properties. In the case of a Program object, behavior is defined by its

TRIPL program.

SchedulingExecution

The control engine thread of the station periodically walks a list of objects and

executes them in a sequential fashion. The scheduling of execution is determined by

the executionParameters property of individual objects, which has two parts:

• freq —Frequency. Most types of objects provide the following selections:

– never

– slower

– normal (the default)

– faster

– fastest

– minutely– on_trigger

For more information, see “Execution Frequency.”

• order —The following selections are available for all objects:

– input

– processor

– output

For more information, see “Execution Order.”

Execution Frequency

By default, most objects are executed in a continuously repeating fashion, and are

assigned by default to the “normal” execution frequency group. You can assign them

to one of the other three frequency groups for continuously executing objects, namely

“slower,” “faster,” and “fastest.” Target cycle times for the four execution frequency

groups are on the Config tab of the ControlEngineService property sheet.

Calendar and Schedule object types are special cases that execute only once a minute,

(at the “top” of the minute). If desired, you can assign other executable objects to

execute only at the top of the minute, by assigning the freq parameter to “minutely.”





Chapter 4 Services


4–14

In addition, many objects can be configured to execute only upon receiving a trigger

pulse, using the common input “executeTrigger.” In this case, both of these

conditions must be met:

• The object’s executeTrigger input must be linked.

• The object’s executionParameters, freq property must be set to “on_trigger.”

Note Frequency selections are exclusive. You cannot, for example, configure an object to

execute both continuously (for example, “normal”) and also on trigger.

Tip Often, overall execution efficiency can be improved by assigning objects that

are not critical to the “slower” category, for example, objects with values that

are monitored for display purposes only. This allows more processor time for

“normal” objects, plus more time for various integration (polling) services.

Also, if a station includes many Gx objects, you can also improve overallstation efficiency by assigning the UiEngineService’s cycleTime to a higher

value (than the default 500ms). A value of 2000 (or higher) is typically

acceptable.

Execution Order

For continuously-executing objects, and within each frequency group, are three

distinct divisions of order :

• input —These objects are executed first. By default, most are “input” type

objects, for example, AI, BI, and MSI.

• processor —These objects are executed next. Most are “software” typeobjects, such as Math, Loop, Logic, log types, and Program objects, to name a

few. By default, most object types are in this category.

• output —These objects are executed last. By default, most are “output” type

objects, for example, AO, BO, and MSO.

Typically, default execution order settings are recommended for most objects. This

allows the most efficient control response for the execution of control logic.





Chapter 4 Services

DatabaseService

4–15

DatabaseServiceQuick reference for all properties: Table A-24

abbrev: (none); DatabaseService

The DatabaseService provides an RDBMS

(relational database management system) forarchiving log object data, plus events such as

alarms and alerts. Referred to as an

application database (or appdb) it is separate

from the station’s configuration database.

The default appdb is an embedded,

Java-based, SQL-type by Cloudscape.

The DatabaseService is required for a Web

Supervisor. It is optional for a JACE-NP or

NX, and is not supported on a JACE-4/5.

The service provides Web browser access to

the application database, including an indexto all archives, plus an SQL query form.

Output from SQL queries can be directed to

different MIME type outputs, including text

in plain, HTML, XML, tab-separated, and

comma-separated formats.

A DatabaseBrowser view is also provided in

the JDE, as the object’s default view. This

provides access to summary, data, and SQL

query commands from within the JDE.


Only one DatabaseService per station.



CommandsIf a Cloudscape appdb, users with “Command, Admin” privileges have the following

available commands (these commands do not apply if MSDE or MS SQL appdb):

• Open —Opens a connection from the station to the application database.

Typically, this connection always remains open during station operation, so

that the station can populate the database and support the alarming subsystem. Note a connection is automatically opened upon any station restart.

• Close —Closes the connection from the station to the application database.

Note Do not close the database connection unless you have a specific reason.

While closed, station data that would otherwise be archived will be lost, and

the Niagara alarming subsystem will not function.

Note: Starting with Niagara 2.301.321.v1, additional (and optional)support for Microsoft MSDE or MS SQL databases was introduced, asan alternative to the standard Cloudscape SQL database.Configuration properties relating to these options are not explainedhere, but are covered in another document, MSDE or SQL Server 2000

Database Installation and Configuration Instructions.

Inputs

Object Shape

Outputs

(none) (none)

Input / Outpu t Property Reference for DatabaseService Object(only input and output types, see Table 4-5 for all properties)


input — — —

output — — —

(none)

http://-/?-

http://-/?-





Chapter 4 Services

DatabaseService

4–16

PropertiesTable 4-5 DatabaseService propert ies.


G e n e r a

l

S t a t u s

objectType,


See Table 4-1 on page 4-5 for information

on these properties common to all serviceobjects.


Relationaldatabasemanagement.

isConnected Read Only: Shows whether a connectionexists between the station and database.

False, True True

databaseProductName Read Only: Product name and vendor. DBMS:<type>

Validvalue

databaseProductVersion Read Only: Database product version. (valid versionnumber)

3.5.11(example)

driverName Read Only: Name for the embeddeddatabase driver, such as “CloudscapeEmbedded JDBC Driver.”

(valid name) seeDescrip.

driverVersion Read Only: Database driver version. (valid versionnumber)

3.5(example)

C o n

f i g

urlPrefix Read Only: String used within URLs forbrowser access to the application database.

For example:http:/<host>/<urlPrefix>/index.html

appdb appdb

databaseType Read-Write: Specifies the SQL databasetype for the appdb, with following choices:

• Cloudscape

• MSDE

• MS_SQL_Server

• Oracle (currently not supported)

Note: If Cloudscape, see “Memory UsageNotes,” page 4-26.

(see descrip). Cloud-scape

Cloudscape is thestandard SQLdatabase type.MSDE orMS_SQL_Serverare speciallylicensed options.

orderByTimestampDescending

Read-Write: Specifies how data records inan archive are ordered in table views, either:

• Most recent data first (at top of table),orderByTimestampDescending= True

• Oldest data first (at top of table)orderByTimestampDescending= False

False, True True

V i s u a

l position Read-Write: See “position,” page 4-5. — -214748364

8

x 0

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the object is assigned. For more

details, see “securityGroups,” page 4-5.

Note: In r2.3.4 and later, any browser userrunning a query (“Using the SQL QueryForm,” page 4-21) must have Admin Writeprivileges to issue any SQL commandbesides “Select”. Previously, any stationuser could issue any SQL command.

General,

7 others

General Any JDE userrequires Admin

Write privileges toaccess theDatabaseBrowser view. Command,Admin privilegesare required toissue commands“Open” and“Close”.





Chapter 4 Services

DatabaseService

4–17

DatabaseService NotesThe following main topics are covered in this notes section:

• DatabaseBrowser

• Database Tables

• Archive Data Format

• Accessing Archives

• SQL Queries

• DatabaseBrowser vs. Web Browser

• Summary Information and Useful URLs

• Memory Usage Notes

C l o u

d s c a

p e

C o n

f i g

jdbcDriverClassName Read-Write: Name for ODBC databasedriver (COM.cloudscape.core.JDBCDriver).

see Descrip. seeDescrip.

Do not changedefault jdbcproperty settings. jdbcConnectionUrl Read-Write: ODBC database used, with

format <jdbc>:<odbc>:<databasename>.Default is:

jdbc:cloudscape:app;create=true;upgrade=true

see Descrip. see

Descrip.

databaseUser Read-Write: Not implemented. — — —

databasePassword Read-Write: Not implemented. — — —

M S S Q L S e r v e r

C

o n

f i g

msJdbcDriverClassName

Read-Write: MS SQL database driver namecom.microsoft.jdbc.sqlserver.SQLServerDriver

see Notes seeDescrip.

For configurationdetails for thisappdb option,please refer to thedocument:

MSDE or SQL

Server 2000

Database

Installation and

Configuration

Instructions.

msJdbcConnectionUrl Read-Write: Connection url to MSDE or MSSQL database. Default value is:

jdbc:microsoft:sqlserver://localhost:1433;Select

Method=cursor


msDatabaseUser Read-Write: Typically default “sa”. see Notes sa

msDatabasePassword Read-Write: Password for databaseUser. see Notes —

msCreateNewDatabase Read-Write: See Notes. False, True True

msDatabaseDataFilename

Read-Write: See Notes. see Notes —

msDatabaseLogFilename

Read-Write: See Notes. see Notes —

O r

a c

l e ( f u t u r e u s a g e

)

C o n

f i g

orJdbcDriverClassName Read-Write: Name for Oracle databasedriver (oracle.jdbc.driver.OracleDriver).


Oracle appdbconfiguration notsupported in initialNiagara 2.3.5Release.

orJdbcConnectionUrl Read-Write: Connection URL to Oracledatabase. Default value is:<jdbc>:oracle:thin:@<localhost>1521:ORCL


orDatabaseUser Read-Write: See Notes. — tridium

orDatabasePassword Read-Write: See Notes. — niagara

Table 4-5 DatabaseService properties. (continued)






Chapter 4 Services

DatabaseService

4–18

DatabaseBrowser The default view for the DatabaseService in the JDE is the DatabaseBrowser, which

provides a two-sided window into the application database (Figure 4-3).

Figure 4-3 DatabaseBrowser is the default view for the DatabaseService.

Database Tables In a relational database, data resides in multiple tables. In the Niagara appdb, most

tables correspond one-to-one with individual log objects (that have archived).

Note Database “schemas” (and therefore table names) differ between Cloudscape and

MSDE/MS SQL appdbs. All examples shown here (and in later sections) are

Cloudscape-specific. However, all of the operations and sample queries also apply

to an MSDE or MS SQL appdb, providing you use the appropriate table names.

By default, tables (archives) are listed alphabetically from top-to-bottom, and are

named using the format:

<SCHEMA>.<TABLE>

where all characters appear capitalized .

Most tables are schema type ARCHIVE, using the format:

ARCHIVE.<STATION>_<LOG_OBJECT_SWID>

where an underscore (_) replaces the slash (/) used in normal swid syntax.

For example:

ARCHIVE.DEMOR2_SIM_LOGICSCREENS_AIRHANDLER_AH1CLG

For the log object “ah1Clg” in station “demoR2,” at swid:/demoR2/Sim/LogicScreens/AirHandler/ah1Clg

Notes • If an object name includes an underscore, it appears as two underscores inside

the table name. For example:

ARCHIVE.MY__STATION_LOGS_VAV__LOGS_ROOM__101

for swid: /My_Station/Logs/VAV_Logs/Room_101

• In addition to ARCHIVE, other schema types are ALERT, EVENT, and APP.

Right sideprovides threetabs for theselecteddatabase table.

Left side liststhe tables inthe database,available forselection.

Double-click toopen theDatabaseBrowser.





Chapter 4 Services

DatabaseService

4–19

Archive DataFormat

Within any table, archived data appears in table rows; each record is a separate row.

Typically, each record begins with a unique timestamp (first column), followed by

one or more other fields (columns) with values and status.

Note Starting in r2.3.4, the default order for archive records are “most recent data first.” Ifneeded, you can reverse this display order (from top-to-bottom) such that oldest data

is first (top). To do this, set the config property orderByTimestampDescending to

False —this duplicates the previous sort method used in older Niagara releases.

For archives of log types AnalogLog, BinaryLog, IntegerLog, and MultistateLog,

there are three fields (columns) total:

• TSTAMP —(Timestamp), formatted HH: MM: SS DD- MMM- YYYY TMZ

using 24-hour time. For example, 17: 00: 03 10- Sep- 2001 EDT.

• VALUE — Without engineering units (if analog/integer), or state descriptor if

binary/multistate (only “true” or “false” if binary, integer value if multistate).

For example: 71. 3457 (analog), f al se (binary), 2 (integer or multistate).

• STATUS1 —The statusFlags value for the source object. Typically, this is

“ok,” meaning normal. However, other values are possible, either singly or

in combination. For example, i nAl arm or i nAl arm, unackedAl arm.

Standard Archives

Table 4-6 shows “standard” archives that are not associated with a particular data log

object. Typically, these are listed in any station running the DatabaseService.

Notes • The four tables sourced from the NotificationService (alerts and alarms) can

hold records from multiple remote stations—providing that each station’s

NotificationService is configured to archive_remote (and to the Supervisor

station entered in its addressBook).

• Normal user access to data in the tables ALERT.UNACKEDALERTS and

EVENT.UNACKEDALARMS is through the JDE’s Alarm Console, Vykon

Alarm Service client, or using the URL ht t p: / / <st at i on>/ al ar mwith a

browser connection.

1. Archives for StringLog objects have only the TSTAMP and VALUE fields.

Table 4-6 Standard archives, in addition to archived log objects.

Format as listed (SCHEMA.TABLE) Description Data Sourced From

ALERT.ALERTHISTORY Alert HistoryNotificationService (must be set to archive)

ALERT.UNACKEDALERTS Unacknowledged Alerts

ARCHIVE.<STATION>_AUDITLOGSERVICE Station audit log AuditLogService (must be set to archive)

ARCHIVE.<STATION>_ERRORLOGSERVICE Station error log ErrorLogService (must be set to archive)

EVENT.EVENTHISTORY Alarm HistoryNotificationService (must be set to archive)

EVENT.UNACKEDALARMS Unacknowledged Alarms





Chapter 4 Services

DatabaseService

4–20

Accessing Archives

Archived data can be viewed (a table at a time), using either the DatabaseBrowser

view in the JDE, or from a Web browser connection to the station.

• To select an archive in the DatabaseBrowser view in the JDE, merely click it.

To see the archived data, click the Data tab on the right side.

• To select an archive from a Web browser, open the index to the availablearchives using either URL:

http://<stationName or IP address> /appdb/index

(lists all schema-type tables, including ARCHIVE, ALERT, and EVENT)

or

http://<stationName or IP address> /archive/index

(shows only ARCHIVE (log) tables).

for example, ht t p: / / 192. 168. 1. 195/ appdb/ i ndex

Click on any table to see the archived data.

Notes • Due the size (width) constraints encountered in the DatabaseBrowser, using

the browser method typically provides better viewing of archives. This is

particularly true for certain logs, such as the audit and error logs, that contain

extended values in fields such as “AUDITACTION” or “STACKTRACE.”

• If an archive contains more records, only the first 25001 will be shown. A

message (in red) appears in the DatabaseBrowser or browser window saying:

“WARNING: More records available, only displaying first 2500 records.”

You can view more records in a browser only by appending this string at the

end of the URL: &limit=n (where n is some number larger than 2500) and

then refreshing the browser.

SQL Queries The application database supports standard SQL queries, using either the

DatabaseBrowser (JDE) or a Web browser connection. Query results are identical

whether run from the DatabaseBrowser or a Web browser.

The following subsections apply to SQL queries.

• Running a Query

• Using the SQL Query Form

• Query Output Types

• Example SQL Queries

Running a Query

SQL queries can be run from a Web browser by typing in a specific URL directly,

using the following basic syntax:

htt p: / / <host I P>/ appdb/ query?sql =<query>&content - t ype=<mi meType>

1. Niagara r2.2 and later limit is 2500 records. In previous releases, the limit is 1000 records.





Chapter 4 Services

DatabaseService

4–21

Where standard MIME types are “text/plain”, “text/comma-separated-values”,

“text/tab-separated-values”, “text/xml”, and “text/html”. If content-type is not

specified, the default is “text/html.”

Additional parameters can be appended to this basic URL query, using the syntax:

&l i mi t =<si ze>&af t er =<yyyy- mm- dd>T<hh: mm: ss>&bef or e=<yyyy- mm- dd>T<hh: mm: ss>

where “limit” specifies the maximum number of records returned. If not specified,

the maximum limit is 2500 records.

For example, the following URL retrieves the first 20 archived records in the audit

log of station “demoR2,” and displays them in XML format:

htt p: / / 192. 168. 1. 100/ appdb/ query?sql =sel ect %20*%20f r om%20ARCHI VE. DEMOR2_SERVI CES_AUDI TLOG&cont ent - t ype=t ext / xml &l i mi t =20

Note Spaces are not permitted in URLs. Instead, the characters “%20” (without quotes)

must be used in a URL wherever a space would otherwise be used in a query.

Using the SQL Query Form

Using an SQL query form is much easier than typing in a URL—however, knowing

the SQL syntax needed is still the challenge. See Table 4-7 for some example queries.

Note SQL commands and syntax are beyond the scope of this document. See the SQL

Tutorial in the online Niagara Help system for a good introduction.

• JDE Access

• Browser Access

JDE Access—From the JDE’s DatabaseBrowser, use the following procedure:

Procedure 4-1 Running an SQL query from the DatabaseBrowser

Step 1 Click the Query tab on the right side.

Note The currently selected table (if any) makes no difference with a query.

Step 2 Type the query, using the SQL command, schema.table, and supporting SQL syntax.

A typical query uses this standard format:

select * from <table name> where <column name>='<string>'

example: select * from archive.demo_services_errorlog where severity='ERROR'

Step 3 Click Execute.

Query results appear in the window.





Chapter 4 Services

DatabaseService

4–22

Browser Access—From a Web browser, use the following procedure:

Procedure 4-2 Running an SQL query from a Web browser

Step 1 Access the SQL query form using the URL:

http://<stationName or IP address> /appdb/queryFormfor example, ht t p: / / 192. 168. 1. 195/ appdb/ queryFor m

Step 2 Type the query, using the SQL command, schema.table, and supporting SQL syntax.

A typical query uses this standard format:

select * from <table name> where <column name>='<string>'

example: select * from archive.demo_services_errorlog where severity='ERROR'

Step 3 Select the MIME type output (see “Query Output Types”).

Step 4 Click Execute.

Query results appear in the same browser window.

Note When using a browser connection, you can save query results by using the browser’s

File > Save As feature. Typically, this allows you to save a query as either an HTML

table or a text (.txt) file, or if you selected text/xml MIME output, in XML format.

Query Output Types

You can select any of the following MIME (Multipurpose Internet Mail Extensions)

types of output when running an SQL query. Each is listed below:

• text/html —Data is pre-formatted within an HTML table, using standardHTML tags. Included are column headers for each record field.

• text/plain —Data is formatted in plain text, one record per row, with each field

separated by a comma (,). Header (field name) information is not included.

• text/xml —Data is formatted using XML tags that reflect field (column)

headers, for example <TSTAMP> and </TSTAMP>. The XML output is

viewable in newer browsers. Header (field name) information is not included.

• text/tab-separated-values —Data is formatted in plain text, one record per

row, with each field separated by a tab. Header (field name) information is not

included.

• text/comma-separated-values —Data is formatted in plain text, one record

per row, with each field separated by a comma (,). Header (field name)information is not included. (Output is identical to the “text/plain” selection.)

• application/x-tridium-datax —Data is encapsulated in a binary file for use in

another application. This output selection is directed to a saved file only (not

viewable in the DatabaseBrowser or a Web browser window).





Chapter 4 Services

DatabaseService

4–23

Notes • There is no output difference between “text/comma-separated-values” and

“text/plain” selections.

• When using the DatabaseBrowser and the “Save Results” command, the

following file extensions (by default) are assigned to the different MIME types: – text/html .html

– text/plain .cvs

– text/xml .xml

– text/tab-separated-values .tvs

– text/comma-separated-values .cvs

– application/x-tridium/datax .dx

• You can save comma- and tab-separated output selections and import them into

spreadsheet programs that accept delimited data, and manipulate as needed.

Example SQL Queries

Table 4-7 shows some example SQL queries, referencing the “demoR2” station.

Note that queries are in lowercase—only strings in quotes (’ ') are case sensitive.

Typically, queries similar to these (after being successfully run) have the URLs saved

to a file. Then, the URL text can be used in URL link references in whatever HTML

navigation is provided to the system owner.

Table 4-7 SQL query examples with descript ions.

Query Entry Example What It Does Command, Selections,

Operators

select * from archive.demoR2_services_auditlog wheresource not like 'Position'

Lists all fields (*) for all audit logrecords, except those related torepositioning objects.

command select

selection source

condition not like

select username,tstamp,auditaction fromarchive.demoR2_services_auditlog whereusername=’admin'

Lists only the fields specified (in thatparticular order), for all audit logrecords for user “admin.”

command select

selection username

operator =

select * from archive.demoR2_services_auditlog wheretstamp>'2001-09-12 00:00:00'

Lists all fields (*) for all audit log recordsthat have timestamps after midnight,September 12, 2001.

command select

selection tstamp

operator >

select * fromarchive.demoR2_sim_logicscreens_energymgmt_oaologwhere value='true'

Lists all fields (*) for records of theBinaryLog object OAOLog created by atransition to On (true).

command select

selection value

operator =

select * fromarchive.demoR2_sim_logicscreens_energymgmt_schlogwhere ((extract(month from tstamp))=(extract(month fromcurrent_date)-1) and (extract(day fromtstamp))>=(extract(day from current_date)) or(extract(month from tstamp))=(extract(month fromcurrent_date)) and (extract(day fromtstamp))<=(extract(day from current_date))) and(extract(year from tstamp))=(extract(year fromcurrent_date))

An advanced level query using acombination of functions and operators(thanks to author Gerard Huff).

Lists all fields (*) for all records in theselected archive (in this case,BinaryLog object SCHLog) for a “rollingmonth’s” worth of data.

In other words, lists all archivedrecords from today’s date in last month until today’s date.

command select

selection tstamp

operators =, AND, OR

Also uses functions:

extract

Note: This query works forall months except forretrieving December datain January.





Chapter 4 Services

DatabaseService

4–24

Timesaver To avoid typing a table name in a query, open a browser connection to the

database index ( ht t p: / / <host >/ appdb/ i ndex) and copy the table name to the

clipboard. Do this by dragging backwards (right-to-left) over the table’s

hyperlink, until it is completely highlighted. Then press CNTRL-C to copy. It can

now be pasted (CNTRL-V) inside your SQL query, as needed.

DatabaseBrowservs. Web Browser

For the most part, everything in the application database that can be accessed using

the JDE DatabaseBrowser can also be accessed using a Web browser connection

(including, as previously noted, with an improved width of view).

However, the following features are available only in the JDE’s DatabaseBrowser:

• List Filters

• Summary Information

List Filters: You can list tables filtered on schema type (ALERT, ARCHIVE,

EVENT) and/or table string (Figure 4-4). By default, both the schemaFilter and

tableFilter are “wild cards” (*).

For example, with schemaFilter left at “*” and tableFilter changed to *ahu*, when

you press ENTER the list of tables updates to include only archives with “AHU”

(note this is not case sensitive). On the other hand, in the browser-accessible list, all

tables are alphabetically listed using the URL ht t p: / / <st at i on>/ appdb/ i ndex.

delete from archive.demoR2_services_auditlog wheretstamp<'2001-01-01 00:00:00'

Deletes all audit log records withtimestamps for years prior to 2001.

Note: Be careful when using the deletecommand. There is no undo.

command delete

selection tstamp

operator <

delete from alert.unackedalerts wheretstamp>'1980-01-01 00:00:00'

Deletes all unacknowledged alerts(currently pending acknowledgment).

Note: This would be used only to “freeup” the alarm console before jobturnover. However, it does not write anacknowledgment timestamp to alertscollected in the alert history.

command delete

selection tstamp

operator >

drop tablearchive.demoR2_sim_logicscreens_energymgmt_oaolog

Deletes the entire table (archive) forthe named table, in this case, for the

AnalogLog object OAOLog.

Note: Be careful when using the droptable command. There is no undo.

command drop table

selection (none)

operator (none)

Table 4-7 SQL query examples with descriptions. (continued)

Query Entry Example What It Does Command, Selections,

Operators





Chapter 4 Services

DatabaseService

4–25

Figure 4-4 Example of using fil ters to l ist only audit logs for the various stations.

Summary Information: The Summary tab in the DatabaseBrowser provides SQL

table structure information for any selected table. Included are the following four

categories for each of the different fields (columns) in a table:

• name —The column’s name (header ), for example, TSTAMP or VALUE.

Often used in an SQL “select... where name” statement (case is insensitive).

• typeName —The SQL data type for the field, for example such as INT

(integer), VARCHAR (character string), or TIMESTAMP.

• size —Data field size, as an integer. Boolean data (true or false) has a size of 1.

• isNullable —(YES or NO) Specifies whether data in the field can be null, that

is, the column can be empty. Typically, this is YES.

Summary information may be useful when someone with extensive SQL knowledge

is examining the application database.

SummaryInformation andUseful URLs

The DatabaseService provides an embedded RDBMS plus browser-accessible

mechanisms for accessing archived data. The following URLs provide universal

browser access to the service’s application database:

• ht t p: / / <host>/ appdb/index

Index listing all tables in the application database; each is a hyperlink to data.

• ht t p: / / <host>/ archive/index

Index listing only archive (log) tables in the application database; each is a

hyperlink to data.

• ht t p: / / <host>/ appdb/queryForm

HTML form for entering an SQL query, with selectable output options.The URL for any customized query can be saved and incorporated in an HTML

link for an end user, if desired.

Note Be aware that any browser connection requires entry of a valid user name for

the station, however, no specific security rights are required.

The schemaFilter and tableFilter fields canbe used to limit which tables appear listed.





Chapter 4 Services

DatabaseService

4–26

The station requires an open connection with the application database to support

normal operation, which includes support for Niagara alarming and archiving of log

data. By default, this connection is opened when the station starts, and remains open

(unless manually closed by a user with “Command, Admin” rights).

Archived data is stored in tables, where the vast majority of tables correspond

one-to-one to log objects that are configured to archive. Such a table does not existin the database until the log object has actually archived.

In addition to log (object) archives, standard archives associated with the

NotificationService, AuditLogService, and ErrorLogService typically exist.

Memory UsageNotes

For some Web Supervisors using the default Cloudscape appdb, (databaseType is

Cloudscape), data archiving has been noted to markedly increase memory usage of

the host PC. In a few cases, the Web Supervisor’s performance became

sluggish—this was found be related to “garbage collection” issues.

Starting in r2.3.5, these issues were resolved as a result of the JVM change to Sun

Hotspot (vs. the previous Microsoft VM). A Web Supervisor running r2.3.5 or latershould not experience this problem.

If a Web Supervisor is running an earlier ( pre-r2.3.5) Niagara release, for example

r2.3.4 or r2.3.3, it is recommended that you “uncomment” (remove leading “#”) from

this line in the host’s system.properties file:

gc.daemon=600000

This forces a periodic garbage collection by the JVM every 600,000 ms (10 minutes).

Caution If running r2.3.5 or later, you should disable the garbage collection entry described

above in the Web Supervisor’s nr e\ l i b\ syst em. pr oper t i es file, to prevent

needless periodic garbage collection.

To do this, add a comment (“#”) in front of this line, such as:

#gc.daemon=600000

For additional information about this and other Niagara properties files, refer to “List

of Niagara Properties Files,” page 1-31.





Chapter 4 Services

ErrorLogService

4–27

ErrorLogServiceQuick reference for all properties: Table A-26

abbrev: (none); ErrorLogService

The ErrorLogService keeps a record of

software errors which are caused by invalidconfigurations and software bugs. Different

priority levels are logged, ranging from

MESSAGE (informational) to WARNING

and ERROR (high). Each log record includes

a timestamp, source (swid), message, and

stackTrace pointer (if a warning or error).

The default view for the ErrorLogService is

its LogTable, which lists the most recent

errors (stored in the object’s buffer). As with

other logs, the LogService provides archive

support. This allows the station’s error logs to

be periodically archived to an application

(SQL) database, meaning the supervisor

station running the DatabaseService.


Only one ErrorLogService per station.

Resource Count Range: 38 to 1043, depending on the bufferSize (54 if default bufferSize of 25).

Trigger Properties The ErrorLogService has two available trigger-type inputs:



• doClearTrigger —A received pulse causes all log data currently held in the

object’s log buffer to be cleared.


• recordedTrigger —Fires upon each recorded error message (log).











Inputs

Object Shape

Outputs

doArchiveTrigger

doClearTrigger

recordedTrigger

archivedTrigger

Input / Output Property Reference for AuditLogService Object(only input and output types, see Table 4-8 for all properties)


input — doArchiveTrigger TriggerType

input — doClearTrigger TriggerType

output — recordedTrigger TriggerType

output — archivedTrigger TriggerType

(none)





Chapter 4 Services

ErrorLogService

4–28

Properties

ErrorLogService NotesEach log record created by the ErrorLogService has the following fields:

• tstamp —Timestamp of the recorded error or event, for example,

“10:05:20 4-Sep-2001 EDT.”

• severity —Can be one of the following:– MESSAGE (informational) Examples include a message identifying

station startup or a new service added.

– WARNING (low) An example is from a “Cannot send packet” message.

– ERROR (high) Examples include “Cannot send mail” or “Cannot load

Ethernet Packet Driver.”

Table 4-8 ErrorLogService proper ties.


S t a t u s

objectType,





Logs configurationand softwareerrors.

lastArchiveTimestamp Read Only: Shows a date/timestamp for whenthe last archive occurred. Shows “null” if therehave been no archives or if theclearLastArchive command was given.

validtimestamp

or null

null

C o n

f i g

bufferSize Read-Write: Defines the number of loggedchanges that can reside locally (in RAM).

An allocation of “resource counts” (RAM) is setaside based upon the entered number.

1 to 1000 25

stopWhenFull Read-Write: If set to True, logging stops whenthe number of logged changes equals the

configured bufferSize. If set to False (thedefault), the log buffer rotates—this means thatthe oldest recorded change is overwritten aseach new change continues to be recorded.

False, True False

archiveSetup Read-Write: Defines the events that cause theobject’s log data to be archived. Flags can beset in any combination.

• nearFull —Archive occurs at 80% of the logbuffer size.

• daily —Archive occurs daily, at the timeconfigured in the LogService.

• polled —Applies only if another (remote)Niagara station is configured with the Polled

Archive (multisite) service.


nearFull,daily,polled

daily

V i s u a


x 0



General,

7 others

General





Chapter 4 Services

ErrorLogService

4–29

• source —Swid of the object involved in the error or event (most typically a

service object). For example: “/demoR2/Services/MailService.”

• message —Description of the error or event, for example, “Cannot send mail”,

“Cannot send packet”, or “Station started successfully. (HTTP port=80).”

• stackTrace —Populated only if a WARNING or ERROR severity, this often

provides a “reason” for the error, and identifies (in some detail) the failed Java process. For example:

j avax. mai l . SendFai l edExcept i on: No r eci pi ent addr esses at j avax/ mai l / Transport . send0 ( Transpor t . j ava: 96) at j avax/ mai l / Transport . send ( Tr ansport . j ava: 71) att r i di um/ ser vi ces/ Mai l Ser vi ce. sendI mpl ( Mai l Ser vi ce. j ava: 230) att ri di um/ ser vi ces/ Mai l Ser vi ce





Chapter 4 Services

LogService

4–30

LogServiceQuick reference for all properties: Table A-42

abbrev: (none); LogService

The LogService provides archive

management for station logs (all log objects,the audit log and error log). The log archive

destination is configurable as remote or local,

depending on the location of the application

database (station with the DatabaseService).

A configurable archive time allows for a

daily periodic archive (for all logs so

configured). The service also has an

archive_disabled mode, in which case log

data is not archived.

In addition to archive management, the

LogService also provides Web browser

access to the log data of any log in the station.

The URL for a tabular index to all station logs

is ht t p: / / <host >/ l og/ i ndex. Output for a

selected log is text-based, and available in

several formats including plain, HTML,

XML, tab-separated, and comma-separated.


Only one LogService per station.


Trigger Properties The LogService has two available trigger-type inputs:• doArchiveAllTrigger —A received pulse is equivalent to the archiveAll

command, described below.

• doClearLastDailyArchiveTrigger —A received pulse is equivalent to the

clearLastDailyArchive command, described below.

Note You can link to trigger properties listed above, if needed. Use the Tree View and the

right-click “Link From” or “Link To” menu commands.


• archiveAll —Causes the log data currently held in every log object to be

immediately archived (sent to the LogService archive destination). Note this

applies even to logs that are not configured to archive (daily and/or near full)!

• clearLastDailyArchive —Resets the config property lastDailyArchive from a

valid timestamp value to a “null” value. In a subsequent daily archive, each log

object archives all log records accumulated since its lastArchiveTime.

Inputs

Object Shape

Outputs

doArchiveAllTrigger

doClearLastDailyArchiveTrigger

(none)

Input / Output Property Reference for LogService Object(only input and output types, see Table 4-9 for all properties)


input — doArchiveAllTrigger TriggerType

input — doClearLastDailyArchiveTrigger TriggerType

(none)





Chapter 4 Services

LogService

4–31

PropertiesTable 4-9 LogService proper ties.


S t a

t u s objectType,


SeeTable 4-1 on page 4-5 for information on



Provides logsupport.

C o n

f i g

logUrlPrefix Read Only: String used within URLs for browseraccess to log buffered data.For example:http:/<host>/log/index

log log

archiveUrlPrefix Read Only: String used within URLs for browseraccess to archived log data.For example:http:/<host>/archive/index

archive archive Applies only if thestation has theDatabaseService.

archiveMode Read-Write: Determines whether logs arearchived, and if so, where.

• A Web Supervisor station should always be

set to archive_local.• JACE controllers are typically set to

archive_remote (unless a JACE-NP with theDatabaseService).

archive_disabled

archive_local

archive_remote

Note: Changerequires astation restart.

archive_disabled

If archive_disabled,the LogService doesnot archive, nor is

“polled archiving”(from a pollingstation with thePollArchiveService)performed.

archiveAddress Read-Write: Specifies the station with theDatabaseService where logs are archived.Uses the station’s AddressBook setup.The property has two parts:

• Supervisor checkbox—Check i f archivingremotely to a station already defined as theSupervisor in the AddressBook.

• station drop-down list—Lists stationsavailable when archiving remotely. These

stations are defined as peers or subordinatesin the AddressBook. A “none” selection isalso included.

Supervisor,

none

archiveTime Read-Write: Specifies the archive time for alllogs configured to archive daily.

Uses a 24-hour format (Hr:Min) from 00:00(midnight) to 23:59 (11:59 PM).

00:00to

23:59

02:00

lastDailyArchive Read Only: Shows a date/timestamp for the lastdaily archive.

valid timestampor null (none)

null

minRetryTime Read-Write: Specifies the minimum time, inminutes, for the “retry window” following a failedarchive. A retry is made within this window.

1 to n 5(minutes)

Archives may faildue to connectionproblems to thearchive host. The

“retry window”scheme prevents“server floods” upona reconnection.

maxRetryTime Read-Write: Specifies the maximum time, inminutes, for the “retry window” following a failedarchive. A retry is made within this window.

1 ton

15(minutes)

V i s u a


x 0



General,

7 others

General





Chapter 4 Services

LogService

4–32

LogService Notes Notes on the LogService include the following four topics:

• About the LogService

• Log Servlet

• Troubleshooting Archive Activity

• Additional r2.3.5 Archive Debug Features

About theLogService

The LogService coordinates the archiving of buffered log data in the station to the

archive destination, whether local (station is running the DatabaseService) or remote

(as in a typical JACE controller).

The LogService uses a “push” mechanism that automatically opens a connection

with the application database and populates (or creates and populates) the necessary

archive tables with log data. This process occurs at these times:

• Daily (at the configured archiveTime), for all log objects set to archive daily.

• On an individual “near full” basis (80% of the configured bufferSize), for anylog object set to archive nearFull.

• Upon a manual “archive” command given to any log object.

• Upon receipt of a trigger pulse at the “archiveTrigger” input of any log object.

• Upon receipt of a trigger pulse at the “doArchiveAllTrigger” input of the

LogService object (causes an archive of all log objects set to archive).

If the archiveMode is set to archive_disabled, no log data is archived, but the

LogService still provides HTTP access to buffered log data.

Log Servlet The log servlet provides HTTP access to data currently residing in the buffers of the

station’s log objects. An index to all log objects in the station is provided by the URL:

http://<host>/log/index

Logs are listed by “description” property (if entered) or object name (if not). The

HTML index provides links to view each logs data in the following formats:

• text/html —Data is pre-formatted within an HTML table, using standard

HTML tags. Included are column headers for each record field.

• text/plain —Data is formatted in plain text, one record per row, with each field

separated by a comma (,). Header (field name) information is not included.

• text/xml —Data is formatted using XML tags that reflect field (column)

headers, for example <TSTAMP> and </TSTAMP>. The XML output is

viewable in newer browsers. Header (field name) information is not included.

• text/tab-separated-values —Data is formatted in plain text, one record per

row, with each field separated by a tab. Header (field name) information is not

included.

• text/comma-separated-values —Data is formatted in plain text, one record

per row, with each field separated by a comma (,). Header (field name)

information is not included. (Output is identical to the “text/plain” selection.)





Chapter 4 Services

LogService

4–33

• application/x-tridium-datax —Data is encapsulated in a binary file for use in

another application. This output selection is directed to a saved file only (not

viewable in a Web browser window).

Troubleshooting

Archive Activi ty

The log servlet also provides HTTP access to the “status” of the log archive activity

for a station, using the URL:

http://<host>/log/status

This provides a “snapshot” list of statistics for the LogService’s archive activity, plus

links to the Incoming Archives and Outgoing Archives pages (described ahead).

Statistics can be useful when troubleshooting log archive activity, and are as follows:

• archiveMode —of the LogService. (archive_remote or archive_local).

• currentTime —timestamp for the statistics (refresh browser to update all).

• lastSuccessTime —timestamp for when the last successful archive transaction

occurred. Shows “null” if archive active activity has not occurred since the last

station restart.

• successCount —number of successful archive transactions since stationstartup.

• lastFailureTime —timestamp of the last failed archive attempt. Typically, this

is when the archive host (destination) became unreachable. Shows “null” if no

failed archives since station startup.

• lastFailureReason —reason for the last failed archive. Typically, it is a

network connection problem. Alternately, the archive station may have been

stopped, or its DatabaseService closed.

• nextAttemptTime —timestamp for when a retry will occur for “backlogged”

archives.

• nextAttempPeriod —number of seconds after failed archive attempt before a

retry attempt is made. This number was randomly derived within a window

defined by the LogService’s configured “minRetryTime” and

“maxRetryTime” properties. (Does not change on refresh).

• backlogCount —number of logs currently awaiting a retry to archive.

Incoming Archives: The “incomingArchives” link at the bottom of the log/status

page applies if a Web Supervisor station, or JACE-NX/NP with DatabaseService. It

lists stations that have archived to this station, along with a timestamp of last archive

contact. Stations are hyperlinks to “incomingArchives?station=<sta>” screens.

Clicking on a station returns a list of archives for the selected station (as they exist in

the SQL database of the archive host). Each displays the archive’s swid, and shows

timestamps for the last “archive contact” and the last archive timestamp.

Outgoing Archives: The “outgoingArchives” link at the bottom of the log/status

page is useful for any station that is archiving logs (either locally or remotely). This

page lists any “backlogged” logs for archiving, showing a total number in the

“Archive Backlog [n]” at the top of the table. These are logs awaiting to be sent to

the station’s archive destination.





Chapter 4 Services

LogService

4–34

Each log is named by swid, with a timestamp for the last archive and a “Percent

Unarchived” number. Typically, these values range from 80% (the ”nearFull” archive

trigger point) and 100%, where 100% indicates possibility of lost (unarchived) data.

Lesser percentages may also appear.

The swid to each log is a hyperlink to the properties table for that log object.

Additional r2.3.5 Archive DebugFeatures

Starting in r2.3.5, any running station provides a central “debug servlet”, using URL:

http://<host>/debug

From this main debug page are several “General” links for use from a browser

connection, including a “Log Status” link described in the previous section

“Troubleshooting Archive Activity.”

In addition, the debug servlet provides a “stdout” (Standard Output) link that

provides a snapshot of that station’s Standard Output—something previously that

required an Admin Tool connection to a Niagara host.

In r2.3.5, you can also send archive “trace” messages to the station’s Standard Output

by setting a property in that host’s system.properties file, namely:

archive.trace=true

Trace messages from archiving appear similar to:

Archive> archive /J403_428/test/AlmTest/CountLog_2

Archive> success!

Archive> archive /J403_428/test/AlmTest/CountLog_3

Archive> success!

By default, trace archiving is disabled. In other words, if the archive.trace property is

not present in system.properties, it is evaluated the same as if:

archive.trace=false

Like most entries in system.properties, any change to this particular property

becomes immediately effective.





Chapter 4 Services

MailService

4–35

MailServiceQuick reference for all properties: Table A-46

abbrev: (none); MailService

The MailService provides the ability to send

e-mail notifications of Niagara alarms andalerts. The station’s NotificationService must

be configured with MailRecipient objects to

utilize this service. The MailService is

typically run on a Web Supervisor station, but

can also run on any JACE controller station.

The MailService operates as a send-only mail

client using the SMTP protocol and port 251.

Configuration properties specify the SMTP

server to be used, and the appropriate “from”

address. If required, username and password

properties are available to provide the

necessary authentication to the SMTP server

(see “Authentication Notes,” page 4-37).

In a scenario where e-mails cannot be sent

(SMTP server becomes unavailable, for

example), they are stored locally in a mail

outbox (outbox.mbx file). On a configurable

basis, the MailService periodically attempts

to resend pending e-mails in the outbox.




• deleteOutbox —Deletes all pending (previously failed) e-mail notifications

awaiting to be resent.

Properties

1. Starting in r2.301.429.v1 and later, you can specify another “non-default” port for the SMTP server.

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for MailService Object(only input and output types, see Table 4-10 for all properties)


input — — —

output — — —

(none)

Table 4-10 Mai lService propert ies.


S t a t u s


See Table 4-1 on page 4-5 for information onthese properties common to all service objects. — — description default:Service to store andsend email.

C o n

f i g enabled Read-Write: Must be True for operation of theMailService. If set to False, the MailServicedoes not route alarms/alerts.

False, True False





Chapter 4 Services

MailService

4–36

MailService NotesThe MailService is used by MailRecipient objects linked to NotificationClass objects

(both reside in the NotificationService container).

The following notes apply to the MailService:

• Outbox Notes

• Authentication Notes

• Localization Notes

C

o n

f i g ,

c o n

t .

smtpHost Read-Write: Specifies the SMTP host to use tosend e-mail notifications.

Starting in r2.301.429.v1 and later, you can also

specify a TCP port different than 25 (default):<hostname>:<port> for example:

ourMailSrv:40

Note:A station restart is required afterentering (changing) the SMTP host name.

valid hostnameof SMTP server(and optionally)

TCP port if not 25

- The SMTP host isread upon stationstartup.

If station is runningin a JACE-NX,review/adjust itssecurity policy asneeded if changingdefault port or usingDNS.

fromAddress Read-Write: Specifies the “from” address usedin sent e-mail notifications. An e-mail accounton the SMTP server is typically required usingthis same address.

Often, an e-mail account using the station’sname is created and used.

valid e-mailaddress

[email protected]

outboxRetryTime Read-Write: Specifies the wait time, in minutes,that must occur before an unsuccessful e-mailnotification is resent.

5(minutes)

username Read-Write: Username associated with thee-mail account used on the SMTP server.

May be left blank unless the SMTP serverrequires authentication on a send operation, inwhich case username must be entered.

See descrip. — An entry in theNiagara host’ssystem.properties file is also required.

See “AuthenticationNotes,” page 4-37password Read-Write: Password for the user named by

the username property.

May be left blank unless the SMTP serverrequires authentication on a send operation, inwhich case the password must be the correct

one used for the named user.

See descrip. —

E n g

i n e e r i n g debug Read-Write: When set to True, provides

detailed information in the station’s StandardOutput relating to the connection to (andcommunication messages with) the designatedSMTP server.

False, True False

V i s u a


x 0



General,

7 others

General

Table 4-10 MailService properties. (continued)






Chapter 4 Services

MailService

4–37

Outbox Notes The outbox of the MailService collects failed e-mail notifications (ones that were not

successfully sent). The service periodically attempts to resend the failed notifications

in the outbox, based upon a time specified in the outboxRetryTime property.

The outbox exists as a file residing under the station folder, using this file path:

niagara\<release>\stations\<stationName>\mail\outbox.mbxThe outbox.mbx file is automatically created (or appended to) by the MailService,

upon demand. An outbox.mbx file of 0 bytes indicates there are no failed (pending)

e-mail notifications—any other file size indicates pending e-mails exist. The contents

of the outbox.mbx is all failed e-mails, in plain text format.

The MailService command “deleteOutbox” deletes the outbox.mbx file. If necessary,

the service automatically creates a new outbox.mbx file.

Note (Setup) If the SMTP host is incorrectly identified in the smtpHost property,

notifications routed via MailRecipients are stored in the outbox (outbox.mbx file).

These e-mails will be successfully sent after the smtpHost property is correctlymodified, and the station is restarted . If you do not want them sent, issue the

“deleteOutbox” command to the MailService before restarting the station.

AuthenticationNotes

If the target SMTP mail server is configured to require authentication for send

requests, you must configure the service’s config properties username and password

with the appropriate entries. Contact the mail server’s system administrator for this

information.

In addition, the Niagara host’s system.properties file must have the following line

present:

mail.smtp.auth=true

For information on accessing Niagara properties files, refer to “Host > Edit File,”

page 1-28.

LocalizationNotes

In r2.3.5 and later, the MailService uses UTF-8 encoding (by default) to support the

sending of localized alarm messages. If necessary, this feature can be disabled so that

straight ASCII encoding is used instead. This might be necessary if e-mail clients

cannot handle UTF-8 encoding properly.

Do this by adding a line in the Niagara host’s system.properties file as follows:

mail.useUTF=false

If this line is missing or has a value of “true,” the default UTF-8 encoding is used.





Chapter 4 Services

NotificationService

4–38

NotificationServiceQuick reference for all properties: Table A-62

abbrev: (none); NotificationService

The NotificationService provides alarm and

event routing, processing of alarmacknowledgments, and management of alarm

archiving. It is a required service in any

Niagara station.

NotificationService properties define the

alarm archive destination (typically, the Web

Supervisor) and the archive mode (local,

remote, disabled, local no SQL). A debug

mode is available for troubleshooting.

The NotificationService object is unique

among service objects because it is a

container object. Child (notification) objectsdefine the station’s notification scheme, and

include the following types:

• NotificationClass

• ApiRecipient

• MailRecipient

• PrinterRecipient

• RemotePrinterRecipient

• SnmpRecipient


Only one NotificationService per station.

Resource Count Range: 51 to 61, plus the

sum of all resource counts of child objects.


Commands None.

Properties

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for NotificationService(only input and output types, see Table 4-11 for all properties)


input — — —

output — — —

(none)

Table 4-11 NotificationService properties.


S t a t u s objectType,


See Table 4-1 on page 4-5 for informationon these properties common to all serviceobjects.


Alarm delivery tosupervisor.





Chapter 4 Services

NotificationService

4–39

NotificationService NotesBy default, the NotificationService in a newly-created station contains a single child

NotificationClass object, with a notification class number of zero (0). Typically,

additional child objects are added and linked in the NotificationService workspace.

Note You can place NotificationClass objects and recipient objects in containers under the

NotificationService, and not just directly in the NotificationService.

For more details on the various notification child objects (classes and recipients), please refer to Chapter 9, “Notification Objects.”

C o n

f i g

alarmArchiveAddress Read-Write: Specifies the station with theDatabaseService (and alarm console)where alarms and alerts are archived. Uses

the station’s AddressBook setup.The property has two parts:

• Supervisor checkbox—Check if archivingremotely to a station already defined asthe Supervisor in the AddressBook.

• station drop-down list—Lists stationsavailable when archiving remotely. Thesestations are defined as peers orsubordinates in the AddressBook. A“none” selection is also included.

See descrip. Supervisor,

none

archiveMode Read-Write: Specifies how notification andassociated archiving occurs. The default“disable” selection prevents notificationfrom occuring.

The “archive_local” selection is valid only ifthe station is running the DatabaseService(typically, this is the Web Supervisor).

archive_disable

archive_local

archive_remote

archive_local_no _SQL

archive_disable

A station in a typicalJACE controllerrequires thearchive_remoteselection. The“local_no_SQL” isfor a standaloneJACE-4/5 only.

E n g


detailed information in the station’sStandard Output relating to routing andacknowledgment of alarms and events.

False, True False

V i s u a


x 0

S e

c u r i t y securityGroups Read-Write: Shows the security groups to

which the object is assigned. For more

details, see “securityGroups,” page 4-5

General,

7 others

General

Table 4-11 NotificationService properties. (continued)






Chapter 4 Services

PollArchiveService

4–40

PollArchiveServiceQuick reference for all properties: Table A-65

abbrev: (none); PollArchiveService

The PollArchiveService is an optional,

individually licensed service that can be usedon a station running the DatabaseService. It is

needed by a “Master Web Supervisor.” This

service is in the tridiumx/multisite JAR.

This service “pulls” log data from target

stations, where each station is assigned to a

particular poll archive group. This differs

from the standard “push” of log data that

occurs through each station’s LogService.

Log data is acquired from remote log objects

that have an archiveSetup that includes

“polled,” or , if the target station is running theDatabaseService, (e.g. Web Supervisor)

directly from that station’s SQL appdb.

Reasons for using the PollArchiveService

include the following scenarios:

• Firewalls prevent the normal

LogService “push” data approach.

• A “tiered” approach of archiving is

needed, with one or more Web

Supervisors and/or JACE-NP stations

with the DatabaseService.

For any poll archive group, log data is

archived based upon any occurrence of:

• A configurable, repeating timer

(every 1 to n hours).

• A trigger pulse received at the service’s

pollGroup N input.

• A manual pollGroup N command.


Only one PollArchiveService per station.


Trigger Properties The PollArchiveService has 8 available trigger-type inputs:

• pollGroup0Trigger through pollGroup7Trigger —A received pulse causes

the associated poll archive group to be polled for archive data. (You assign a

station to a poll archive group in the AddressBook of the polling station.) This

input can be linked to a Command, Schedule, DateTimeTrigger or other object.

Inputs

Object Shape

Outputs

pollGroup0Trigger

pollGroup1Trigger

pollGroup2Trigger

pollGroup3Trigger

pollGroup4Trigger

pollGroup5Trigger

pollGroup6Trigger

pollGroup7Trigger

(none)

Input / Output Property Reference for PollArchiveService Object(only input and output types, see Table 4-12 for all properties)


input — pollGroup0Trigger TriggerType




input — pollGroup4Trigger TriggerTypeinput — pollGroup5Trigger TriggerType



(none)





Chapter 4 Services

PollArchiveService

4–41





• pollGroup n (0—7) —Immediately requests a poll for archive data from poll

archive group n. Any commanded poll request is considered “high priority.”

– If poll archiving is currently not in progress, polling immediately begins

for that poll archive group.

– If a poll archive is in currently in progress, the request is added to the high

priority queue. If no other high priority requests are queued, polling begins

for that poll archive group next (after the current poll archive completes).

• clearLowPriorityQueue —Removes all group archive requests from low

priority queue (frequency-initiated group archives).

• clearHighPriorityQueue —Removes all group archive requests from high

priority queue (command-initiated group archives).

PropertiesTable 4-12 PollArchiveService properties.


S t a t u s


See Table 4-1 on page 4-5 for information onthese properties common to all service objects.


Service to supportmulti-site logcollection.

lowPriorityQueueSize

Read Only: Number of queued group archivesinitiated by regular frequency.

0 to n 0 Typically, each is 0or a low number. See“Priority Queues,” page 4-43.

highPriorityQueueSize

Read Only: Number of queued group archivesinitiated by “pollGroupn” commands.

0 to n 0

C o n

f i g

group0enabled,frequency

through

group7enabled,frequency

Read-Write: (Separately configurable for eachpoll archive group.) Specifies whether that pollarchive group is enabled for poll archiving, andif so, what regular, repeating frequency ofarchive should occur (in hourly increments).

• If False, poll archiving does not occur.

• If True but frequency is 0, poll archivingoccurs only upon a pollGroupTrigger pulse ora pollGroup command.

False, True

0 to n hours (integer)

False,

0

lowPriorityQueueCapacity

Read-Write: Specifies group archive queuemaximum size, for low priority (frequencyinitiated) group archives.

10 to 60 50 Values much overdefaults (50) shouldnot be necessary.

See “PriorityQueues,” page 4-43.

highPriorityQueueCapacity

Read-Write: Specifies group archive queuemaximum size, for high priority (commandinitiated) group archives.

10 to 60 50

V i s u a

lposition Read-Write: See “position,” page 4-5. — 10 x 10





Chapter 4 Services

PollArchiveService

4–42

PollArchiveService NotesThe PollArchiveService is required in the “Master Web Supervisor” station only, not

in any “polled” (target) station (Figure 4-5). Special configuration for each target

station is not needed, apart from its LogService being set to either archive_remote

(typical) or archive_local (if Web Supervisor or JACE-NP, NX with DatabaseService).

E n g


detailed information in the station’s StandardOutput relating to poll archive messages.

False, True False Leave debugdisabled exceptwhile

troubleshooting thePollArchiveService.



General,

7 others

General

Table 4-12 PollArchiveService properties. (continued)


Figure 4-5 Polled archive (Master Web Supervisor) configuration.

The PollArchiveServiceuses a “pull” approach.

The Master Web Supervisorhas the PollArchiveService,and is the “poller.”

All the JACE controllersand/or Web Supervisorsshown are entered in theMaster Web Supervisor’saddressBook, and areassigned to a particular pollarchive group (each may beassigned to the same group

or a unique group, asneeded).

Web Supervisors orJACE-NPs or NXs with theDatabaseService eachhave their own SQLapplication database(appdb). When thesestations are polled, newdata from its log archives is“pulled” to the Master WebSupervisor.

See the followingsubsections:

• Configuration

• Operation

Poller

Web Supervisor JACE-4/5Archive Remote

JACE-NP, NX w/ appdb

Archive Local

JACE-NP, NXArchive Remote

SQL database

SQL database

appdb

appdb

Polled Archiving (PollArchiveService) Pushed Archiving (LogService)

archiveAddress isundefined

All logs set to polled

archiveAddressis local

No logs set topolled

archiveAddress isJACE-NP

Some logs set topolled

PollArchiveService

archiveAddress isWeb Supervisor orother JACE-NP, NX

Some logs set topolled

JACE-4/5

Archive Remote

Normal archive of logs set toarchive nearFull and/or daily

Poll list generated fromin-memory object databaseof logs with polled flag set.

Poll list generated fromin-memory object databaseof logs with polled flag set.

Poll list generated from tables of archived

logs in Application Database (appdb)

Master

Web Supervisor or





Chapter 4 Services

PollArchiveService

4–43

Configuration Configuration for the PollArchiveService is done in the AddressBook of the Station

object for the Master Web Supervisor. Each target station must be identified and

assigned to a particular poll archive group (0 to 7). This is done using the Poll

Archive Group setting, which by default is “archive_disabled.” Each group 0 to 7

maps to a groupn configuration in the PollArchiveService's property sheet.

Once you have mapped a Station to archive groups in the AddressBook, you are

ready to configure the PollArchiveService itself. There are three mechanisms to poll

a group. First is a manual command on the PollArchiveService itself. Secondly you

may enable the group, and setup a poll frequency in hours (zero is a disable). The

time begins when the station is started. For instance, a group with a frequency of 2

would poll for the first time 2 hours after the station was started, then 2 hours later,

and so on. The third mechanism to enable the polling of a group is to use a trigger

input. This allows polling based on Calendars, Schedules, DateTimeTriggers, or

custom Program objects.

Additional configuration requires the station running the PollArchiveService to have

the DatabaseService, and the local LogService set to archive_local.

Operation The actual poll process is as follows. Once a group is polled, the service looks in the

AddressBook to find all the stations configured in that group. For each station it

attempts to open a connection and get the list of logs to archive and the timestamp of

their latest record. It compares this list against it own local SQL database, to see what

records are missing. If any records are missing, then a request is made back to the

station to upload all the missing records.

When the PollArchiveService requests the list of logs to archive there are three

possible outcomes, dependent on the source station’s LogService archiveMode

property. If this property is set to archive_disable, then no logs are archived during

the poll process. If this property is set to archive_remote, then the list is generated

from the in-memory object database using only logs with the polled flag set in theirarchiveSetup. If the archiveMode is set to archive_local (polling of a server), then the

list is generated from all the tables located in the archive schema of the application

database (the standard location for LogService archival).

Priority Queues

In r2.3.4 and later, “low and “high” priority queues were added, including associated

properties (status and config), plus “clear” commands. The queues provide orderly

execution of pending archives of poll groups—note that in some cases, the poll

archive for a single group may take up to an hour to complete.

• Low priority queue—For all regularly scheduled poll group archives, meaning

each initiated at intervals defined for that groupn’s frequency, in hours.

• High priority queue—For poll group archives initiated by a pollGroupn

command (see “Commands,” page 4-41) given to the PollArchiveService.

In most cases, default queue sizes (50) are recommended. In the case where you

notice status property lowPriorityQueueSize climbing much above zero (0), this may

indicate communications problems to target stations, or groups that are configured

with too low a frequency value (in hours). In the latter case, adjust the groupn’s

frequency setting higher (longer interval).





Chapter 4 Services

TimeSyncService

4–44

TimeSyncServiceQuick reference for all properties: Table A-74

abbrev: (none); TimeSyncService

The TimeSyncService provides both client

and server support for time synchronization.• As a client, the service can poll up to

three designated Time Protocol servers,

using the standard Internet Time

Protocol (RFC 868). Polling occurs at a

configurable frequency. The station’s

time is adjusted (synchronized) based

upon a configurable error tolerance.

• As a server, the station operates as a

Time Server, also using the standard

Internet Time Protocol (RFC 868).

Client and server operation can occursimultaneously, if desired. Because the

Internet Time Protocol is widely

implemented, client synchronization can

occur in a number of ways. For example, to

another Niagara station (typically, the Web

Supervisor) or ( for a Web Supervisor) to

selected public “atomic clock” Time Servers.




• syncToServer —Client operation immediately obtains the current time from

the specified timeProtocolServers, and adjusts the station’s time if necessary.

Properties

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for TimeSyncService Object(only input and output types, see Table 4-13 for all properties)


input — — —

output — — —

(none)

Table 4-13 TimeSyncService properties.


S t a t u s

objectType,



these properties common to all serviceobjects.


Timesynchronization.

serverReport1,

serverReport2,

serverReport3

Read Only: Each shows the results of thelast (client) synchronization attempt with theassociated timeProtocolServer. Format is:

<result>:<yyyy-mm-dd>T<hr:min:sec:>.tripT

Examples:

Success:2001-09-07T06:34:28.02-4No response:2001-09-07T06:34:28

See descrip. unconfigured If a host cannot befound the valueshows an errorstring, for example:

Error:java.net.Un-kownHostExcep-tion: <hostname>.





Chapter 4 Services

TimeSyncService

4–45

TimeSyncService NotesThe TimeSyncService is typically used to keep all Niagara stations for a job

synchronized to the same exact time. At the time of this reference, a URL listing ITS

(Internet Time Service) servers used by NIST (USA National Institute of Standards

and Technology) is as follows:

ht t p: / / www. boul der . ni st . gov/ t i mef r eq/ ser vi ce/ t i me- ser ver s. ht ml

Other public ITS servers are available on a world-wide basis.

C o n

f i g

serverEnabled Read-Write: Must be True for serveroperation. If False, client (time protocol)requests to the station are not answered.

False, True True

serverPort Read-Write: Specifies the application portused by the server operation.

valid portnumber

37 Port 37 is the “wellknown” Time port.

clientEnabled Read-Write: Must be True for cl ientoperation. If False, polling of time serversstops, station time is not adjusted, and statusproperties serverReportn show “Disabled.”

False, True True

clientPollFrequency Read-Write: Specifies, in minutes, thefrequency of the polling of the namedtimeProtocolServers.

1 to n 15

clientResetTolerance Read-Write: Specifies, in seconds, themaximum ± time difference among multipleservers before their times are averaged,(else an ERROR, then avg. discarded), and

then the minimum ± time difference requiredbetween this “filtered” average and station’stime before station’s time is resynchronized.

1 to n 30 With mulitple timeservers, a “filtered”average value isevaluated against

the station’s time.This “filter” is newstarting in r2.3.4.

timeProtocolServer1,

timeProtocolServer2,

timeProtocolServer3

Note: If not using theSupervisor choice,you should specify

all three (different) valid time servers tobest enable “filtering.”

Read-Write: Each property specifies a TimeServer to use for synchronization (as client).

If the station’s AddressBook is configurednaming another station as the Supervisor,the Supervisor checkbox is a valid option.

When entering server names, IP addressesare typically better than qualified hostnames.For example, 132.163.4.101 instead oftime-a.timefreq.bldrdoc.gov (NIST, Boulder,Colorado).

(each)

Supervisor(if configured) or

IP address or valid fullyqualified

hostname

— If the Supervisorcheckbox reads“not configured,” itis not a validselection.

E n g

i n e e r i n g

debug Read-Write: When set to True, providesdetailed information in the station’s StandardOutput relating to the connection to (andcommunication messages with) thedesignated Time Protocol server(s).

Includes roundtrip and oneway times, serverand station times, and delta time (in ms).

False, True False Leave debugdisabled exceptwhiletroubleshooting theTimeSyncService.

V i s u a


x 0



General,

7 others

General

Table 4-13 TimeSyncService properties. (continued)


http://www.boulder.nist.gov/timefreq/service/time-servers.html

http://www.boulder.nist.gov/timefreq/service/time-servers.html





Chapter 4 Services

UiEngineService

4–46

UiEngineServiceQuick reference for all properties: Table A-76

abbrev: (none); UiEngineService

The UiEngineService executes all user

interface objects (Gx objects) in the station. Itis mandatory for any Niagara station.

The UiEngineService is similar to the

ControlEngineService, but has a more limited

role. A cycleTime configuration property

allows setting the target execution time. The

default cycleTime (500) ms is often adjusted

upwards with no adverse effect.


Only one UiEngineService per station.



CommandsUsers with “Command, Std” privileges have the following available command:

• resetStatistics —Clears (zeroes) accumulated statistics found on the Status tab

of the property sheet. This includes execution cycle counts, overruns, average

execution times. Also cleared are the accumulated lateStarts.

Properties

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for UiEngineService Object(only input and output types, see Table 4-14 for all properties)


input — — —

output — — —

(none)

Table 4-14 UiEngineService properties.


S

t a t u s




Execution enginefor user interfaceobjects.

averageExecuteTime Read Only: Shows the average executiontime, in milliseconds, for a complete cycle(totalExecuteTime/executionCycles).

float value(ms)

—

totalExecuteTime Read Only: Shows the total execution time,in milliseconds, since the last station startup.

integer (ms)

—

executionCycles Read Only: The accumulated number of

execution cycles since last station startup.

integer —

overruns Read Only: The total number of overrunscounted. An overrun occurs when the actualcycle time exceeds its target time, as definedby the cycleTime property (on Config tab).

integer —

objectCount Read Only: The total number of objectsexecuted by the UiEngineService. Thisincludes all Gx objects in the station (not justthose in GxPage containers).

— —





Chapter 4 Services

UiEngineService

4–47

UiEngineService NotesThe UiEngineService executes only Gx objects—all other executable objects in the

station are executed by the ControlEngineService.

Object Execution When a Gx object is executed by the UiEngineService, usually there are three phases

of processing:

1. Read inputs —Values are “pulled” from outputs linked to inputs.

2. Calculation —The object’s algorithm, using its configuration properties.

3. Write shape (behavior) —The Gx object updates in appearance.

All three phases occur within the object’s execution time.

A Gx object’s appearance is usually determined by its object type and the settings of

its configuration properties.

SchedulingExecution

The Ui engine thread of the station periodically walks a list of objects and executes

them in a sequential fashion.

S t a t u s ,

c o n

t .

startTime Read Only: Shows the time of the last stationstartup. Status statistics accumulate from thispoint (until a resetStatistics is given).

— — format is:hh:mm dd-mo-yyyy

averageInterCycleDelay Read Only: Shows the average delay time, inmilliseconds, between cycle starts.

lateStarts Read Only: The number of object executioncycles that started later than “anticipated,”(after the next cycle should have begun).

C o n

f i g

cycleTime Read-Write: Target execution time, inmilliseconds, for a complete execution cycle(for all Gx objects in the station).

integer value,in milliseconds

(typically, notless than thedefault 500)

500 Commonly adjustedup (i.e. 2000)without adverseeffect, to improveoverall stationefficiency.

displayDots Read-Write: If True, causes a tilde (~) written

to Standard Output after each completion ofan execution cycle.

False, True False

V i s u a


x 0



General,

7 others

General

Table 4-14 UiEngineService properties. (continued)






Chapter 4 Services

WebUiService

4–48

WebUiServiceQuick reference for all properties: Table A-78

abbrev: (none); WebUiService

The WebUiService (Web User Interface) is

used to provide a set of views to certain Niagara objects using standard Web

browsers. An optional Niagara service, it is

included in the following products:

• Web Supervisor

• JACE-NP-2

• JACE-50x-UI

• JACE-51x-UI

• JACE-401-UI

The WebUiService includes a suite of

servlets that use HTML and Java applets to provide a Web browser interface. Some

servlets reference HTML files (templates),

which are used to frame applets. You can

customize and save HTML templates, if

needed. Configuration properties of the

WebUiService allow you to globally

reference various template files.

Parent Dependencies ServiceContainer. Only one WebUiService per station.



Commands None.

Properties

Inputs

Object Shape

Outputs

(none) (none)

Input / Output Property Reference for WebUiService Object(only input and output types, see Table 4-15 for all properties)


input — — —

output — — —

(none)

Table 4-15 WebUiService properties.




See Table 4-1 on page 4-5 for informationon these properties common to all serviceobjects.


Web browser

interface support.

C o n

f i g

defaultTemplateUrl Read-Write: References a swid file path toone of the 4 “global” HTML templates.

This default template is used as the“backup” template. It frames a WebUi appletin case one of the other 3 “global” templateproperties (GxPage, Calendar, Schedule) isblank, and a local template is not specified.

Default (new station) value:/tridium/services/defaultTemplate.html

A valid swidreferencing anHTML file thatcontains theappropriateserver tags.

See descrip. The default (newstation) value pointsto an HTML filecontained in thetridium JAR file.





Chapter 4 Services

WebUiService

4–49

WebUiService Notes

The WebUiService includes the following servlets:

• Gx —Browser access to Niagara graphics (GxPages).

• Chart —Browser access to Log charting (LogChart and LogSelector views).

• Schedule: Browser access to Schedule and Calendar object views.

• Alarm: Browser access for viewing and acknowledging alarms.

• Status: Browser access to a text table “snapshot” of current values and

statuses. A “Status Query” form (with wildcard capability) supports searches.

• Text —Supports a custom external HTTP application, responding with text

output to specific swid “object.property” requests.

Refer to For detailed information on using the WebUiService, please refer to the Niagara Web

Solutions Guide.

gxPageTemplateUrl Read-Write: References a URL filepath toan HTML template used to globally displayGxPages (graphics). It is used whenever a

local override template (property availablefor each GxPage) is not referenced.

Default (new station) value:(none—blank)

A valid swidreferencing anHTML file with

the appropriateserver tags.

See descrip. If left blank, thedefaultTemplateUrlnamed HTML file is

used instead.

calendarTemplateUrl Read-Write: References a URL filepath toan HTML template used to globally displayCalendar editor views. It is used whenever alocal override template (property availablefor each Calendar object) is not referenced.


A valid swidreferencing anHTML file withthe appropriate

server tags.

See descrip. If left blank, thedefaultTemplateUrlnamed HTML file isused instead.

scheduleTemplateUrl Read-Write: References a URL filepath toan HTML template used to globally display

Schedule editor views. It is used whenevera local override template (a property foreach Schedule object) is not referenced.


A valid swidreferencing an

HTML file withthe appropriateserver tags.

See descrip. If left blank, thedefaultTemplateUrl

named HTML file isused instead.

V i s u a


x 0



General,

7 others

General

Table 4-15 WebUiService properties. (continued)






Chapter 4 Services

WebUiService

4–50





CHAPTER

5–1

5

Control Objects

This chapter describes each of the standard Niagara control objects, that is, those

provided in the control folder of the tridium JAR file. General information on control

objects is provided first, as follows:

• About Control Objects

– BACnet Heritage

– Selecting Control Objects

• Common Control Object Things

– Trigger Properties

– Debug Command

– About Units

– Common Control Object Properties

• Event-Type Objects

– Status Properties

– Alarm Setup Properties

Individual control object descriptions follow, arranged alphabetically as follows:

• AnalogInput • DateTimeTrigger

• AnalogOutput • FunctionGenerator

• AnalogOverride • IntToFloat

• BinaryInput • Logic

• BinaryOutput • Loop

• BinaryOverride • Math

• Command • MultistateInput

• Comparison • MultistateOutput

• CpAnalogNode • MultistateOverride

• CpBinaryNode • PeriodicTrigger

• CpIntegerNode • Totalizer

• CpStringNode





Chapter 5 Control Objects

About Control Objects

5–2

About Control ObjectsControl objects provide a common platform for integrating control logic. Whether a

value or state occurs in a LonWorks device, a BACnet device, or another

proprietary/legacy device, it can be linked into control algorithms developed using

standard control objects.

Note Some JACE models (JACE-4) have onboard I/O points for direct connection of

sensors, meters, etc., and controlled loads. Special types of control objects provide

the interface to this I/O. Refer to Chapter 10, “Ndio Objects,” for more details.

Control objects are executed in the station by the “control engine” (managed by the

ControlEngineService ), as are all “Apps” objects—notably the Calendar, log-types,

Schedule, and Program objects. Most Niagara stations are engineered to use some

control and apps objects, in addition to other child-only (primitive) objects.

These other types of primitive objects include:

Shadow objects: These objects provide remote access to data in a foreign system,

that is, non-Tridium devices. Depending on the integration, a primitive shadow

object can exist at the device level or a lower, data-point level. Shadow objects are

executed by both the station’s integration-specific service, for example,

LonWorksService, and by the station’s ControlEngineService.

Gx objects: The building blocks to create a graphical user interface to the station,

accessible using the JDE or a standard Web browser. These objects are executed by

the UIEngineService, and are also processed by the WebUIService.

It is possible (but not likely), for a Niagara station to be engineered using only

shadow objects and perhaps Gx objects, if only simple monitoring of values isneeded.

However, control objects are typically required to provide things such as:

• Alarming and event notification.

• Proper value formatting (such as selected decimal display).

• Commandable control (including a command prioritization scheme).

• Inter-device control routines.

In addition, the various apps objects are typically used to provide global scheduling

control, data logging, and specialized routines typically needed when engineering a

building automation system.







BACnet Heritage

In general, Niagara control objects are implemented like the equivalent BACnet

objects (used to model data in BACnet devices). Because a Niagara station is

inherently capable of being integrated as a BACnet device, this feature allows it to

expose several standard objects directly as BACnet objects, namely:

• AnalogInput (AI) objects

• AnalogOutput (AO) objects

• BinaryInput (BI) objects

• BinaryOutput (BO) objects

• MultistateInput (MSI) objects1

• MultistateOutput (MSO) objects1

• All NDIO objects (see Chapter 10, “Ndio Objects”)

Plus, these apps objects:

–

Calendar objects– Schedule objects

• Also, special “BACnet” log objects (found in bacnet JAR) similar to types

AnalogLog, BinaryLog, IntegerLog, MultistateLog, and StringLog. When

exposed to BACnet, they appear as a “Trend_Log” object.

Niagara objects that represent analog data have assignable engineering units (for

display purposes) based on BACnet engineering units. See “About Units,” page 5-6.

In a BACnet integration, the BACnet service makes the Niagara station a BACnet

server to provide client access to these objects (to other networked BACnet devices).

At the same time, the BACnet service allows the station client access to standard

BACnet objects in remote BACnet devices, by using BACnet shadow objects.

Refer to For detailed information on Niagara and BACnet, refer to the Niagara BACnet

Integration Reference document.

BACnet Terms Niagara control objects and their properties use BACnet terminology, which may not

be immediately clear if you aren’t already familiar with BACnet. The following list

cross-references more common terms to their BACnet equivalents.

1. Some state restrictions apply. See the MultistateInput and MultistateOutput sections.

Common Use Term BACnet / Niagara Equivalent

• Alarm • Event, to-offnormal event

• On, Off / Running, Stopped • Active, Inactive

• Runtime • ElapsedActiveTime

• Logically Disconnected • Overridden

• Tri-state, 3-speed, 4-speed, etc. • Multistate







5–4

Selecting Control Objects

Until you become familiar with the different Niagara control objects, it may not be

immediately clear which types provide common functions. The table below crosses

some standard control routines to the appropriate object type.

Control Routine Needed Niagara Control Object Used

• 3-speed, 4-speed, monitoring, alarm MultistateInput (MSI)

• 3-speed, 4-speed, etc., control MultistateOutput (MSO)

• Adder (analog), up to 4-input Math (function: summation)

• Averager (analog), up to 4-input Math (function: average)

• Analog monitoring, alarm AnalogInput (AI)

• Analog value simulator FunctionGenerator

• AND logic gate, 2-input Logic (function: A_AND_B)

• Binary (2-state) monitoring, alarm BinaryInput (BI)

• Binary (2-state) control BinaryOutput (BO)

• (Browser user) command access to anotherobject’s configuration (internal) property

CpAnalogNode (float value), CpBinaryNode (boolean

value), CpIntegerNode (int value), CpStringNode (string)

• Comparison (analog), 2-input Comparison (select: A>B, A<B, A>=B, A<=B, A=B, A!=B)

• Daily One-shot DateTimeTrigger

• Difference (analog), 2-input Math (function: difference)

• Divider (analog), 2-input Math (function: division)

• Interval One-shot PeriodicTrigger

• Loop control Loop• Maximum Selector Math (function: maximum)

• Minimum Selector Math (function: minimum)

• Override AnalogOverride, BinaryOverride

• PID control (or PI, P-only loop) Loop

• NOT logic gate, 2 input Logic (function: A_NOT_B)

• OR logic gate, 2-input Logic (function: A_OR_B)

• Reset Math (function: reset)

• Setpoint Adjuster AnalogOutput (AO)

• Subtractor (analog), 2-input Math (function: difference)• Timed Override AnalogOverride, BinaryOverride, MulitstateOverride

• Totalization Totalizer

• Various trigonometric functions Math (function: various types)

• XOR logic gate, 2-input Logic (function: A_XOR_B)




Common Control Object Things



Common Control Object ThingsControl objects have properties common to all Niagara object types, such as the

status properties “objectType” and “description”. Other common properties are for

object execution and security (user access). A JDE “dump” command also exists.

Rather than explaining for each object type, these common properties are covered in

this section. Also, many object type have a “units” property, for display purposes.

A listing of all possible units selections is given in “About Units,” page 5-6.

Several object types are alarm-capable, and so have additional properties related to

alarming. See the following the “Event-Type Objects” section on page 5-11.

Trigger Properties

Most control objects have at least one “trigger-type” property. While viewing

property sheets in the JDE, you do not see trigger-type properties listed. This is

because unlike other types of properties, there is no associated value, state, or string(only the possibility of a transient “pulse,” likely to go unnoticed anyway).

In this chapter, the description for each control object type includes a “Trigger

Properties” section that lists and describes the object’s available trigger properties.

executeTrigger—Except for the Command object, every control object has a

linkable input property, executeTrigger. This input is rarely used . The intention of

this input is to have the object execute (once) each time a trigger pulse is received.

In this case, you would set the object’s configuration property execution Parameters,

“freq” field from the default setting of “normal” to “on_trigger”. Otherwise, the

object would continue to execute during each ongoing cycle of the control engine

(ControlEngineService), and it would ignore any received trigger pulses.

This is mentioned only because the executeTrigger input is shown for each object

type in the “All Inputs / Outputs” figure. However, be aware that for most control

objects, this input has limited or no application.

Debug Command

If you have “Command, Admin” privileges, this menu bar command is available in

the JDE for any control object (you must have the object’s property sheet displayed):

Commands > dump —Sends data about the object to the Standard Output window,

including the objects swid, handle, name, parent, properties and values, and links.

Note Typically, the dump command is used only during development. The JDE right-click

command Go > Report is a more flexible utility that provides similar information.

Various control object types have other available commands, both right-click types

(which are available when accessing the station using a browser), and JDE accessible

commands. Each object’s available commands are listed in subsequent descriptions.







5–6

About UnitsVarious Niagara objects have a “units” property to define how values are displayed.

Table 5-1 and 5-2 list all units by category, full unit descriptor, and “abbreviated”

unit. (By default, a linked GxText object displays a value with the abbreviated unit.)

Unit types without an abbreviation are listed as “—”, and display only with full units.

Table 5-1 Units (Area to MassFlow).

Category Selections Abbr. Category Selections Abbr.

Area square_meters sq m Enthaply joules_per_kilogram_dry_air J/kg (da)

square_feet sq ft btus_per_pound_dry_air btu/lb (da)

Currency currency1 — kilojoules_per_kilogram_dry_air KJ/kg

currency2 — Entropy joules_per_degree_Kelvin —

. . . . . . joules_per_kilogram_degree_Kelvin —

currency10 — Frequency cycles_per_hour —

Electrical milliamperes mA cycles_per_minute —

amperes A hertz hz

ohms ohms kilohertz khz

kilohms kohms megahertz mhz

megohms Mohms per_hour —

volts V Humidity grams_of_water_per_kilogram_dry_air

millivolts mV percent_relative_humidity %RH

kilovolts kV kg_of_water_per_kilogram_dry_air kg/kg (da)

megavolts MV Length millimeters mm

volt_amperes VA meters m

kilovolt_amperes kVA inches in

megavolt_amperes MVA feet ft

volt_amperes_reactive VAR micrometers um

kilovolt_amperes_reactive kVAR kilometers km

megavolt_amperes_reactive MVAR Light watts_per_square_foot W/sq ft

degrees_phase — watts_per_square_meter W/m2

power_factor — lumens lm

kiloamperes kA luxes lux

Energy joules J foot_candles ft_can

kilojoules kJ candles cd

kilojoules_per_kilogram kJ/kg Mass kilograms kg

megajoules MJ pounds_mass lb_mass

watt_hours whr grams g

kilowatt_hours kwh milligrams mgbtus btu metric_tons tonne

therms — MassFlow tons tons

ton_hours — kilograms_per_second kg/s

Kbtus Kbtu kilograms_per_minute kg/min

Mbtus Mbtu kilograms_per_hour kg/hr

megawatt_hours Mwh pounds_mass_per_minute lb/min

killowatts_per_hour kW/hr pounds_mass_per_hour lb/hr

http://-/?-

http://-/?-

http://-/?-

http://-/?-







Note By default, units in a newly-created object is typically category “Other,” “no_units.”

Table 5-2 Units (Power to Other).

Category Selection Abbr. Category Selection Abbr.

Power

milliwatts mW

Volume

cubic_feet cu ft

watts W cubic_meters m3

kilowatts kW imperial_gallons igal

megawatts MW liters l

btus_per_hour btu/hr us_gallons gal

horsepower hp

VolumetricFlow

cubic_feet_per_minute cfm

tons_refrigeration tons_rfg cubic_meters_per_second m3/s

kilocalories_per_hour kcal/h cubic_meters_per_hour m3/hr

Pressure

pascals Pa imperial_gallons_per_minute igal/min

hectopascals hPa liters_per_second l/s

kilopascals kPa liters_per_minute l/minmillibars mbar liters_per_hour l/hr

bars bar us_gallons_per_minute gal/min

pounds_force_per_square_inch psi Other degrees_angular °

centimeters_of_water — degrees_Celsius_per_hour °C/hr

inches_of_water inwc degrees_Celsius_per_minute °C/min

millimeters_of_mercury — degrees_Fahrenheit_per_hour °F/hr

centimeters_of_mercury — degrees_Fahrenheit_per_minute °F/min

inches_of_mercury — kilowatt_hours_per_square_meter kwh/m2

Temperature

degrees_Celsius °C kilowatt_hours_per_square_foot —

degrees_Kelvin K megajoules_per_square_meter MJ/m2

degrees_Fahrenheit °F megajoules_per_square_foot —

degree_days_Celsius °days_C no_units (blank)

degree_days_Fahrenheit °days_F parts_per_million ppm

delta_fahrenheit deltaF parts_per_billion ppb

Time years yrs percent %

months mnths percent_per_second %/s

weeks wks per_minute /min

days d per_second /sec

hours hrs psi_per_degree_Fahrenheit psi/°F

minutes min radians rad

seconds sec revolutions_per_minute rpm

milliseconds ms watts_per_square_meter_degree_Kelvin W/m2K

Velocity meters_per_second m/s kilograms_per_cubic_meter kg/m3

kilometers_per_hour km/h radians_per_sec rad/s

feet_per_second ft/s decibels dB

feet_per_minute ft/min raw_value Raw

miles_per_hour mph ph_value pH







5–8

Common Control Object Properties

Table 5-3 lists common properties organized in the property sheet tab in which you

can find them. In the case where some property variation exists for a particular type

of object, that difference is noted in the property table for that object type.

Table 5-3 Common propert ies for al l control objects.


S t a t u s

objectType Read Only: The control object type. Bydefault, a newly added object uses thisstring in its name (until renamed).

The full string for the object type is shown,for example, AnalogInput or Comparison.


For most object types, astandard abbreviation forthat type appears insidethe object’s shape (nearthe top).

This abbreviation isnoted in the individualdescriptions for eachcontrol object.

statusFlags Read Only: Current state of the object’s

status flags, which reflect the general“health” of the object. Depending onconditions, status flags can be set incombinations. A dominant flag sets theobject’s color to something other than gray(the same color appears at its outputs).

A “normal” state (no flags set) is where thestatus flags value is “ok”, and the object’scolor is gray. Outputs appear normally.

Briefly, status flag values mean:

• inAlarm—An alarm state currently exists.The object’s shape and outputs are red.Another property, alarmState, is True.

• fault—A fault state occurs when anotherproperty, reliability, has any value except “no_fault_detected.” The object’s shapeand outputs are orange.

• overridden—The object’s propertiespresentValue and reliability are no longertracking changes.

• outOfService—The object’s propertyoutOfService has been set to True.The object’s shape and outputs are cyan.

• unackedAlarm—An alarm has occurredthat is still pending acknowledgment.If the inAlarm flag is still set, the objectoutputs are red and also flashing.

• down—The station (or integration device)is down or offline. The object ‘s shape andoutputs are yellow.

where values

appear inbraces :

inAlarmfault

overriddenoutOfService

unackedAlarmdown

ok Not al l object types can

alarm, meaning thatsome objects havestatus flags that arenever set.

The total set of 6 statusflags is a superset of theBACnetStatusFlag type,adding these 2 flags tothe 4 BACnet types:

• unackedAlarm

• down

description Read-Write: Permits a user-defined textdescriptor for describing the object. Anyprintable characters, including spaces andmixed case characters, are allowed.

See description — Not available for aCommand object.







C

o n

f i g

executionParameters

Read-Write: Defines the frequency andorder for the object as it is executed by thestation’s ControlEngineService.

• freq (frequency)—Specifies how often theobject is executed. Typically, the defaultfrequency (normal) is acceptable.

• order —Specifies the order of execution ineach cycle. On each cycle of the controlengine, objects specified as inputs areprocessed first, then processors next, andlastly the outputs. By default, the defaultorder setting reflects the object’s type. Forexample, input-type objects (AI, BI, MSI)will have an order value of “input,”processing type objects (Loop, Logic,etc.) will have an order value of“processor,” and so forth.

freq:

never slower

normalfaster fastest

minutelyon_trigger

order:

inputprocessor

output

freq:normal

order:

<seedescrip>

This property is notavailable (nor applies to)a Command object.

Usually, default valuesare recommended.

Frequency selectionsare exclusive. Forexample, if on_trigger isselected, the object willexecute only if the inputexecuteTrigger is linkedand a trigger pulse isreceived on that input.

For related details, seeControlEngineService and its Config property“executionFrequencies”.

foreignAddress Read-Write: BACnet usage only. Exposesthe Niagara object as a BACnet object.

Note: Currently, this property has apractical application for these object types:AnalogInput (AI), AnalogOutput (AO),Binary Input (BI), BinaryOutput (BO),MultistateInput (MSI), MultistateOutput(MSO), Calendar, Schedule, and all NdioObjects.

For these object types, a valid value is anyinteger from 0 to 4194302 (the maximumBACnet Instance Number for any object).

SeeDescription

If assigned, thisproperty valuemust be unique in the station,

within the

object’s type

(AI, AO, BI, BO,MSI, MSO,Calendar,

Schedule, etc.)

-1

(not used)

Not shown for aCommand object.

Before using, theBACnet service must beinstalled and configuredin the station.

In the case of Ndioobjects, the station mustalso have theBACxNdioService. Ndioobjects count as eitherAI, AO, BI, or BOobjects—refer to

Table 10-2on page 10-8.membershipGroups Read-Write: (Future use only.) niagaraR2 niagaraR2 Leave at default.

V i s u a

l

position Read-Write: The x-y coordinates for theobject’s position on the JDE Workspace.

Coordinate values are in pixels, and arerelative to the upper-left corner of theWorkspace and the upper-left corner of theobject shape (including its input area).

An object with a position of “0,0” is in the topleft corner of the Workspace.

Some positivex, y value less than the parent

(container)object’s “size”property value.

Near themousepointer

when theobject is

firstcreated.

Typically, you don’tmanually enter positionvalues, but use themouse to drag the objectas needed on the JDEWorkspace.

However, if needed, youcan enter values directlyto “tweak” an object’sposition.

Table 5-3 Common properties for all control objects. (continued)








5–10

E n g

i n e e r i n g

minExecuteTime Read-Write: Can show the object’sminimum execution time, in mil liseconds.

Shows MAX_VALUE if “profileNodes” in the

ControlEngineService was not previouslyset (since the last station start).

integer, 0 to n Seedescrip.

Providing that theControlEngineServicewas set to

“profileNodes”, theseproperties show theobject’s executionstatistics. Typically, youdo not leave theControlEngineServiceconfigured this wayexcept for brief periodsto collect these values.

This properties are notavailable (nor apply to) aCommand object.

maxExecuteTime Read Only: Can show the object’smaximum execution time, in milliseconds.

Shows MIN_VALUE if “profileNodes” in theControlEngineService was not previouslyset (since the last station start).


averageExecuteTime

Read Only: Can show the object’s averageexecution time, in seconds.

Shows 0.0 if “profileNodes” in theControlEngineService was not previouslyset (since the last station start).

valid float Seedescrip.

userData Read-Write: Stores a user entered string.Can be used by servlets and the API forconfiguration information.

Any desiredtext string forservlet/API

usage.

<blank>

S e c u r i t y


Refer to the “Security Tab” section onpage 1-20 (Station object UserAdmin topic)for more details on how securityGroupssettings apply.


•General

•HVAC

•Security

•Life Safety

•Group 4

•Group 5

•Group 6

•Group 7


Table 5-3 Common properties for all control objects. (continued)








Event-Type Objects

Many of the control object types are alarm-capable objects, or event-type objects. All

have a common group of “Status Properties” and “Alarm Setup Properties” that have

direct BACnet heritage, including property names and definitions.

Event-type standard control objects include the following types1:

• AnalogInput (AI)

• AnalogOutput (AO)

• BinaryInput (BI)

• BinaryOutput (BO)

• Loop

• MultistateInput (MSI)

• MultistateOutput (MSO)

Rather than cover the common properties in detail for each object type, they are

explained in this section. In the case where a property variation exists for a particular

object type, that difference is noted in the property table for that specific object.

TriggerProperties

In addition to the common status and alarm setup properties, all event-type objects

have properties that are special, event-based, trigger outputs. Trigger outputs fire

upon each occurrence of a particular event, change-of-state (or value), and so forth.

Some event-type objects also have special trigger inputs. These properties are listed

and described in the “Trigger Properties” section in each object’s description.

JDE Command For any event-type object, a JDE user with “Command, Admin” privileges can access

this menu bar command (the object’s property sheet must be opened):• Commands > resetAckedTransitions —Sets any of the three flags in the

ackedTransitions property (to-offnormal, to-fault, to-normal) that are cleared.

A rarely used command, it is necessary only in one possible scenario with a

JACE-4/5 configured for “standalone alarming” (NotificationService is set to

“archive_local_no_sql”). The symptom requiring this command is if the object

indicates an “unackedAlarm”, and yet no alarm exists for acknowledgment.

It is possible due to the size of the JACE’s rolling alarm buffer (250 entries). If

enough alarms are generated in this configuration, some unacked alarms could

“roll through”, that is, get dropped. In this case, the ackedTransitions flags for

the objects that generated the dropped alarm would get stuck in the clear state.

The object will indicate an “unackedAlarm” in its status flags but the alarm cannever be acknowledged.

The resetAckedTransitions command will resolve this situation. It does not

generate an alarm acknowledgment, it just cleans up the object.

1. Most Ndio objects (JACE-4 I/O) are also event-types. Refer to Chapter 10, “Ndio Objects.”







5–12

StatusProperties

Each event-type object includes standard Niagara object status properties such as

objectType and description, plus a collection of BACnet-derived properties, listed in

Table 5-4.

Table 5-4 Status properties for standard event-type objects (AI, AO, BI, BO, Loop, MSI, MSO).


S t a t u s

eventState Read Only: Shows the object’s currentalarm state, which is one shown at right.

normalfault

offnormalhigh_limitlow_limit

normal offnormal applies to BI,BO, MSI, and MSOobjects. The high_limitand low_limit statesapply to AI, AO andLoop objects.

reliability Read-Write: Required for BACnet usage.Indicates whether the presentValue oroperation of the object is “reliable,” and ifnot, why. Selections include:

no_fault_detected, no_sensor, overrange,under_range, open_loop, shorted loop,no_output_value, unreliable_other,process_error

See Description no_fault_detected

outOfService Read-Write: Allows setting the object as outof service (when set to True).

This allows logic testing of error conditions.While set to outOfService, you can thenselect a value for the reliability property. Forexample, you can set outOfService to Trueand reliability to ”unreliable_other,” whichwill force a fault condition.

False,True

False For input-type objects(AI, BI, MSI), you canset outOfService toTrue and then write topresentValue. Thisvalue appears at theoutput while the objectis outOfService.

ackedTransitions Read Only: Flags, that when cleared,indicate that an unacknowledged eventtransition has occurred. Separate for eventtypes: to-offnomal, to-fault, to-normal.

set or cleared set Relates to the setup ofthe associatedNotificationClass object. See also the

notificationClass property description.

toOffnormal,

toFault,

toNormal

Read Only: For event transitions of type:to-offnormal (alarm), to-fault, to-normal.Each property has three fields:

• eventTime—Date and timestamp for thelast alarm event.

• ackTime—Date and timestamp for the lastacknowledgment.

• count—Total event count since the lastacknowledgment. Resets to 0 uponreceipt of acknowledgment.

valid date andtimestamp foreventTime,

ackTime, or “null”if the event hasnot occurred.

0 to <n>for any count

“null” fordate and

timestamp

0 for count

If an event-type is not set in the associatedNotificationClassobject to requireacknowledgment, theackTime value remains“null” and the countvalue never resets to 0.

presentValue Read Only or Read Write: Required for

BACnet. In normal usage, reflects theobject’s output.

For input-type objects (AI, BI, MSI), thisproperty is writable. When such an object isset to outOfService, an enteredpresentValue appears at the statusOutput.

Setting outOfService back to False clearsany previously entered presentValue.

output value or

state

— Displays in the

configured:

units(if analog),

activeInactiveText(if binary), or

stateText(if multistate)







Alarm SetupProperties

Only event-type control objects have Alarm Setup properties. Many of these

properties define how an alarm condition is determined, using settings such as alarm

limits and deadbands. These properties can vary by object type, and so are covered

individually in the description for each object type.

In addition to those properties, each event-type object has the following common

alarm setup properties, which work in a consistent manner among object types.

Table 5-5 Alarm Setup properties for standard event-type objects (AI, AO, BI, BO, Loop, MSI, MSO).


A l a r m

S e

t u p

timeDelay Read-Write: Minimum time period inHr:Min:Sec, that an alarm (off-normal)condition must exist before the objectalarms (statusFlag “inAlarm” becomes setand the object and its outputs turn red).

The delay timer begins when an alarmcondition, as configured, occurs. If the alarmcondition clears before the delay timer

expires, the object does not alarm and thedelay timer is reset.

any practicalvalue in

Hr:Min:Sec

Typically, this issome number

of seconds andor minutes

00:00:00(no delay)

This timeDelay periodalso applies to anobject returning“to-normal” from analarm state.

However, thetimeDelay period doesnot apply to transitions

to (or from) fault conditions.

notificationClass Read-Write: The assigned notification classnumber, used in routing alarms.

A NotificationClass object using the same

number must exist under the

NotificationService (container) object.

Configuration of this NotificationClassobject determines what type of events(to-offnormal, to-fault, to-normal) require

acknowledgment (ack). If an event type,such as “to-normal”, does not require anack, then it is always set (checked) in this

object’s status property, ackedTransitions.Such an event transition will never clear thatfield in ackedTransitions, meaning it will notset the statusFlag “unackedAlarm”.

An alarm requiring acknowledgment resultsin a flashing red statusOutput (see Note).

0 to 8388607 0 NotificationClassobjects reside in orunder theNotificationServicescontainer (under thestation’s services).

If the object’seventEnable flag is setfor “to-offnormal,”

AND the associatedNotificationClassobject is configured torequire an ack forto-offnormal, theobject’s statusOutputflashes red during anunacknowledgedalarm.

eventEnable Read-Write: Flags that define the types ofevent (alarm) transitions for this object thatare sent to the alarm console.

Selection ”to-offnormal” applies to anyalarm state, e.g. “high-limit” or ”low-limit” foran AI, AO, or Loop object, or “offnormal” fora BI, BO, MSI, or MSO object.

selection of anyor all:

to-offnormalto-fault

to-normal

(noneselected)

notifyType Read-Write: Required for BACnetcompliance. In a Niagara system, it makesno difference which type is selected. (Eitherselection functions the same in the Niagaraalarming subsystem.)

However, if exposing the object as BACnet,and notifyType is set to event (not alarm), anactive unacknowledged alarm is not reported by the station’s BACnet service,GetAlarmSummary.

event or alarm event







5–14

Alarm Setup Propert ies Notes

Most alarm setup properties have direct BACnet heritage. However, two of these

properties are unique to Niagara objects, namely:

• inhibitTime —This works in conjunction with the object’s statusInhibit input

(a booleanStatusType property), and applies only when this input is linked.

Note that the alarm inhibit mechanism operates independently from

“delayTime,” which is a BACnet-type property.

• eventTriggerEnable —This works in conjunction with the object’s

eventTrigger output (a triggerType property). Unlike eventEnable, which

relates to alarm notification, the eventTriggerEnable flags determine which

types of event transitions cause the object’s eventTrigger output to fire.

A l a r m

S e

t u p , c o n

t .

inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s inputs statusInhibit is linked.

The purpose is to prevent nuisance alarmson equipment startup and shutdown.

Note: For further details specific to anobject type, see the inhibitTime propertydescription for that object.


Hr:Min:Sec

00:00:00(no inhibit)

A minimum value of 1second (00:00:01) isrecommended

whenever thestatusInhibit is linked.

eventTriggerEnable Read-Write: Flags that specify the types ofevent (alarm) transitions, as they occur, thatfire the object’s eventTrigger output.

Selection ”to-offnormal” applies to anyalarm state, e.g. “high-limit” or ”low-limit” foran AI, AO, or Loop object, or “offnormal” fora BI, BO, MSI, or MSO object.


to-offnormalto-fault

to-normal

(noneselected)

These flags operateindependently of theeventEnable flags.

alarmText Read-Write: Text descriptor included in ato-offnormal or to-fault alarm for this object,as sent to the alarm console. Appears in themessageText field of the alarm record.

This text is not included in a return to-normalevent sent to the alarm console.

If left at the default hyphen (-), the object’scontainer object (Container, Bundle,Composite, PollAlways, PollOnDemand)“alarmText” property value is used.

Note: If alarms or alerts will be routed fromthe object to a Web Supervisor running the

Vykon Alarm Service, and a special alarmsound and/or URL is needed at VAS clients(associated with the object), you mustappend “extra” information at the end of thealarmText and/or alertText property. Fordetails, see the Vykon Alarm Service

Installation and Configuration Instructions.


Any text string,including

spaces andmixed casecharacters.

-(hyphen)

For BI, BO, MI, andMSO objects, anotherproperty, “alertText”,applies to runtime andCOS alerts sent to thealarm console.

If alarmText is default(-) for both the objectand its container, thethe next highercontainer’s alarmTextis used (and so on).If all parent container

objects have thedefault (-) alarmText,the Station object’salarmText is used.

Table 5-5 Alarm Setup properties for standard event-type objects (AI, AO, BI, BO, Loop, MSI, MSO).







AnalogInput

5–15

AnalogInputQuick reference for all properties: Table A-2

abbrev: AI

AnalogInput (AI) objects are used to bring

analog values into the control engine, formatthem for display, monitor them for an

off-normal condition, generate an alarm, or

pass the value onto some other control logic.

As with Niagara AO, BI, BO, MSI, and MSO

objects, you can expose any AI object in the

database directly as a BACnet object.

Parent Dependencies: None (any

container).


Trigger Properties The AI object has the standard input property, executeTrigger , (typically not used)

and also two trigger-type outputs:

• eventTrigger —Fires upon each event transition (to-offnormal, to-fault,

to-normal) that has been specified in the property “eventTriggerEnable.”

• covTrigger —Fires upon each change of value at the statusOutput.

As needed, these outputs can be linked to any input using TriggerType data species.

CommandsA JDE user with “Command, Admin” rights has this available menu bar command:

• Commands > resetAckedTransitions —Sets all three flags in the

ackedTransitions property (to-offnormal, to-fault, to-normal). Rarely required,

see the the “JDE Command” section on page 5-11 for more information.

Properties

Inputs

Default Object Shape

Outputs

statusInput statusOutput

Inputs

All Inputs / Outputs

Outputs

executeTrigger

statusInhibit

statusInput

eventTrigger

covTrigger

statusOutput

Input / Output Property Reference for AI Object(only input and output types, see Table 5-6 for all properties)


input exe executeTrigger TriggerTypesInh statusInhibit BooleanStatusType

sIn statusInput FloatStatusType

output eventTr eventTrigger TriggerType

covTrig covTrigger TriggerType

sOut statusOutput FloatStatusType

Table 5-6 AnalogInput (AI) object propert ies.


S t a t u s


See Table 5-3 on page 5-8 for informationon these properties common to all controlobjects.

— —

http://-/?-

http://-/?-






AnalogInput

5–16

S t a t u s ,

c o n

t .

eventState,reliability,outOfService,

ackedTransitions,toOffnormal,toFault,toNormalpresentValue

See Table 5-4 on page 5-12 for informationon these properties common to allevent-type control objects.

— — presentValue can bewritten to directlywhenever the object

is set tooutOfService.

C o n

f i g

executeParameters Read-Write: The object’s execution frequency and order. Formore details, see “execution Parameters,” page 5-9.

normal,input

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet AnalogInput object to other BACnetdevices. See “foreignAddress,” page 5-9,for more information.

0 to 4194302

or -1(not exposed)

-1 If set, must be aunique numberamong all otherAnalogInput objectsin station.

membershipGroups Read-Write: (Future use only.) niagaraR2 niagaraR2 Leave at default.

units Read-Write: Selection of engineering unitsfor display purposes. Choose from a logicalgrouping, then a specific unit.

For selections see “About Units,” page 5-6.

Select any(BACnet-typeunit choices)

Other,no_units

Units can bedisplayed by alinked GxTextobject.

covIncrement Read-Write: The minimum requiredchange-of-value at the statusInput (sincethe last output change) before outputs andpresentValue update. Affects these outputs:

• statusOutput

• covTrigger (fires at change of value)

valid float 0.0

(nominimum)

Execution efficiency (of downstreamobjects) is typicallyincreased byentering a smallvalue here, say 0.1

defaultInput Read-Write: The input value used by the AIobject if its statusInput link is broken orassumes a status that includes “fault.”

valid float 0.0

A l a r m

S e

t u p

timeDelay,notificationClass,eventEnable,notifyType,inhibitTime*,eventTriggerEnable,alarmText


— — * See specific detailson inhibitTime, thenext property.

inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked. Thepurpose is to prevent nuisance alarms onequipment startup and shutdown.

The inhibitTime is triggered by a transition

from false-to-true at the statusInhibit input.• When statusInhibit becomes true, alarm

processing is delayed for the inhibit time.

• Whenever statusInhibit becomes false,alarm processing remains inhibited. Thealarm status of the object cannot change.This applies whether the object’sstatusFlags show a “normal” ok state or“inAlarm” and/or “unackedAlarm” states.


Hr:Min:Sec


A minimum of 1second (00:00:01) isrecommendedwhenever thestatusInhibit is linked.

Table 5-6 AnalogInput (AI) object properties. (continued)







AnalogInput

5–17

AnalogInput NotesThe AnalogInput (AI) object is typically used to display an analog value received

from an integration (shadow) object, offering decimal place control and unit

selection. In addition, the object provides Niagara alarm capability and the option to

expose it as a BACnet Analog Input object.

A l a r m

S e

t u p ,

c o n

t .

minPresentValue Read-Write: Valid processing low range forthe received input value.

Below this value, the object and its output

have a fault status (orange color).

valid float MIN_VALUE is default, meaningno effective minimum.

maxPresentValue Read-Write: Valid processinghigh range forthe received input value.

Above this value, the object and its outputhave a fault status (orange color).

valid float MAX_VALUE is default, meaningno effective maximum.

highLimit Read-Write: Value above which the object isevaluated in high-limit alarm.

Above this value (if not in fault), the objectand output have inAlarm status (red color).

valid float 0.0

lowLimit Read-Write: Value below which the object isconsidered in low-limit alarm.

Below this value (if not in fault), the object

and output have inAlarm status (red color).

valid float 0.0

deadband Read-Write: Differential value applied tohigh and low limits before return-to-normal.

Deadband is subtracted from highLimit andadded to lowLimit.

valid float 0.0 Deadband does notapply to faultconditions.

limitEnable Read-Write: Flags that enable low-limit andhigh-limit alarms, as needed.

(select)

low-limit,high-limit

(none)

V i s u a

lposition Read-Write: See “position,” page 5-9. — —

decimalFormat Read-Write: Sets decimal posit ion from 0 to6 places, and optionally force (+) sign forpositive values.

0 to 6,

(+) sign’no (+) sign

2,

no (+) sign

Effects display valueonly (no effect onprecision).

E n g

i n e e r i n g

minExecuteTime,maxExecuteTime,averageExecuteTime,userData

Properties common to all control objects.For more information, see Table 5-3 onpage 5-8.

— —

statusInhibit(input sInh)

Read Only: Shows the current boolean stateand status of the statusInhibit input.

false, true :status flags

false : ok

statusInput(input sIn )

Read Only: Shows the current value andstatus received on the statusInput.

<float value>status flags

00.0 ok

statusOutput(output sOut)

Read Only: Shows the current value andstatus of the statusOutput.


00.0 ok



General,

7 others

General

Table 5-6 AnalogInput (AI) object properties. (continued)







AnalogInput

5–18

AlarmingFunctions

Any AI object can be configured for alarm indication, and optionally, event (alarm)

notification. The object provides properties to set values for alarm limits, alarm

deadband, alarm delay, and event notifications, using BACnet-type properties.

The following subtopics apply to AI alarming:

• AI Alarm Detection• AI Alarm Notification

• AI Alarm Inhibit

• AI Alarm Delay

Figure 5-1 AI objects have alarming functions with BACnet-type properties.

AI Alarm DetectionSeveral properties on the Alarm Setup tab determine whether an alarm condition can

be detected by the object. In order of relative importance, these properties include:

• highLimit —Value above which the object can be considered “offnormal,”

with a status (eventState property) of “high_limit.” The object shape and its

statusOutput are red in this state. The appropriate limitEnable flag must be set.

• lowLimit —Value below which the object can be considered “offnormal,” with

a status (eventState property) of “low_limit.” The object shape and its

statusOutput are red in this state. The appropriate limitEnable flag must be set.

• limitEnable —Flags that determine whether the object can alarm, using the

respective highLimit and lowLimit properties. The default is for both flags

cleared, meaning that the object cannot alarm. You must set flags as needed.

• deadband —Differential value that must be applied to high and low limits

before a return from a “high_limit” or “low_limit” status to “normal” status

occurs. Deadband is subtracted from the highLimit and added to the lowLimit.

• timeDelay —Optional time period that must be met before any alarm state

change occurs with the object. See “AI Alarm Delay” on page 5-20.

inhibitTime and eventTriggerEnable areNiagara-only properties. See “AI Alarm Inhibit”.

“fault” limits, if any, are defined byminPresentValue and maxPresentValue

These four properties(listed at the bottom ofthe Alarm Setup tab)define alarm detection.

notificationClass,eventEnable, and notifyType

apply to alarm notification.






AnalogInput

5–19

AI Alarm Notification

Alarming notification determines which type of event transitions (alarms) are sent to

the Niagara alarming subsystem (Alarm Console). Events sent to the alarming

subsystem require user acknowledgment.

Note Alarm notification is a “step beyond” alarm detection. If you want only alarm

detection (and visual indication) for an object, leave the eventEnable flags cleared.

Using the various recipient options for the target notificationClass object, event

notifications can also be routed to printers, e-mail addresses, and APIs. If the AI

object is exposed as a BACnet object, BACnetRecipients can also be designated.

In the AI object, properties on the Alarm Setup tab relating to notification are:

• notificationClass —Must match an existing notificationClass object in the

station’s notificationServices container. The default class is zero (0).

• eventEnable —Flags that determine which event transition types are sent tothe alarming subsystem (to-offnormal, to-fault, to-normal). The default is all

flags cleared, meaning that object alarms are not sent for notification. You must

set flags as needed to receive alarm in the alarm console, route alarms, etc.

• notifyType —Either event (the default) or alarm. Operation within the Niagara

alarming subsystem is the same for either selection.

However, in a BACnet integration, in a response to a requesting BACnet

client’s “GetAlarmSummary” request, the station reports “BACnet-exposed

objects” currently in alarm only if their notifyType properties are set to alarm.

• alarmText —Text descriptor sent as an alarm record field whenever a

“to-offnormal” or “to-fault” event transition occurs (not a “to-normal”).

AI Alarm Inhibit

In addition to BACnet-type alarm properties, Niagara provides an alarm inhibit

feature based upon a boolean input to the object. Use of this feature is optional.

However, whenever the statusInhibit input is linked , the object’s inhibitTime

property should hold a defined value (not the default of 00:00:00 in Hr:Min:Sec).

Otherwise, the AI object will not be capable of alarming.






AnalogInput

5–20

Figure 5-2 Alarm inhibit feature requires linking to the statusInhibit input.

The inhibit feature is intended to prevent unintended alarms, such as in after-hours

situations where a piece of equipment is turned off. For example, a return air

humidity sensor for an air handler may require alarm-limit monitoring during unit

operation (and only when the unit is running), as shown in Figure 5-2.

In this particular example, an alarm-status change can occur only after the air handler

has been running at least 15 minutes, as defined in the object’s inhibitTime. The

inhibit timer is reset whenever a state change at the statusInhibit input is received.

AI Alarm Delay

Alarm delay is a BACnet-type property, separate from the alarm inhibit mechanism.

It means that the object’s statusInput must meet the “alarm-change criteria” for a

continuous period equal to or greater than defined in the timeDelay property, before

an alarm status change occurs.

The alarm delay applies to both types of status transitions:• “to-offnormal”, meaning normal (ok) to alarm (high_limit, low_limit)

• “to-normal”, meaning alarm (high_limit, low_limit) to normal (ok)

In the case of a “to-normal” transition, the alarm-change criteria includes any defined

deadband value.

The general intention is to prevent nuisance alarms caused by momentary spikes or

dips in a received value. Typically, when both an alarm delay and alarm inhibit is

used, the timeDelay is shorter than the inhibitTime.

Fault Conditions The min and maxPresentValue properties can be used to set fault limits on the value

received at the object’s statusInput. When below or above these limits, the AI object

and its statusOutput have a status of “fault” (show as orange).

Default values for these properties are “MIN_VALUE” and “MAX_VALUE”;

effectively this means that no fault values are defined.

Whenever a logic false(inactive) is at thestatusInhibit (sInh) input,the AI object cannotchange status to (or from)

an alarm condition.

Upon a false-to-true (active) transition,the object’s inhibitTime periodbecomes effective. Until this periodexpires, the object remains inhibited from any alarm status change.

After the inhibitTime period expires,the object is capable of changingalarm status to (or from) alarm.

inhibitTime = 00:15:00(15 minutes)






AnalogInput

5–21

Note In some integrations, related shadow objects have a statusOutput that supplies fault

status information, however, you can define fault limits in a linked AI object as well.

If defined, min and maxPresentValue properties should extend past any configured

alarm limits (minPresentValue < lowLimit and maxPresentValue > highLimit). Notethat the alarm delay feature does not apply to transitions to (or from) a fault status.

Examples Figure 5-30 shows several examples of using AnalogInput objects.

Figure 5-3 AnalogInput examples.

The two AI objects at rightare used to format thereceived decimal value toone place, and assign units(temperature, in this case).

This AI object passes aduct pressure value, asconverted by a Math object(DIV) from Pascals toinches water column.

Here, the AI object isnecessary only foralarming capability andexposure as a BACnetobject (as the Math objectalso has units and decimal

values for display).

The eventTrigger output ofthis AI object is linked to thedoArchiveTrigger input atmultiple log-type objects.

If an alarm (or other statusevent) occurs, the logobjects archive theiraccumulated data to thestation’s designatedarchive supervisor.

By default, a linked GxTextobject shows the“abbreviated” units of theAI object.

This AI object providesalarming capability andthe ability to be exposedas a BACnet object.

This AI object is also configuredfor alarm inhibit. See See “AIAlarm Inhibit” on page 5-19.






AnalogOutput

5–22

AnalogOutputQuick reference for all properties: Table A-4

abbrev: AO

AnalogOutut (AO) objects provide a

prioritized analog output signal to othercontrol logic. Typically, an AO object is used

to adjust a setpoint in an a foreign device’s

application.

As with Niagara AI, BI, and BO objects, you

can expose any AO object in the database

directly as a BACnet object.


container).


Note: Upon any link change (add or delete

any link) to an AO object, commands at

priority-slots (1-16) that were received

from priorityArray links are momentarily

cleared. The priorityArray input is now

immediately rescanned; any input

command found remains effective at the

output .

Trigger Properties The AO object has the standard input property, executeTrigger , (typically not used)

and also two trigger-type outputs:

• eventTrigger —Fires upon each event transition (to-offnormal, to-fault,to-normal) that has been specified in the property “eventTriggerEnable.”



CommandsThe right-click command menu provides these commands (note that default

command names are shown, these are modifiable using the object’s commandTags

property):

• Set —To set an output value at the Manual level (8).

Requires “Command, Std” privileges.

• Auto —To clear an output value set at the Manual level (8).


• EmergencySet —To set an output value at the Emergency level (1).

Requires “Command, Emer” privileges.

• EmergencyAuto —To clear an output value set at the Emergency level (1).


Inputs


Outputs

priorityArray

statusInput

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInhibit

priorityArray

statusInput

eventTrigger

covTrigger

statusOutput

prioritizedOutut

statusFeedbackOutput

Input / Output Property Reference for AO Object

(only input and output types, see Table 5-7 for all properties)Type Label Property Name Data Species

input exe executeTrigger TriggerType

sInh statusInhibit BooleanStatusType

pIn priorityArray FloatPriorityArrayType





pOut priorit izedOutput FloatPriorityType

sFbOut statusFeedbackOutput FloatStatusType






AnalogOutput

5–23

For a JDE user with “Command, Admin” privileges, the following object command

is available from the menu bar:




PropertiesTable 5-7 AnalogOutput (AO) object propert ies.


S t a t u s



— —

eventState,reliability,outOfService,ackedTransitionstoOffnormal,

toFault,toNormal,presentValue


— — presentValue isalways read-only.

P r i o r i t i e s

priorityArray(input: pIn )

Read Only: Shows values present on eachof the 16 priority level slots for thepriorityArray (pIn) input.

<valid float> orauto,

levels 1 to 16

auto

1 to 16

relinquishDefault Read-Write: Defines the output value whenall 16 priority level slots have an “auto”.

valid float 0.0

C o n

f i g


normal,output

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet AnalogOutput object to other

BACnet devices. See “foreignAddress,” page 5-9, for more information.

0 to 4194302

or -1(not exposed)

-1 Must be a uniquenumber among allAnalogOutput objects

in station.





Other,no_units

covIncrement Read-Write: The minimum requiredchange-of-value at the priorityArray input (since the last output change) before theoutputs and presentValue update. Affectsthese outputs:

• prioritizedOutput

• statusOutput


valid float 0.0

(nominimum)

Execution efficiency (of downstreamobjects) is typicallyincreased by enteringa small value here,say 0.1

A l a r m

S e

t u p









AnalogOutput

5–24

A l a r m

S e

t u p ,

c o n t .

inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked. The

purpose is to prevent nuisance alarms onequipment startup and shutdown.

Note: Alarming is based solely on the valueat the priorityArray input (unlike a BO orMSO object, the statusInput is ignored).

The inhibit timer is triggered by a transitionat the statusInhibit input.

• When statusInhibit becomes true, alarmprocessing is delayed for the inhibit time.

• When statusInhibit becomes false, alarmprocessing remains inhibited. While alarmprocessing is inhibited or delayed, the

alarm status of the object cannot change.This applies whether the object’sstatusFlags show a “normal” ok state or“inAlarm” and/or “unackedAlarm” states.


Hr:Min:Sec


A minimum of 1second (00:00:01) isrecommended


minPresentValue Read-Write: Valid processing low range.Below this value, the object and itsstatusOutput have a fault status (orange).

The minimum value that can be set for theobject using its right-click command menu.

Less than maxsetting (below)

See Notes Defaults are MIN andMAX_VALUE.

A non-default value isrequired for both ofthese properties inorder to provide aslider adjustmentfrom the JDE.

maxPresentValue Read-Write: Valid processing high range.Above this value, the object and itsstatusOutput have a fault status (orange).

The maximum value that can be set for the

object using its right-click command menu.

Greater thanmin setting

(above).

See Notes

highLimit Read-Write: Value above which the object isconsidered in high-limit alarm.

valid float 0.0

lowLimit Read-Write: Value below which the object isconsidered in low-limit alarm.

valid float 0.0

deadband Read-Write: Differential value applied tooff-normal limits before return-to-normal.

valid float 0.0

limitEnable Read-Write: Flags that enable low-limit andhigh-limit alarms.

valid float 0.0

V i s u a

l

position Read-Write: See “position,” page 5-9. — —

decimalFormat Read-Write: Sets decimal position from 0 to6 places, and optionally force (+) sign for

positive values.

0 to 6,

(+) sign,

no (+) sign

2,

no (+) sign

commandTags Read-Write: Defines the command labelsthat show on the right-click command menufor the object. Default tags are:

• Set (manualSet level)

• Auto (manualAuto level)

• Emergency Set (emergencySet level)

• Emergency Auto (emergencyAuto level)

Any desiredtext string,including

spaces andnumerals.

Seedescrip.

If a tag is blank (nocharacters), thecommand is notavailable on thecommand menu.

See Figure 5-2.

Table 5-7 AnalogOutput (AO) object properties. (continued)







AnalogOutput

5–25

AnalogOutput NotesThe AO object is typically used to provide a user-adjustable setpoint. In some cases,

an AO object is used to directly control a physical analog output of a remote device,

represented by a shadow object. In this case, the statusOutput of the AO object is

typically linked to an input of a device object, or to an input of an AO “point” object.

CommandRelatedProperties

Although the object provides alarming capabilities identical to the AI object (based

upon the value at the priorityArray input) AO objects are not typically configured for

alarm indication and notification.

However, two properties on the Alarm Setup tab of the property sheet are routinely

configured from defaults, namely:

• minPresentValue —Determines the minimum valid value that can be

commanded, using the right-click Set command.

• maxPresentValue —Determines the maximum valid value that can be

commanded, using the right-click Set command.

These limits also define “fault” status conditions for the AO object. Such conditions

can occur if the priorityArray input is linked, and the received value falls outside of

these limits. During a fault condition, the AO object and its statusOutput are colored

orange.

E n g

i n e e r i n g

minExecuteTime,maxExecuteTime,averageExecuteTime,

userData


— —

statusInhibit(input: sInh)



false : ok

statusInput(input: sIn )


Note: This input value is not used in the AOobject’s alarm processing (no real use).


00.0 ok If statusInput is notlinked, reflects valueat priorityArray.

statusOutput(output: sOut)



00.0 ok

prioritizedOutput(output: pOut)


<float value> @<pri. level>

0.00 @ 16


(output: sFbOut) Read Only: Shows the current value andstatus at the statusFeedbackOutput. <float value>status flags 00.0 ok Reflects statusInputvalue (if linked),otherwise shows thestatusOutput value.



General,

7 others

General

Table 5-7 AnalogOutput (AO) object properties. (continued)







AnalogOutput

5–26

Note that both minPresentValue and maxPresentValue must be configured from the

defaults in order for the “slider bar” to appear in the JDE when commanding the

object, either directly or from a linked Gx object (Figure 5-4).

Figure 5-4 Command limits are determined by min and maxPresentValue (Alarm Setup tab).

This AO object has thedefault values for min andmaxPresentValue.

When using the JDE or a webbrowser to issue a right-clickcommand to the object(either directly, or through alinked Gx object), any valuecan be entered.

This AO object hasconfigured values for min andmaxPresentValue.

When using the JDE to issuea right-click command to theobject (either directly orthrough a linked Gx object), aslider bar appears that can bedragged to change the value.The commanded value canonly be between theconfigured limits.

No slider is available whenissuing an AO command froma Web browser (through alinked Gx object).

However, the popup controlremains displayed if thecommanded value is beyondmin or maxPresentValue.

In addition, the lower leftcorner of the browser windowshows an “Invalid Input” whilethe cursor is over the OKbutton.

Use the Alarm Setuptab to access min andmaxPresentValue.

Default “MIN” and “MAX” values

allow a Set command to any value.

Slider bar appears because both min andmaxPresentValue are configured.

Use the Alarm Setuptab to access min andmaxPresentValue.

The lower left corner of the browser shows“Invalid Input” with the cursor over OK.

Popup control for right-click commandwhen using a Web browser.

Whenever the entered value is out ofrange, the popup command control

remains visible after clicking OK.






AnalogOutput

5–27

Command Tags It is typical for AO objects to be configured with custom command “labels,” using

the commandTags property, located on the Visual tab of the object’s property sheet.

Editing commandTags allows more meaningful right-click menu labels on the

right-click menu than the default values, for example, “Adjust Setpoint” vs. “Set.” In

addition, you can clear any tags to make those commands unavailable (Figure 5-5).

This is often done for emergency-level commands, for example.

Examples Figure 5-6 shows two examples of using AnalogOutput objects.

Figure 5-5 The commandTags property (Visual tab) determines how (and which) commands are listed.

Figure 5-6 AnalogOutput examples.

These AO objects are usedfor setpoint control of aLON VAV device.

The commandTagsproperty of the occupiedsetpoint AO object hasbeen edited from defaultsto provide only a manuallevel set command(“Change Setpoint”).

AO objects at right areused to control physical

AOs of a LON HoneywellXFL522 device.

SnvtSwitchMux objects areneeded between the AOobjects and the XFL522device object for binding tothe device’s associatedNVIs.






AnalogOverride

5–28

AnalogOverrideQuick reference for all properties: Table A-5

abbrev: AOvrd

An AnalogOverride (AOvrd) object provides

a prioritized analog output signal that iscontrolled from a right-click command menu.

Commands include starting a timed-override

for a specified duration, canceling an

override, and changing the override value.

The priority level of an override is

configurable to any level (from 1 to 16).


container).


Trigger Properties The AOvrd object has the standard input property, executeTrigger , (typically not

used) plus an additional trigger-type input :

• overrideTrigger —Any received trigger pulse starts an override at the object’s

presently configured overrideValue, overrideTime, and priorityForWriting.

If needed, this input can be linked to an object with a trigger-type output, for

example, a Command object. This would allow a user to start an override, but not to

change the override value, cancel the override, or change its duration. An overridewould be started each time a trigger pulse is received at this input.

CommandsFor any user with “Command, Std” privileges, an AOvrd object has a right-click

command menu that provides these commands:

• override —To start an override and specify the duration, in minutes.

• cancel —To cancel any current override.

• setOverrideValue —To set the prioritizedOutput value used in an override.

Properties

Inputs


Outputs

(none) statusInOverride

prioritizedOutput

Inputs


Outputs

executeTrigger

overrideTrigger

inOverride

statusInOverride

prioritizedOutput

Input / Output Property Reference for AnalogOverride Object(only input and output types, see Table 5-8 for all properties)


input exe executeTrigger TriggerTypeoverride overrideTrigger TriggerType

output inOverr inOverride boolean

sInOv statusInOverride BooleanStatusType

pOut priori tizedOutput FloatPriorityType

Table 5-8 AnalogOverride (AOvrd) object properties.


S t a t u s

statusFlags Read Only: See Table 5-3 on page 5-8.

inOverride(output: inOverr )

Read-Only: Indicates if an override iscurrently in effect (True) or not (False).Available as a linkable output.

False, True False boolean dataspecies.






AnalogOverride

5–29

AnalogOverride NotesThere are two basic ways to use an AnalogOverride object:

• Available directly to users—see “Directly Available”.

• Available through a Command object—see “Used with a Command object”.

C o n

f i g


normal,input

foreignAddress Read-Write: Does not apply to this object. -1 -1


priorityForWriting Read-Write: Defines the priority level usedat the prioritizedOutput during an override.

When the override expires or is canceled,this level is auto’ed.

Any prioritylevel,

from 1 to 16

ManualOperator

(8)

overrideTime (min) Read-Write: Defines the duration of anoverride, in minutes.

When an override is commanded, this timeis initialized and begins counting down. Ifnot canceled or re-initiated, the override willlast this duration.

This property is most important when using

the input “overrideTrigger.”

Any positiveinteger from 1

up to 32-bitlimit.

60 If using the object’sright-click commandmenu, this overridetime is displayed (andcan be adjusted)each time an overrideis issued.

overrideValue Read-Write: Defines the value that appearsat the prioritizedOutput during an override.This value will be issued at the priority leveldefined in the priorityForWriting property.

When the override expires or is canceled,the output value expires (level is auto’ed).

This property is most important when usingthe input “overrideTrigger.”

Any floatingpoint value.

0.0 If using the object’sright-click commandmenu, this overridevalue can beadjusted(setOverrideValue).

V i s u a



0 to 6,


2,

no (+) sign

E n g

i n e e r i n g



— —

statusInOverride(output sInOv)

Read Only: Shows if an override is activeand also the status of the object. Appears bydefault as a linkable output.

true or falsestatus flags

false ok BooleanStatusTypedata species.

prioritizedOutput(output pOut)

Read Only: Shows the value and prioritylevel currently on the prioritizedOutput.Appears by default as a linkable output.

<ovrd value>@ <pri. level>

auto @ 8 FloatPriorityTypedata species.



General,

7 others

General

Table 5-8 AnalogOverride (AOvrd) object properties. (continued)







AnalogOverride

5–30

Directly Available The right-click menu for an AnalogOverride object provides the user a list of

commands, providing the ability to:

• Initiate an override, specifying the duration in minutes.

• Cancel an override.

• Change the analog value for an override (setOverrideValue).

Note A setOverrideValue command does not affect an override in progress.

If changed, the duration of override and/or the override value are stored in the

object’s Config properties. These values become the defaults for the next command,

and are seen when the command’s popup control appears (Figure 5-7).

Figure 5-7 An override or setOverrideValue command shows the currently stored value.

Popup controlfor right-clickoverridecommandwhen usingthe JDE.

Popup controlfor right-clickoverridecommandwhen using aWeb browser .

Popup control forright-clicksetOverrideValuecommand whenusing the JDE.

Popup control forright-clicksetOverrideValuecommand whenusing a Webbrowser .






AnalogOverride

5–31

Used with aCommand object

In some scenarios, direct access to an AnalogOverride object may provide too much

user control for changing override parameters (duration times and override values).

In this case, linking a Command object to the object’s overrideTrigger may be better.

In this configuration, a user can be given access to the Command object (but not

directly to the AnalogOverride object). This allows the initiation of an override, but

no other control (including canceling an override). The outputTrigger text property

of the Command object should be given a descriptive label for the configured

override action (Figure 5-8).

Other Notes The standard set of library (lib) Program objects includes an object used to derive the

remaining override time. Two links are required to the AnalogOverride object.

Figure 5-9 RemainingOverrideTime object in Local Library (tridiumx/lib/programs/hvac) used with AnalogOverride.

Figure 5-8 Control from a linked Command object allows override initiation only.

Command object linked tooverrideTrigger input.

outputTriggerText ofCommand object.

Popup right-clickcommand tolinked Commandobject, seen froma Web browser .

Popup right-clickcommand tolinked Commandobject, seen fromthe JDE.

Local Libraryopened with lib JAR expanded toreveal programs folders (hvac).

Copy the object(sns file) andpaste it into yourstation asneeded.

Copied RemainingOverrideTime object.

Two links are required between theAnalogOverride object and the Programobject (RemainingOverrideTime):

overrideTime to overrideTime

statusInOverride to statusInOverride

Remaining override time value.Can be linked to a GxText todisplay to time to users.






BinaryInput

5–32

BinaryInputQuick reference for all properties: Table A-9

abbrev: BI

BinaryInput (BI) objects are used to bring

digital values into the control engine,generate an alarm on a digital state, or pass

the value onto some other control logic.

The BI object collects runtime (elapsed active

time) and counts COS (changes-of-state).

Based upon configurable limits, the object

can be set to generate alerts for both runtime

levels and COS counts. Trigger inputs allow

the clearing of the COS count and the runtime

value. Trigger outputs are available that fire

upon each COS, COS alert, runtime alert, and

alarm (event).

As with Niagara AI, AO, and BO objects, you

can expose any BI object in the database as a

BACnet object.


container).


Trigger Properties The BI object has the standard input property, executeTrigger , (typically not used)

and also 2 other trigger-type inputs:

• resetChangeOfStateCountTrigger —Any received trigger pulse clears the

object’s current count of COS (changes of states), resetting it to zero (0).

• resetElapsedActiveTimeTrigger —Any received trigger pulse clears the

object’s accumulated runtime (elapsed active time), resetting it to zero (0.0).



• changeOfStateTrigger —Fires upon each change-of-state at the statusOutput.

• changeOfStateAlertTrigger —Fires each time a change-of-state alert is issued

(COS count has reached the “changeOfStateAlertLimit” value, or a “multiple”

of this value if “periodicAlerts” is set to True).

Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInhibit

resetCOSCountTrigger*

resetElpActTimeTrigger*

statusInput

*abbreviations,see chart below

eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

statusOutput


Input / Output Property Reference for BI Object(only input and output types, see Table 5-9 for all properties)




resetCt resetChangeOfStateCountTrigger TriggerType

resetElp resetElapsedActiveTimeTrigger TriggerType

sIn statusInput BooleanStatusType


sCnt statusChangeOfStateCount IntegerStatusType

sCnt statusElapsedActiveTime IntegerStatusType

cosT changeOfStateTrigger TriggerType

cosAlrt changeOfStateAlertTrigger TriggerType

elActAlr elapsedActiveTimeAlertTrigger TriggerTypesOut statusOutput BooleanStatusType






BinaryInput

5–33

• elapsedActiveTimeAlertTrigger —Fires each time a runtime alert is issued

(“activeTimeAlertLimit” value has been reached), or when a “multiple” of this

value occurs (if “periodicAlerts’ is set to True).

As needed, these trigger-type inputs and outputs can be linked to other objects.

Commands For a JDE user with “Command, Admin” privileges, the following object commands

are available from the menu bar (for example, Command > resetActiveTime):

• resetAckedTransitions —Sets all three flags in the ackedTransitions property

(to-offnormal, to-fault, to-normal). Rarely required, see the the “JDE

Command” section on page 5-11 for more information.

• resetChangeOfStateCount —This sets the changeOfStateCount property

value to zero (0), clearing any COS count.

• resetActiveTime —This sets the elapsedActiveTime property value to

00:00:00 (Hr:Min:Sec), clearing any accumulated runtime.

• setChangeOfStateAlertLimit —Allows editing of the

changeOfStateAlertLimit property value (Alarm Setup property).

• setRuntimeAlertLimit —Allows editing of the activeTimeAlertLimit

property value (Alarm Setup property).

PropertiesTable 5-9 BinaryInput (BI) object propert ies.


S t a t u s



— —

eventState,

reliability,outOfService,ackedTransitionstoOffnormal,toFault,toNormal,presentValue


on these properties common to allevent-type control objects.

— — presentValue can

be written todirectly wheneverthe object is set tooutOfService.

changeOfStateTime Read Only: Shows a date/timestamp for thelast COS (change of state).


null

changeOfStateCount Read Only: Shows the total number ofchanges of state that have occurred sincethe last COS count reset (clear).

integer value 0

timeOfStateCountReset Read Only: Shows a date/timestamp forwhen the COS count was last cleared.


null

elapsedActiveTime Read Only: Shows the accumulated runtime(elapsed active time) formatted inHr:Min:Sec.

Time period upto 9999:99:99(Hr:Min:Sec)

00:00:00

timeOfActiveReset Read Only: Shows a date/timestamp forwhen the accumulated runtime (elapsedactive time) was last cleared.


null






BinaryInput

5–34

C o n

f i g


normal,input

foreignAddress Read-Write: BACnet usage only. Set to a

positive integer for this object to appear as aBACnet BinaryInput object to other BACnetdevices. See “foreignAddress,” page 5-9, formore information.

0 to 4194302

or -1(not exposed)

-1 Must be a unique

number among allBinaryInputobjects in station.


polarity Read-Write: Determines if the sameboolean state at the statusInput is reflectedat the statusOutput (normal), or if the outputremains opposite from the input (reverse).

normal, reverse normal

defaultInput Read-Write: The input value used by the BIobject if its statusInput link is broken orassumes a status that includes “fault.”

Inactive, Active Inactive

A l a r m

S e

t u p

timeDelay,

notificationClass,eventEnable,notifyType,inhibitTime*,eventTriggerEnable,alarmText


on these properties common to allevent-type control objects.

— — * See specific

details oninhibitTime, thenext property.

inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked.The purpose is to prevent nuisance alarmson equipment startup and shutdown.

The inhibitTime is triggered by a transition atthe statusInhibit input.


• When statusInhibit becomes false, alarmprocessing is delayed for three times theinhibit time.


Hr:Min:Sec


A minimum valueof 1 second(00:00:01) isrecommendedwhenever thestatusInhibit inputis linked.

Alarm processingcompares thestatusInput valueto the definedalarmValue.

changeOfStateAlertLimit Read-Write: Number of COS occurrencesthat generate a changeOfStateCount alert.

Positive integer 0

activeTimeAlertLimit Read-Write: Amount of runtime (elapsedactive time), in Hr:Min:Sec, that generates aruntime alert.

Value up to99999:59:59(Hr:Min:Sec)

00:00:00

alertNotificationClass Read-Write: The assigned notification classnumber, used in routing alerts.


number should exist in theNotificationService object’s container.

0 to 8388607 0

periodicAlerts Read-Write: Determines if both COS countalerts and runtime alerts are periodicallygenerated each time the respective limit isreached.

False, True False

Table 5-9 BinaryInput (BI) object properties. (continued)







BinaryInput

5–35

BinaryInput NotesThe BinaryInput (BI) object is typically used to display a binary state received from

an integration (shadow) object, offering configurable display text for the two boolean

states. In addition, the object provides Niagara alarm capability and the option to

expose it as a BACnet Binary Input object.

See the following main topics on configuring a BI object:

• Routinely Configured BI Properties

• BI Alarming Functions

• BI Alert Notifications

A l a r m

S e

t u p

, c o n

t .alertText Read-Write: Text descriptor included in

either a COS count alert or runtime alert.

If left at the default hyphen (-), the Station

object’s alertText is used.

Any text string,including spacesand mixed case

characters.

-(hyphen)


alarmValue Read-Write: Defines the digital state that isevaluated as an alarm.

Active, Inactive Active

alarmValueEnabled Read-Write: Determines if the BI object isconfigured for alarming.

False, True False

V i s u a

l


activeInactiveTextactive,inactive

Read-Write: Defines how states display atthe statusInput, statusOutput, andpresentValue, also how they appear on theobject’s property sheet.

Any desireddescriptors forthe two states.

Active,Inactive

State descriptorscan display at alinked GxTextobject.

E n g

i n e e r i n g

minExecuteTime,maxExecuteTime,

averageExecuteTime,userData

Properties common to all control objects.For more information, see Table 5-3 on

page 5-8.

— —

statusInhibit

(input sInh)



false : ok

statusChangeOfStateCount

(output sCnt)

Read Only: Shows the current COS count.Available as a IntegerStatusType output.

<count> :status flags

0 : ok

statusElapsedActiveTime

(output sElpT)

Read Only: Shows the current runtime(elapsed active time), totaled in seconds.Available as a IntegerStatusType output.

<seconds> :status flags

0 : ok

statusInput

(input sIn)

Read Only: Shows the current state andstatus received on the statusInput.

Inactive, Active Inactive :ok

statusOutput

(output sOut)

Read Only: Shows the current state andstatus of the statusOutput.




General,

7 others

General

Table 5-9 BinaryInput (BI) object properties. (continued)







BinaryInput

5–36

RoutinelyConfigured BIProperties

Among all properties on a BI object’s property sheet, the two most typically

configured are:

• activeInactiveText (Visual tab)—Defines the display descriptors used for the

object’s boolean states (active and inactive). Assigned descriptors appear in

linked GxText objects and in the accumulated data of a linked BinaryLog.

• defaultInput (Config tab)—Defines the statusOutput state produced

whenever a “fault” is received on the statusInput. A fault may originate from

the output of a shadow object, for example.

If alarming functions and/or alerts are needed, additional Alarm Setup properties are

configured from default values.

BI AlarmingFunctions

Any BI object can be configured for alarm indication, and optionally, event (alarm)

notification. The object provides properties to define the alarm state, alarm delay, and

event notifications, using BACnet-type properties.

The BI object can also generate “alerts” based on configurable limits for runtime

(elapsed active time) and change-of-state transitions. See “BI Alert Notifications” on

page 5-39 for more information.

The following subtopics apply to BI alarming:

• BI Alarm Detection

• BI Alarm Notification

• BI Alarm Inhibit

• BI Alarm Delay

Figure 5-10 BI objects have alarming functions with BACnet-type properties.

inhibitTime and eventTriggerEnable areNiagara-only properties. See “BI Alarm Inhibit”.

“Alert” properties define alert notification,which includes change-of-state alerts andruntime (activeTime) alerts.

These two properties (listed at thebottom of the Alarm Setup tab)define alarm detection.

notificationClass,eventEnable, and notifyTypeapply to alarm notification.






BinaryInput

5–37

BI Alarm Detection

Several properties on the Alarm Setup tab determine whether an alarm condition is

detected by the BI object. In order of relative importance, these properties include:

• alarmValue —State at which the BI is considered “offnormal” (inAlarm),

providing that the alarmValueEnabled property is set to True. The object shapeand its statusOutput are red during this state.

• alarmValueEnabled —Determines if the BI is capable of an alarm condition.

The default is False (no alarming capability).


change occurs with the object. See “BI Alarm Delay” on page 5-38.

BI Alarm Notification

Alarming notification determines which type of alarm transitions are sent to the

Niagara alarming subsystem (Alarm Console). Events sent to the alarming subsystem

require user acknowledgment. Using the various recipient options for the target

notificationClass object, event notifications can also be routed to printers, e-mailaddresses, and APIs. If the BI object is exposed as a BACnet object,

BACnetRecipients can also be designated.



In the BI object, properties on the Alarm Setup tab relating to alarm notification are:



• eventEnable —Flags that determine which event transition types are sent tothe alarming subsystem (to-offnormal, to-fault, to-normal). The default is all


set flags as needed to receive alarm in the alarm console, route alarms, and so

on.













BinaryInput

5–38

BI Alarm Inhibi t



Note Whenever the statusInhibit input is linked , the object’s inhibitTime property shouldhold a defined value (not the default of 00:00:00 in Hr:Min:Sec).

Otherwise, the BI object will not be capable of alarming.



situations where a piece of equipment is turned off. For example, a dirty-filter switch

for an air handler may require alarm monitoring during unit operation (and only when

the unit is running), as shown in Figure 5-11.

In this particular example, an alarm-status change can occur only after the air handlerhas been running at least 30 seconds, as defined in the object’s inhibitTime. The

inhibit timer is reset whenever a state change at the statusInhibit input is received.

BI Alarm Delay





The alarm delay applies to both types of status transitions:

• “to-offnormal”, meaning normal (ok) to in_alarm.

• “to-normal”, meaning in_alarm to normal (ok).

The general intention of timeDelay is to prevent nuisance alarms caused by

momentary change in the received boolean value. Typically, when both an alarm

delay and alarm inhibit is used, the timeDelay is less (shorter) than the inhibitTime.

Whenever a logic false(inactive) is at the statusInhibit (sInh) input, the BI objectcannot change status to (orfrom) an alarm condition.



inhibitTime = 00:00:30

(30 seconds)






BinaryInput

5–39

BI AlertNotifications

In addition to (or instead of) alarming on a particular binary state, a BI object is also

capable of generating “alerts,” based upon configurable limits for runtime (elapsed

activeTime) and/or number of COS transitions (change of states). Alerts are sent to

the Niagara alarming subsystem (Alarm Console), and require acknowledgment.

Like alarms, alerts are associated with a specified notificationClass and can be routed

to various recipients.

BI object alert subtopics include:

• Alarm Setup Properties for Both Alert Types

• Change-of-State (COS) Alerts

• Runtime (Active Time) Alerts

Alarm Setup Propert ies for Both Alert Types

Alarm Setup properties that apply to both types of BI alerts (runtime and COS) are:

• alertNotificationClass —Must match a notificationClass object in the

notificationServices container. The default is 0, the same default for alarms.

• periodicAlerts —Determines whether runtime and COS alerts should repeat

upon each accrued interval of runtime or COS count. For example, if enabled

(True), and the COS count limit is defined at 150, a COS alert will be issued at

COS counts of 150, 300, 450, and so on. The default value is False.

• alertText —Any user-friendly text string wanted. Appears as a field in the alert

record for any runtime or COS alert, as a means of further description.

Change-of-State (COS) Alerts

Each state change at the BI’s statusInput increments the object’s COS counter by 1.

Assuming the object’s COS counter begins at 0, if the input changes from

inactive-to-active-to-inactive-to-active-to-inactive, the COS count will be 4. Thetotal number of active transitions (in this case, 2) is about half the current COS count.

The COS count is available as the Status property changeOfStateCount. It is also

available as the statusChangeOfStateCount output (using integerStatus data species).

The COS count is resettable (to 0) for any JDE user with Admin-level command

rights. Also, the COS count can be reset using a Command object linked to the

object’s resetChangeOfStateCountTrigger input, if needed.

Properties on the Alarm Setup tab that apply to COS alerts include:

• changeOfStateAlertLimit —Integer value that defines the COS count that

should result in an alert notification. If periodicAlerts is set to True, an alert is

generated at each multiple of this value.

Runtime (Active Time) Alerts

Each BI object automatically accumulates runtime, that is, elapsed active time. This

time is available formatted in Hr:Min:Sec as the Status property elapsedActiveTime.

Runtime is also available as an output, as an integer value in seconds (using an

integerStatusType data species).






BinaryInput

5–40

Runtime is resettable (to 0) for any JDE user with Admin-level command rights.

Runtime can also be reset using a Command object linked to the object’s

resetElapsedActiveTimeTrigger input, if needed.

Properties on the Alarm Setup tab that apply to runtime alerts include:

• activeTimeAlertLimit —Amount of runtime, in Hr:Min:Sec, that shouldresult in an alert notification. If periodicAlerts is set to True, an alert is


Examples Figure 5-30 shows several examples of BinaryInput objects in use.

Figure 5-12 BinaryInput usage examples.

The two BI objects at rightare used to format thereceived boolean values“true/false” to morerecognizable states, e.g:On/Off and Dirty/Clean.

The BI for the AHU filter isconfigured for alarming,including an alarm inhibit.

These BI objects at rightare also used to format“true/false” to morerecognizable states, e.g:Frost/No Frost andFlow/No Flow.

Both BI objects wereassigned a polarity of“reverse” (and at the sametime), had descriptors for

activeInactiveText flipped.This was done to invert theoutput states for use in“downstream” logic, notshown here.

BI objects are sometimesused to capture the logicresults of other controlobjects, such as Logic andComparison objects.

Unlike these other objects,a BI object can beconfigured to alarm. It canalso be exposed as a

BACnet object.

By default, a linked GxTextobject shows the BI’sactiveInactiveText text strings.

This BI providesalarm capability.The alarmValueis inactive, or“Frost,” due tothe assignedreverse polarity(output is “NOT”the input).

This BI object represents the logicresults of a number of Logic objects.

Its main purpose is for alarmingcapability. In this case, it provides a

preheat-coil pump alarm.






BinaryOutput

5–41

BinaryOutputQuick reference for all properties: Table A-11

abbrev: BO

BinaryOutput (BO) objects provide a

prioritized digital output signal to othercontrol logic. Typically, BOs provide on/off

control of a digital device.

The BO object collects runtime (elapsed

active time) and counts COS

(changes-of-state). Based upon configurable

limits, the object can be set to generate alerts

for both runtime levels and COS counts.

Trigger inputs allow the clearing of the COS

count and the runtime value. Trigger outputs

are available for each COS, COS alert,

runtime alert, and event.

As with Niagara AI, AO, and BI objects, you

can expose any BO object in the database as

a BACnet object.


container).



any link) to a BO object, commands at


from priorityArray links are momentarilycleared. The priorityArray input is now



output . This is an improvement over

previous releases, where a link change

might produce an output cycle until a linked

Schedule output updated.

Trigger Properties The BO object has the standard input property, executeTrigger , (typically not used)


• resetChangeOfStateCountTrigger —Any received trigger pulse clears theobject’s current count of COS (changes of states), resetting it to zero (0).






Inputs


Outputs

priorityArray

statusInput

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInhibit



priorityArray

statusInput


eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

presentValue

statusOutput

prioritizedOutput



Input / Output Property Reference for BO Object(only input and output types, see Table 5-10 for all properties)






pIn priorityArray BooleanPriorityArrayType


output eventTr eventTrigger TriggerTypesCnt statusChangeOfStateCount IntegerStatusType




elActAlr elapsedActiveTimeAlertTrigger TriggerType

present presentValue boolean

sOut statusOutput BooleanStatusType

pOut prioritizedOutput BooleanPriorityType

sFbOut statusFeedbackOutput BooleanStatusType






BinaryOutput

5–42






(“activeTimeAlertLimit” value has been reached, or a “multiple” of this valueif “periodicAlerts’ is set to True).

As needed, these trigger-type inputs and outputs can be linked to other objects that

have properties using TriggerType data species.

CommandsThe BO object provides a right-click command menu with these commands (default

command names are shown, these are modifiable using the commandTags property):

• Active —To set an active output at the Manual level (8).


• Inactive —To set an inactive value at the Manual level (8).


• Auto —To clear any active or inactive output at the Manual level (8).

• EmergencyActive —To set an active output at the Emergency level (1).


• EmergencyInactive —To set an inactive output at the Emergency level (1).


• EmergencyAuto —To clear any active or inactive output at the Emergency

level (1). Requires “Command, Emer” privileges.

For a JDE user with “Command, Admin” privileges, the following object commands






value to zero (0), clearing the COS count.


00:00:00 (Hr:Min:Sec), clearing the accumulated runtime.










BinaryOutput

5–43

PropertiesTable 5-10 BinaryOutput (BO) object properties.


S t a t u s

objectType,



on these properties common to all controlobjects.

— —

eventState,reliability,outOfService,ackedTransitionstoOffnormal,toFault,toNormal,presentValue


<cmd state> orauto,

levels 1 to 16

auto

1 to 16

presentValue isalways read-only.



null


integer value 0



null

elapsedActiveTime Read Only: Shows accumulated runtime(elapsed active time) in Hr:Min:Sec.

Time period upto 9999:99:99

00:00:00



null

P r i o r i t i e s


Read Only: Shows commands present oneach of the 16 priority level slots for thepriorityArray (pIn) input.

Active, Inactive,or auto,

levels 1 to 16

auto

1 to 16

relinquishDefault Read-Write: Defines the output state whenall 16 priority level slots have an “auto”.

Active, Inactive Inactive

inInterstartDelay Read Only: Indicates if an interstart delay iscurrently active (True) or not (False).

False, True False

C o n

f i g


normal,output

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear asa BACnet BinaryOutput object to otherBACnet devices. See “foreignAddress,” page 5-9, for more information.

0 to 4194302

or -1(not exposed)

-1 Must be a uniquenumber among allBinaryOutputobjects in station.


polarity Read-Write: Determines if the same

boolean state at the statusInput is reflectedat the statusOutput (normal), or if the outputremains opposite from the input (reverse).


minimumOnTime Read-Write: Upon a command frominactive to active, results in an activecommand stored at the Minimum On Offpriority level (6) for this time (Hr:Min:Sec).

Any practicaltime needed.

00:00:00






BinaryOutput

5–44

C o n

f i g ,

c o n

t .

minimumOffTime Read-Write: Upon a command from activeto inactive, results in an inactive commandstored at the Minimum On Off priority level

(6) for this duration (Hr:Min:Sec).


00:00:00

restartDisable Read-Write: Determines whether the outputis automatically restarted following a stationrestart (reboot) or power failure. If set toTrue, an inactive at manual level (8) isissued following such an occurrence.

False, True False

interstartDelayTime Read-Write: Defines the time period theoutput is held inactive following an activecommand. Used to prevent multiplesimultaneous starts. Applies to commandsat all priority levels except Emergency (1).


00:00:00 Applied alsofollowing a stationrestart.

A l a r m

S e t u p



— — * See specificdetails oninhibitTime, thenext property.


The inhibitTime is triggered by a transitionat the statusInhibit input.

• When statusInhibit goes false-to-true,alarm processing is delayed for the inhibit

time.• When statusInhibit goes true-to-false,

alarm processing is delayed for three

times the inhibit time.


Hr:Min:Sec


A minimum value of1 second(00:00:01) isrecommendedwhenever thestatusInhibit input islinked.

Alarm processingcompares the

statusInput(feedback) value tothe priorityArray(command) value.


Positive integer 0


Any value up to9999:59:99

(Hr:Min:Sec)

00:00:00



number should exist in theNotificationService object’s container.

0 to 8388607 0


False, True False

Table 5-10 BinaryOutput (BO) object properties. (continued)







BinaryOutput

5–45

A l a r m

S e

t u p ,

c o n

t . alertText Read-Write: Text descriptor included ineither a COS count alert or runtime alert.




characters.

-(hyphen)


V i s u a

l



Read-Write: Defines the displayed states atthe statusInput, statusOutput, andpresentValue, and also how they appear onthe object’s property sheet.


Active,Inactive

States can displayat a linked GxTextobject.

commandTags Read-Write: Defines the labels used to listcommands that appear on the right-clickcommand menu.

Default text values for commandTags are:

• Active (manualActive)• Inactive (manualInactive)

• Auto (manualAuto)

• EmergencyActive (emergencyActive)

• EmergencyInactive (emergencyInactive)

• EmergencyAuto (emergencyAuto)

Any desired textstring, including

spaces andnumerals.

Seedescrip.


E n g

i n e e r i n g



— —

statusInhibit

(input sInh)

Read Only: Shows the current booleanstate and status of the statusInhibit input.


false : ok


(output sCnt)

Read Only: Shows the current value andstatus of the COS count.

Available as a IntegerStatusType output.


0 : ok


(output sElpT)

Read Only: Shows the current runtime(elapsed active time), totaled in seconds.



0 : ok

statusInput

(input sIn)


Inactive, Activestatus flags

Inactive :ok

statusOutput

(output sOut)



Inactive :ok

prioritizedOutput

(output pOut)

Read Only: Shows the current state andpriority level of the prioritizedOutput.

Inactive, Active@ <pri. level>

Inactive :@ def


(output sFbOut)

Read Only: Shows the current state andstatus of the feedback value being suppliedon the statusInput.


Inactive :ok



General,

7 others

General

Table 5-10 BinaryOutput (BO) object properties. (continued)







BinaryOutput

5–46

BinaryOutput NotesThe BO object is typically used for control of two-state device or mode of operation.

In some cases, a BO object is used to directly control a physical binary output of a

remote device, represented by a shadow object.

The following sections provide various notes on BO objects:• Priority Levels

• Routinely Configured BO Properties

• Control Related Properties

• BO Command Tags

• BO Alarming Functions

• Examples

Priority Levels The priorityArray input of a BO object can be linked to the “prioritizedOutput” of

multiple objects. Compatible object types include the BinaryOverride, Comparison,

Logic, Schedule, as well as other BO objects. Default priority levels for these objectsis typically level 8 (manual), however, it is 16 (schedule) for the Schedule object.

In addition to these types, Program objects (that have a boolean prioritized output)

can be linked, including many in the standard tridiumx library (lib). For example,

under the “hvac” folder of the tridiumx “lib” JAR are several applicable Program

objects. Included are an EDL (electric demand limiting) “ShedControl” object, and a

“OptimizedStartStop” object. By default, prioritizedOutputs of these objects work at

levels 9 (demand limiting) and 12,13 (stop, start optimization), respectively.

Typically for these objects, the priority level of its prioritizedOutput can be modified

from the default level, using the Config property priorityForWriting.

How Levels Are EvaluatedThe 16 different priority levels are evaluated upon each object execution cycle. The

highest priority is 1 (manual life safety); the lowest is 16 (schedule). Levels function

as priority “slots,” where commands “pushed” by the execution of linked object(s)

are stored, and then evaluated upon each execution cycle. The highest level with an

“active” or “inactive” (not “auto”) controls the BO object. In the case where all 16

levels are “auto,” the BO assumes the configured “relinquishDefault” state.

The “read slot” technique differs from the normal “pull input data” technique of an

object when it executes. This helps to explain what happens when the priorityArray

is linked to multiple controlling outputs, and the same priority level is used. In this

case, the duplicated level operates at the last received state (active or inactive), with

the strong probability of “control contention” (think chattering).

Notes • When linking multiple objects to the priorityArray input, it is recommended to

source from only one object per specific priority level (to prevent contention).

• A Schedule object has a fixed execution frequency of once each minute. If

linked to a BO, it updates a priority level (slot) only at the top of each minute.






BinaryOutput

5–47

RoutinelyConfigured BOProperties

The three most typically configured properties for a BO object are:

• relinquishDefault (Priorities tab)—Defines the BO object’s output state when

all 16 of the priority-level slots at the priorityArray input have an “auto.”

The default value is inactive.

• activeInactiveText (Visual tab)—Defines the display descriptors used for theobject’s boolean states (active and inactive). Assigned descriptors appear in

linked GxText objects and in the accumulated data of a linked BinaryLog.

• commandTags (Visual tab)—Defines how user commands appear on the

object’s right-click command menu. See “BO Command Tags” on page 5-48.



Control RelatedProperties

The BO object includes several Config properties that directly determine the control

operation of its main outputs (prioritizedOutput and statusOutput).

• polarity —The default is normal. If set to reverse, this flips control such thatan inactive at the control (priorityArray) input (or from a right-click command)

produces an active at the object’s outputs, and vice-versa. Note that the

statusInput input, if used (for alarming), is then “out-of-phase” with control.

• minimumOnTime —Defines the time period in which an active command at

the “Minimum On Off” priority level (6) will exist, as a result of any command

transition from inactive to active. This can prevent equipment short-cycling.

• minimumOffTime —Defines the time period in which an inactive command

at the “Minimum On Off” priority level (6) will exist, as a result of any

command transition from active to inactive. This can prevent equipment

short-cycling.

• restartDisable —Determines how outputs are set following a station restart,host reboot, or power failure. Settings False and True are as follows:

– False (the default), restores outputs automatically to the previous state

(active or inactive).

– If set to True, outputs are set to inactive at the “Manual” level (8).

• interstartDelayTime —Defines a delay period, in seconds, before an active

command becomes effective. Does not apply with a command to inactive.

Applies to all priority levels except Emergency Manual (1). The default value

of zero (0) means no delay time.

You can use this property to prevent multiple simultaneous starts to

BO-controlled loads, which might otherwise cause energy (demand) spikes.

Note There is no “central” interstart delay timer in a Niagara station. This means you

should specify different interstartDelayTimes for each BO (or group of BOs)

included in an interstart delay sequence. For example, assign the first BO a delay

time of 0, second BO a delay time of 3, third BO a delay time of 6, and so forth.

Different times cause “to-active” states to be staggered when multiple BOs receive

a simultaneous active, for instance, from a linked Schedule (or a station restart).






BinaryOutput

5–48

BO CommandTags

It is typical for BO objects to be configured with custom command “labels,” using

the commandTags property, located on the Visual tab of the object’s property sheet.


right-click menu than the default values, for example, “Start AHU-1” vs. “Active.”

In addition, you can clear any tags to make those commands unavailable

(Figure 5-13). This is often done for emergency-level commands, for example.

BO AlarmingFunctions Alarm detection for a BO object requires a separate link to a statusFeedback input,which receives the “actual” boolean value of the controlled device. This state is

compared against the current “controlled/commanded” state, and can result in an

alarm (if the two states are different). See Figure 5-14.

The following subtopics apply to BO alarming:

• BO Alarm Inhibit

• BO Alarm Delay

• BO Alarm Notification







BinaryOutput

5–49

Typically, another input is linked as well: statusInhibit (sInh), coming from the

controlling source. See the “BO Alarm Inhibit” section on page 5-50.

Note The BO object can also generate “alerts” based on configurable limits for runtime

(elapsed active time) and change-of-state transitions. BO alert functions operate the

same as for BinaryInput (BI) objects. See “BI Alert Notifications” on page 5-39.

Figure 5-15 shows the grouping of Alarm Setup properties for a BO object.

Figure 5-15 BO objects have alarming functions with BACnet-type properties.

Figure 5-14 BinaryOutput alarming.

Assuming “normal” polarity,a BO alarm condition is

when the control commandis not the same as the stateat the statusInput input(feedback).

BO alarm condition occurs whenstatusInput (sIn) differs fromcontrol/command state.

Feedback signal linkedto statusInput (sIn)

An alarm condition can occur at both

active and inactive control states.

inhibitTime and eventTriggerEnable areNiagara-only properties. See “BO Alarm Inhibit”.


timeDelay specifies an alarm delay period forany sensed alarm condition.







BinaryOutput

5–50

BO Alarm Inhibit




BO Alarm Delay



continuous period equal to or greater than defined in the timeDelay property, beforean alarm status change occurs.







BO Alarm Notification

Alarming notification determines which type of alarm transitions (events) are sent to


subsystem require user acknowledgment. Using the various recipient options for the

target notificationClass object, event notifications can also be routed to printers,

e-mail addresses, and APIs. If the BO object is exposed as a BACnet object,


Figure 5-16 BinaryOutput statusInhibit input and inhibitTime property.

The statusInhibit input istypically linked to the samesource that is controllingthe BO (linked to thepriorityArray input).

When the BO iscommanded to active, anyalarm status change isinhibited for the specified

inhibitTime, in seconds.

When commanded toinactive, any alarm statuschange is inhibited for 3

times the inhibitTime, inseconds. This extendedperiod can be considered“wind-down” time.

statusInhibit (sInh) link

priorityArray input linkfor control command


Example:inhibitTime = 30 (seconds)

When under schedule control,and going from active toinactive (On to Off), the alarminhibit delay will be 90 seconds.






BinaryOutput

5–51



In the BO object, properties on the Alarm Setup tab relating to alarm notification are:



• eventEnable —Flags that determine which event transition types are sent to

the alarming subsystem (to-offnormal, to-fault, to-normal). The default is all



on.




client’s “GetAlarmSummary” request, the station reports “BACnet-exposedobjects” currently in alarm only if their notifyType properties are set to alarm.



Examples Figure 5-17 shows several examples of BinaryOutput objects in use.

Figure 5-17 BinaryOutput object examples.

The BO objects at rightprovide commandableaccess to occupancymodes for an air handlerand VAV boxes.

Upstream, a Logic object(AND function) providesoverride-OFF control frompump safeties.

This BO object has itsruntime output (sElpT)linked to a Program objectwritten to perform alead/lag rotation. An outputof the Program objectclears the BO’s runtime

when its rotation isselected.






BinaryOverride

5–52

BinaryOverrideQuick reference for all properties: Table A-12

abbrev: BOvrd

A BinaryOverride (BOvrd) object provides a

prioritized digital output signal that iscontrolled from a right-click command menu.


(either active or inactive) for a specified

duration, and canceling an override.


configurable to any level (from 1 to 16). In

addition, text descriptors for the active and

inactive states are editable. This allows the

right-click command menu to show

commands as needed, for example, “override

On” and “override Off” instead of “override

Active” and “override Inactive.”


container).


Trigger Properties The BOvrd object has the standard input property, executeTrigger , (typically not


• overrideTrigger —Any received trigger pulse starts an override, at the

configured overrideValue (state), overrideTime, and priorityForWriting.


example, a Command object. This would allow a user to start an override at the

configured overrideValue (state), but not to the opposite state. The linked Command

object would also not allow a user to cancel an override, or change its duration. An

override would be started each time a trigger pulse is received at this input.

CommandsFor any user with “Command, Std” privileges, a BOvrd object has a right-click

command menu that provides these commands (default state descriptors shown):

• override Active —Start an override to Active, specifying a duration in

minutes.

• override Inactive —Start an override to Inactive, specifying a duration in

minutes.


Inputs


Outputs


prioritizedOutput

Inputs


Outputs

executeTrigger

overrideTrigger

inOverride

statusInOverride

prioritizedOutput

Input / Output Property Reference(only input and output types, see Table 5-11 for all properties)


input exe executeTrigger TriggerTypeoverride overrideTrigger TriggerType



pOut priori tizedOutput BooleanPriori tyType






BinaryOverride

5–53

PropertiesTable 5-11 BinaryOverride (BOvrd) object properties.


S t a t u s

objectType,




— —



False, True False boolean data species.

C o n

f i g


normal,input

foreignAddress Read-Write: Does not apply to this object. -1 -1 Leave at default.




Any prioritylevel,

from 1 to 16

ManualOperator

(8)



This property is most important when usingthe input “overrideTrigger.”


up to 32-bitlimit.

60 If using the object’sright-click commandmenu, this propertyvalue is displayed(and can be adjusted)each time an overrideis issued.

overrideValue Read-Write: Stores the last given overridestate (True for active, False for inactive).The override was issued at the level definedin the priorityForWriting property.

When the override expires or is canceled,the output state expires (level is auto’ed).

Note: Any pulse received at theoverrideTrigger input causes an override atthis state: True (active) or False (inactive).

True, False False If using the object’sright-click commandmenu, this overridevalue (state) isselectable. Theselected state isstored in this property.

V i s u a

l

position Read-Write: See “position,” page 5-9. — — —


Read-Write: Defines the override commandarguments that appear on the object’sright-click command menu. For instance:“override On” or “override Off.”

Default values are:

• Active (active), shows as “override Active”

• Inactive (inactive) shows as “overrideInactive”

Any desiredtext string todescribe the

override state.

Seedescrip.

Blank properties (nocharacters) result incommands that saysimply “override”. Youshould use textdescriptors that makesense to the system

users.

E n g

i n e e r i n g



— —

statusInOverride(input sInOv)

Read Only: Shows if an override is activeand also the status of the object.

Available as a default object output.

Inactive,Active

status flags

Inactive :ok

booleanStatusTypedata species






BinaryOverride

5–54

BinaryOverride NotesThere are two basic ways to use an BinaryOverride object:



Directly Available The right-click menu for a BinaryOverride object provides the user a list of


• Start an override, either active or inactive, specifying the duration in minutes.


Changes to the override duration, if any, are stored in the object’s overrideTime

property. This value becomes the default duration for the next command, and is seen

when the command’s popup control appears (Figure 5-18).

In addition, the last override command (Active or Inactive) is also stored in the

object’s overrideValue property. Be aware that an override from the overrideTriggerinput is always an override to this stored state.

E n g

i n e e r i n g ,

c o n

t . prioritizedOutput(input pOut)

Read Only: Shows the state and prioritylevel currently on the prioritizedOutput.


Inactive,Active

@ <pri. level>

Inactive :@ def

booleanPriorityTypedata species



General,

7 others

General

Table 5-11 BinaryOverride (BOvrd) object properties. (continued)


Figure 5-18 An override active or inactive shows the override duration (and allows changing this stored value).

Popup controlfor right-clickoverridecommandwhen usingthe JDE.

Popup control

for right-clickoverridecommandwhen using aWeb browser .






BinaryOverride

5–55


In some scenarios, direct access to an BinaryOverride object may provide too much

user control for changing override parameters (duration time or the override state).

In this case, linking a Command object to the object’s overrideTrigger may be better.


directly to the BinaryOverride object). This allows the initiation of an override (to the

state stored in the overrideValue property) but no other control—including canceling

an override. The outputTrigger text property of the Command object should be given

a descriptive label for the configured override action (Figure 5-19).


remaining override time. Two links are required to the BinaryOverride object.

Figure 5-20 RemainingOverrideTime object in Local Library (tridiumx/lib/programs/hvac) used with BinaryOverride.

Figure 5-19 Control from a linked Command object allows override initiation only.



Popup right-clickcommand tolinked Commandobject, seen froma Web browser .

Popup right-clickcommand tolinked Commandobject, seen fromthe JDE.




Two links are required between theBinaryOverride object and the Programobject (RemainingOverrideTime):









Command

5–56

CommandQuick reference for all properties: Table A-15

abbrev: Cmd

A Command (Cmd) object provides up to 4

separate trigger outputs that are fired from aright-click command menu. Each trigger has

an editable label for the associated command.

A Cmd object can be linked to other objects

with specialized trigger-type inputs to

provide specific user commands. Typical

examples include the “doArchive” and

“doClear” trigger inputs on log-type objects.

The Cmd object has no linkable input and few

internal properties (no config properties).

Other trigger-type objects include the

DateTimeTrigger and PeriodicTrigger .


container).


CommandsBy default, a newly created Cmd object has no right-click command menu until you

enter text values in the properties outputTriggerTextA through D. Each of these

properties holds the command label that appears on the pop-up menu. You can use

any alphanumeric characters needed, including spaces and mixed case characters.

For a user with “Command, Std” privileges, any non-blank trigger command is

available on the right-click command menu. When a menu selection is made, the

associated trigger output fires.

Properties

Inputs


Outputs


prioritizedOutput

Inputs


Outputs

(none)outputTriggerA

outputTriggerB

outputTriggerC

outputTriggerD



input — — —

output outA outputTriggerA TriggerType

outB outputTriggerB TriggerType

outC outputTriggerC TriggerType

outD outputTriggerD TriggerType

Table 5-12 Command (Cmd) object properties.



statusFlagsSee Table 5-3 on page 5-8 for informationon these common object properties.

— —

V i s u a

l


outputTriggerTextA,outputTriggerTextB,

outputTriggerTextC,

outputTriggerTextD

Read-Write: Defines how (and if)commands appear on the object’s right-clickcommand menu.

By default, output trigger text properties areblank. Until you enter one or more textvalues, no trigger commands are available.

Any desired textstring to describethe trigger

resulting from thecommand.

(none)



General,

7 others

General






Command

5–57

Command NotesThe Command object provides a right-click command menu containing up to four

command selections, each of which fires one of four trigger outputs. Each trigger

command has an editable label.

Examples Figure 5-30 shows an example of a Command objects in use. Other Command object

examples appear in Figure 5-8 and Figure 5-19.

Notes • Trigger-type links are unique in that “many-to-one” links are permitted as well

as the more typical “one-to-many.” This means, for example, that you can link

a Command object to an object’s trigger input that is already linked, say, to aDateTimeTrigger object and/or a PeriodicTrigger object.

• Although the Services container has no Workspace view, the AuditLogService

and ErrorLogService are represented by objects with 2 trigger inputs, namely,

“doArchive” and “doClear”. The LogService also has 2 trigger inputs, namely,

“doArchiveAllTrigger” and “doClearLastArchive.” You can use Tree View to

link Command object outputs (or trigger-type outputs of other objects) to

provide user-accessible commands to these services, as needed.

Figure 5-21 Command object examples.

This Command object islinked to a BO object andprovides a menu to clearthe BO’s COS count andruntime (elapsed activetime). Typically, such anobject would be assignedonly to select securityGroups.

Command descriptions areconfigured on the object’sproperty sheet, (Visualtab).

Any property left blankdoes not appear on theobject’s command menu.

Right-click command menu.Each command results in atrigger pulse from theCommand object.

Command objectwith 2 availablecommands.






Comparison

5–58

ComparisonQuick reference for all properties: Table A-16

abbrev: (reflects function, e.g. A > B)

Comparison objects allow you to compare

two analog inputs and produce a digitalresult, both as a status type and a prioritized

type output. You can configure a Comparison

object to perform one of the following

functions:

• A > B (greater than)

• A < B (less than)

• A >= B (greater than or equal to)

• A <= B (less than or equal to)

• A = B (equal to)

• A != B (not equal to)The prioritizedOutput level is configurable to

any priority level (1 to 16).


container).


Trigger Properties None, apart from the standard input property, executeTrigger . In certain applications,

this input may be used (with executionParameters, frequency, set to on_trigger).

Commands None.

Properties

Inputs


Outputs

statusInputA

statusInputB

prioritizedOutput

statusOutput

Inputs


Outputs

executeTrigger

statusInputA

statusInputB

prioritizedOutput

statusOutput

presentValue

Property Quick Reference for Comparison Object(only input and output types, see Table 5-13 for all properties)

Type Label Property Name Data Speciesinput exe executeTrigger TriggerType

sInA controlledVariable FloatStatusType

sInB setpoint FloatStatusType

output pOut prioritizedOutput BooleanPr iorityType



Table 5-13 Comparison object properties.


S t a t u s

objectType,statusFlags,description,presentValue



outOfService,reliability

See Table 5-5 on page 5-13 for informationon these properties.

— —

C o n

f i g

executeParameters Read-Write: The object’s execution frequency and order. Formore details, see “execution Parameters,” page 5-9. normal,processor



defaultA Read-Write: Acts as a constant value usedfor statusInputA, when that input is notlinked (or if its value has a status “fault”).

valid float 0.0






Comparison

5–59

Comparison NotesThe Comparison object performs a simple math comparison on the float values at

statusInputA and B, and sets the boolean prioritizedOutput and statusOutput

according to its configured function. If an input is not linked, or its received status is

in a “fault” state, the object uses the corresponding defaultA or defaultB config

property value.

C o n

f i g ,

c o n

t . defaultB Read-Write: Acts as a constant value usedfor statusInputB, when that input is notlinked (or if its value has a status “fault”).

valid float 0.0

C o n

f i g ,

c o n

t .

function Read-Write: Defines the comparisonfunction of the object. The selected functionshows in the object’s shape.

A > BA < B

A >= BA <= BA = BA != B

A > B

priorityForWriting Read-Write: Defines the priority level usedat the prioritizedOutput.

1 to 16 16(Schedule)

trueCommand Read-Write: Determines the output stateproduced upon a true comparison.

Auto applies only to the prioritizedOutput.

true,false,auto

auto

falseCommand Read-Write: Determines the output stateproduced upon a false comparison.

Auto applies only to the prioritizedOutput.

true,false,auto

auto

V i s u a

l


decimalFormat Read-Write: Sets decimal position from 0 to6 places, and optionally force (+) sign forpositive values.

0 to 6,


2,

no (+) sign


Read-Write: Defines the displayed states atthe statusOutput and presentValue, andalso how they appear on the object’sproperty sheet.


true<active>,

false<inactive>


E n g

i n e e r i n g

minExecuteTime,

maxExecuteTime,averageExecuteTime,userData

Properties common to all control objects.

For more information, see Table 5-3 onpage 5-8.

— —

statusInputA(input sInA)

Read Only: Shows the current analog valueand status at the statusInputA input.

statusInputB(input sInB)

Read Only: Shows the current analog valueand status at the statusInputB input.





S e

c u r i t y securityGroups Read-Write: Shows the security groups to



General,

7 others

General

Table 5-13 Comparison object properties. (continued)







Comparison

5–60

Examples Figure 5-22 shows two Comparison objects used to evaluate a space temperature

value against cooling and heating setpoints. Outputs of the Comparison objects feed

a Logic object, which produces a “Setpoint OK” true or false boolean state.

Figure 5-22 Comparison objects used to compare space temperature against setpoints.

LonWorks Conversion

Figure 5-23 shows Comparison objects linked to a SnvtHvacStatusDemux object that

demuxes different fields in SNVT_hvac_status to various outputs. Five of the outputs

are FloatStatusTypes, and read either “0.0” (for Off) or “100.0” (for On). When

linked to Comparison objects, outputs are converted to boolean values that are better

suited for display and logging (as well as a control logic use downstream).

Note In this case, Comparison objects are better suited than equivalent Program objects, because each uses less resource counts (approximately 56 versus 80 or more).

Figure 5-23 Comparison objects used to convert data types.

Comparison objects

Boolean outputs to aLogic object

For this application, theseComparison objects can beleft at default Config settings.By linking to the sInA input,any input value over 0.0 (thedefault sInB value) results inan “Active” state.

The only properties editedfrom default settings were theVisual “activeInactiveText”properties. In this case, theactive text is simply “On” andthe inactive text is “Off.”






CpAnalogNode

5–61

CpAnalogNodeQuick reference for all properties: Table A-20

abbrev: CpAnalog

(Found in the tridium JAR, control folder.)

A CpAnalogNode object, if linked to aninternal property ( float data species) of

another object, provides a user (right-click)

command access to change that property

value. This allows a browser user to have

write access to a specific internal object

property. Otherwise, a user must use the JDE

to access the target object’s property sheet.

The CpAnalogNode also provides a

minimum and maximum limit for a user

command change to the linked property, as

well as an editable command (menu).

Typical usage is for user-access to a property

such as “lowLimit” or “highLimit” (alarm

limits) etc. It is one four “command property”

object types—others are the CpBinaryNode,

CpIntegerNode, and CpStringNode.

Parent Dependencies None (any container). Requires Niagara Release 2.3 or later.


Trigger Properties None, apart from the standard input property, executeTrigger (typically not used).

CommandsBy default, a newly-created CpAnalogNode object has no right-click command menu

until you enter text in the commandText property (Visual tab).

For a user with “Command, Std” privileges, this command appears on the right-click

menu. Only values between the maxValue and minValue (inclusive) are accepted.

Properties

Inputs


Outputs

cmdLink (none)

InputsAll Inputs / Outputs

Outputs

executeTrigger

cmdLinkvalue

Property Quick Reference for CpAnalogNode Object(only input and output types, see Table 5-14 for all properties)



cmdLnk cmdLink float

output value value float

Note: This object is nearly identical to the AnalogCmd object, whichis included in the lonworks JAR (conversion folder). However, theCpAnalogNode object is a core (tridium) object, and so can be used inany Niagara station, without regard to module dependecies.

Table 5-14 CpAnalogNode object properties.


S t a t u s

objectType,

statusFlags,description,


on these common object properties.

— —

cmdLink(input: cmdLink)

Read-Only: Current (float) value of thelinked (target) property, as on the input.

valid float 0.0

value(output: value)

Read-Only: Current (float) value of thelinked (target) property, as on the output.

Link a Gx object to the value output toprovide command access from a GxPage.

valid float 0.0 At all times equal tothe cmdLink value.






CpAnalogNode

5–62

CpAnalogNode NotesThe CpAnalogNode is used to provide read/write-access to an internal property

(Config, Alarm Setup, etc.) of any Niagara object. The linked (target) property must

be read-write and use the float data species.

Among the four Cp (control property) objects, the CpAnalog may be the most useful.

A typical application is to expose alarm limits for an AI or Loop object, as shown in

Figure 5-24.

Notes • No “range check” of a linked (target) property is performed. Therefore, you

must set reasonable limits (maxValue, minValue) according to the property you

are exposing.

• Cp objects are intended for occasional use, and should not be added to

applications indiscriminately.

• A change to a property made through a Cp object is recorded by the

AuditLogService exactly as if made from a property sheet in the JDE.

C o n

f i g

executionParameters Read-Write: The object’s execution frequency and order. Formore details, see “execution Parameters,” page 5-9.

normal,processor


maxValue Read-Write: Maximum value a user cancommand the linked (float) property to.

Set to a higher value than the minValue.

valid float 0.0 Default values are not

usable (only 0.0).

Max and min limitsaffect access onlyfrom this object (notnormal property sheetaccess).

minValue Read-Write: Minimum value a user cancommand the linked (float) property to.

Set to a lower value than the maxValue.

valid float 0.0

V i s u a

l


commandText Read-Write: Defines how (and if) thecommand appears on the object’s right-clickcommand menu.

By default, this property is blank—you mustenter text to provide a user command.

Any desiredtext string forthe commandto change alinked prop.

(none)

decimalFormat Read-Write: Sets decimal position of theoutput from 0 to 6 places, and optionallyforce (+) sign for positive values.

0 to 6,

(+) sign,no (+) sign

2,

no (+) sign

E n g

i n e e r i n g minExecuteTime,


See Table 5-3 on page 5-8 for informationon these common object properties.

— —



General,

7 others

General

Table 5-14 CpAnalogNode object properties. (continued)







CpAnalogNode

5–63

CpAnalogNodeExample

Figure 5-24 shows two CpAnalogNode objects used to expose the high and low

alarm limits for an AI object.

Figure 5-24 CpAnalogNode objects used to provide highLimit and lowLimit access.

By linking the value output of each CpAnalogNode to a Gx object on a GxPage, the

internal property of the linked object can be changed by a browser user (Figure 5-25).

Further, changes must be made within the range of the maxValue and minValue, as

defined in each respective CpAnalogNode.

Figure 5-25 Browser user can view and modify the internal high and low alarm limits.

objectName: LoAlarmLimitRATmaxValue: 65.0minValue: 60.0commandText: Change RA temp Low Alarm limitdecimalFormat, precision: 1

The top CpAnalogNode’s“cmdLink” input is linked tothe “highLimit” property of theAI object.

The second CpAnalogNode’s“cmdLink” input is linked tothe “lowLimit” property of theAI object.

Links shown here between Cp objects and the AI object appearunusual, as there is no “output.” Conceptually, the cmdLink inputfunctions as an output, however, it is only for user commands fromthe Cp object (no direct linkage to other control logic).

objectName: HiAlarmLimitRAT

maxValue: 85.0minValue: 75.0commandText: Change RA temp High Alarm limitdecimalFormat, precision: 1

Right-click command shows thecommandText string.

Selecting the command

produces an entry box.

In this example, two GxTextobjects are used to show thehigh alarm and low alarm limits.

Each GxText is linked to aCpAnalogNode object.






CpBinaryNode

5–64

CpBinaryNodeQuick reference for all properties: Table A-21

abbrev: CpBinary


A CpBinaryNode object, if linked to aninternal property (boolean data species) of

another object, provides a user (right-click)

command access to change (toggle) that

property value. This allows a browser user to

have write access to a specific internal object

property. Otherwise, a user must use the JDE

to access the target object’s property sheet.

The CpBinaryNode provides state

descriptors (activeInactiveText), as well as an

editable command (menu).

Typical usage is for user-access to a propertysuch as “periodicAlerts” or “stopWhenFull.”

It is one four “command property” object

types—others are the CpAnalogNode,

CpIntegerNode, and CpStringNode.




Commands By default, a newly-created CpBinaryNode object has no right-click command menu



menu. A selection-box in the menu popup allows toggling the current property value.

Properties

Inputs


Outputs

cmdLink (none)

Inputs

All Inputs / OutputsOutputs

executeTrigger

cmdLinkvalue

Property Quick Reference for CpBinaryNode Object(only input and output types, see Table 5-15 for all properties)



cmdLnk cmdLink boolean

output value value boolean

Note: This object is nearly identical to the N2BinaryCmd object,previously included in a johnson2 JAR. However, the CpBinaryNodeobject is a core (tridium) object, and so can be used in any Niagarastation, without regard to module dependecies.

Table 5-15 CpBinaryNode object properties.


S t a t u s

objectType,statusFlags,

description,


— —


Read-Only: Current (boolean) value of thelinked (target) property, as on the input.

Inactive,Active

Inactive


Read-Only: Current (boolean) value of thelinked (target) property, as on the output.


Inactive,Active

Inactive At all times equal tothe cmdLink value.

Displays using theactiveInactiveTextdescriptors.






CpBinaryNode

5–65

CpBinaryNode NotesThe CpBinaryNode is used to provide read/write-access to an internal property


be read-write and use a boolean data species.

Example Figure 5-26 shows a CpBinaryNode object used to toggle periodicAlerts for a BO.

Figure 5-26 CpBinaryNode object used to expose periodicAlerts for a BinaryOutput object.

See the “CpAnalogNode Example,” page 5-63, for another Cp object application.

C o n

f i g executionParameters Read-Write: The object’s execution frequency and order. Formore details, see “execution Parameters,” page 5-9.

normal,processor


V i s u a

l





(none)

activeInactiveText Read-Write: Defines how the linkedproperty’s value displays (value output).

Note: A browser user sees only “false” and“true” in the command selection box (pop-upfrom the object’s right-click command menu,see Figure 5-26 below).


Active,Inactive

State descriptors candisplay at a linkedGxText object.

E n g




— —



General,

7 others

General

Table 5-15 CpBinaryNode object properties. (continued)


Note that the drop-down controlin the popup command boxalways lists “true” and “false.”

value output islinked to aGxText object.

objectName: PeriodicAlertsSF(linked to BO’s periodicAlerts)commandText: Periodic Alerts?activeInactiveText:

active:Yesinactive:No






CpIntegerNode

5–66

CpIntegerNodeQuick reference for all properties: Table A-22

abbrev: CpInteger


A CpIntegerNode object, if linked to aninternal property (int data species) of another

object, provides user (right-click) command

access to change that property value. This

allows a browser user to have write access to

a specific internal object property. Otherwise,

a user must use typically use the JDE to

access the target object’s property sheet.

The CpIntegerNode also provides a

minimum and maximum limit for a user

command change to the linked property, as

well as an editable command (menu).

Typical usage is for access to integer values

such as changeOfStateAlertLimit, or (log)

interval etc. It is one four “command

property” object types—others are the

CpAnalogNode, CpBinaryNode, and

CpStringNode.




CommandsBy default, a newly-created CpIntegerNode object has no right-click command menu



menu. Only values between the maxValue and minValue (inclusive) are accepted.

Properties

Inputs


Outputs

cmdLink (none)

Inputs


Outputs

executeTrigger

cmdLinkvalue

Property Quick Reference for CpIntegerNode Object(only input and output types, see Table 5-16 for all properties)



cmdLnk cmdLink int

output value value int

Note: This object is nearly identical to the N2IntegerCmd object,previously included in a johnsonn2 JAR. However, the CpIntegerNodeobject is a core (tridium) object, and so can be used in any Niagarastation, without regard to module dependecies.

Table 5-16 CpIntegerNode object properties.


S t a t u s

objectType,statusFlags,description,


— —


Read-Only: Current (integer) value of thelinked (target) property, as on the input.

valid integer 0


Read-Only: Current (integer) value of thelinked (target) property, as on the output.


valid integer 0 At all times equal tothe cmdLink value.






CpIntegerNode

5–67

CpIntegerNode NotesThe CpIntegerNode is used to provide read/write-access to an internal property


be read-write and use the int (integer) data species.

Note No “range check” of a linked (target) property is performed. Therefore, you must set

reasonable limits (maxValue, minValue) according to the exposed property.

Example Figure 5-27 shows a CpIntegerNode that exposes a BO’s changeOfStateAlertLimit.

Figure 5-27 CpIntegerNode used to expose changeOfStateAlertLimit property for a BinaryOutput object.

C o n

f i g


normal,processor


maxValue Read-Write: Maximum value a user cancommand the linked (integer) property to.

Set to a higher value than the minValue.

valid float 0 Default values are not

usable (only 0).

Max and min limitsaffect access onlyfrom this object (notnormal property sheetaccess).

minValue Read-Write: Minimum value a user cancommand the linked (integer) property to.

Set to a lower value than the maxValue.

valid float 0

V i s u a

l





(none)

E n g




— —



General,

7 others

General

Table 5-16 CpIntegerNode object properties. (continued)



objectName: COSlimitSF(linked to BO’s changeOfStateAlertLimit)maxValue: 200minValue: 50

commandText: Change COS Limit

Right-clickcommandshows thecommandText.

Selecting the command produces an entrybox. A user can review/modify thechangeOfStateAlertLimit in the target BO.

http://-/?-

http://-/?-






CpStringNode

5–68

CpStringNodeQuick reference for all properties: Table A-23

abbrev: CpString


A CpStringNode object, if linked to aninternal text property (string type) of another

object, provides user (right-click) command

access to change that property’s text value.

This allows a browser user to have write

access to a specific internal object property.

Otherwise, a user must use typically use the

JDE to access the target object’s property

sheet. The CpStringNode also provides an

editable command (menu).

It can provide user access to properties such

as description, alarmText, or other string

types. It is one four “command property”

object types—others are the CpAnalogNode,

CpBinaryNode, and CpIntegerNode.

Parent Dependencies None (any container). Requires Niagara Release 2.3.5 or later.



CommandsBy default, a newly-created CpStringNode object has no right-click command menu


For a user with “Command, Std” privileges, this command appears on the object’s

right-click menu.

Properties

Inputs


Outputs

cmdLink (none)

Inputs


Outputs

executeTrigger

cmdLinkvalue

Property Quick Reference for CpStringNode Object(only input and output types, see Table 5-17 for all properties)



cmdLnk cmdLink string

output value value string

Note: This object is new to Niagara release 2.3.5. Unlike theother Cp objects, it is not available in r2.3 or r2.3.4.

Table 5-17 CpStringNode object properties.


S t a t u s

objectType,statusFlags,description,


— —

cmdLink(input: cmdLink) Read-Only: Current (string) value of thelinked (target) property, as on the input. valid string 0


Read-Only: Current (string) value of thelinked (target) property, as on the output.


valid string 0 At all times equal tothe cmdLink value.

C o n

f i g executionParameters Read-Write: The object’s execution frequency and order. Formore details, see “execution Parameters,” page 5-9.

normal,processor







CpStringNode

5–69

CpStringNode NotesThe CpStringNode is used to provide read/write-access to an internal property


be read-write and use the string data species.

Note String-type properties typically allow any combination of printable characters,

including spaces, mixed case characters, and numerals. However, when using a

browser connection, please note that any entered string with a plus sign (“+”) or

semicolon (“;”) is not accepted . Instead, the edit dialog remains open, and an error

message explaining the invalid characters appears in the status bar of the browser.

Example Figure 5-28 shows a CpStringNode that exposes a BO’s alertText.

Figure 5-28 CpStringNode used to expose alertText property for a BinaryOutput object.

V i s u a

l


commandText Read-Write: Defines how (and if) thecommand appears on the object’s right-click

command menu.


Any desiredtext string for

the commandto change alinked prop.

(none)

E n g




— —



General,

7 others

General

Table 5-17 CpStringNode object properties. (continued)



Object Name: AlertTextMod(linked to BO’s alertText property)commandText: Change Alert Text

Selecting the command produces anentry box. A user can review/modifythe alertText in the target BO.

Right-clickcommand showsthe commandText in the CpString.






DateTimeTrigger

5–70

DateTimeTrigger Quick reference for all properties: Table A-25

abbrev: (Dtrig)

DateTimeTrigger (Dtrig) objects are one of

several trigger-type objects. The Dtrig object provides a single trigger output that can be

configured to fire based on date and time.

Configuration allows for a specific day (one

time), date range, or other combinations

including day of week and daily.


PeriodicTrigger and Command objects.


container).


Trigger Properties The Dtrig object has the standard input property, executeTrigger , (never used) plus

an additional trigger-type output :

• timeTrigger —The “whole purpose” of this object. Fires once each day as

defined in the object’s Config properties.

The purpose of this object is to link this output to other object’s trigger-type inputs,

as needed, to perform a daily function at a particular time.

CommandsFor a JDE user with “Command, Admin” privileges, this menu bar command is

available (with the object’s property sheet displayed):

• Commands > clear —This clears the object’s trigger buffer, allowing it to

trigger again (on that same day).

Typically, this is not necessary unless you are changing the triggerTime after it

has already triggered for the day, and you need it to trigger again.

Properties

Inputs


Outputs

(none) (none)

Inputs


Outputs

executeTrigger timeTrigger

Property Quick Reference for Comparison Object(only input and output types, see Table 5-18 for all properties)



output timeTrig timeTrigger BooleanPriorityType

Table 5-18 DateTimeTrigger properties.





— —

C o n

f i g


normal,processor








DateTimeTrigger

5–71

DateTimeTrigger NotesAs needed, this object can be used to programatically fire a trigger-type input on any

other object. Figure 5-29 shows the object used to clear a Totalizer object total value.

Figure 5-29 DateTimeTrigger object used to reset the Total on the 1st day of each month.

C o n

f i g ,

c o n

t .

triggerDay Read-Write: Defines the day or days thetrigger output fires, at the configured triggertime (next property).

Three basic selections are:• Date—to select a single date.

• Date Range—to select a range ofconsecutive days.

• Week & Day—to select a combination of:

– Month, any (or all months)

– Week, any (or all weeks/last 7 days)

– Day of week (or all days of week).

Any selectablecombination.

Date(current)

For any field ordrop-down list in theJDE property sheet,

the asterisk (*)functions as a“wildcard” (matchesany and all entries).

triggerTime Read-Write: Defines the time of day thetrigger output fires.

12:00 AM to11:59 PM

—

V i s u a

lposition Read-Write: See “position,” page 5-9. — — —

E n g

i n e e r i n g



— —

lastTrigger Read Only: Shows the date of the lasttrigger fire.

Day Mo Yr (current)



General,

7 others

General

Table 5-18 DateTimeTrigger properties. (continued)


DateTimeTrigger objectconfigured as:

triggerDay = 1-***-****triggerTime = 0:00

Linked to theresetTotal input ofa Totalizer object.

On the midnight of the first day of eachmonth, the DateTimeTrigger objectfires, which resets the Totalizerobject’s accumulated total value.






FunctionGenerator

5–72

FunctionGenerator Quick reference for all properties: Table A-27

abbrev: Func

FunctionGenerator (Func) objects are

commonly used to test control logic and/or provide simulated values in the station. The

object generates a varying analog value that

is output on two outputs; a status type and a

prioritized type. By linking the outputs to

inputs of other control objects, results of a

control logic application can be observed in

real-time.

Configuration provides two basic output

modes, sine wave or ramp. Other properties

are available to adjust the rate of value

change and minimum and maximum values.


container).



Commands None.

Properties

Inputs


Outputs

(none) prioritizedOutput

statusOutput

Inputs


Outputs

executeTrigger

presentValue

prioritizedOutput

statusOutput

Property Quick Reference for FunctionGenerator Object(only input and output types, see Table 5-19 for all properties)



output present presentValue float



Table 5-19 FunctionGenerator (Func) object properties.


S t a t u s




C o n

f i g

executeParameters Read-Write: The object’s executionfrequency and order. For more details, see“execution Parameters,” page 5-9.

If needed, you can change the object’sexecution frequency to change its outputcycle rate. When using default settings in

the ControlEngineService, these settingsare relative to a “normal” frequency:

• faster—Twice the frequency

• fastest—Four times the frequency

• slower—Half the frequency

freq:never slower normalfaster fastest

minutelyon_trigger

order:input

processor output

normal,processor

To suspend (freeze)changes to theoutput, set theexecution frequencyto “never”.



http://-/?-

http://-/?-






FunctionGenerator

5–73

C o n

f i g ,

c o n

t .

minValue Read-Write: Minimum value that can appearat the object outputs.

valid float -10.0 If mode=sinusoidal,internally calculatedvalues are “clipped”

between these two.

maxValue Read-Write: Maximum value that can

appear at the object outputs.

valid float 10.0

increment Read-Write: Depending on mode, this valuefunctions as follows:

• Ramp mode: Step value for each outputchange, either added (when ramping up)or subtracted (when ramping down).

• Sinusoid: The output throttling range usedabove and below the offset value.

valid float 1.0 In sinusoid mode, foran output that variesfrom 0 to 100, use anincrement value of50 and an offsetvalue of 50.

See examples.

mode Read-Write: Defines operation as either:

• Ramp—Linear “sawtooth” output.

• Sinusoid—Sine wave output.

ramp, sinusoid sinusoid

offset Read-Write: Applies to sinusoid mode only

(ignored in ramp mode).Defines the midpoint of the internallycalculated sine wave.

valid float 0.0 The increment

property value isapplied above andbelow this midpoint.

degreesPerCycle Read-Write: Applies to sinusoid mode only(ignored in ramp mode).

Defines the number of degrees (°) of thesine wave’s period covered in eachexecution cycle (output change).Affects the time base of the output, where:

360°/<value> = number of output changes

For example, if degreesPerCycle is 3, thereare 120 output changes for a complete cycle(period) of the sine wave. If the object

executes once every 2 seconds, the sinewave period is 120 x 2 sec. = 240 sec (4minutes). In this case, if degreesPerCycle isset to 9, the period changes to 80 seconds.

integer value,typically from 1

to 12

1 A value of 1 makesthe smoothest (andslowest) sine wave.

A value of 0 freezesthe output atmidpoint.

See also the the“Sinusoid Mode”section onpage 5-74.






Other,no_units

V i s u a



0 to 6,


2,

no (+) sign

E n g



These properties are common to all controlobjects. For more information, see Table 5-3on page 5-8.

— —

Table 5-19 FunctionGenerator (Func) object properties. (continued)







FunctionGenerator

5–74

FunctionGenerator NotesThe FunctionGenerator has two operation modes:

• Sinusoid Mode

• Ramp Mode

Both modes are explained below, with examples shown in Figure 5-30.

Sinusoid Mode When the mode property is set to sinusoid, the object’s sine wave output varies by its

midpoint, magnitude, and number of output changes (granularity). These things are

determined by the values of the following configuration properties:

• increment —Defines the magnitude above (and below) the midpoint. For

example, if you want a total output swing of 8.5, set increment to 4.25.

• offset —Defines the midpoint output value.

• degreesPerCycle —An integer that affects the “granularity” and rate of the

sine wave output. The smallest value (1) produces the smoothest output and

slowest output rate. Values 12 and under are typical. An example calculation:

Note that the object’s execution frequency (seconds per execution cycle) affects the

sine wave period. Also, the minValue and maxValue properties can be configured to

“clip” part of the output. See the third example in Figure 5-30.

Ramp Mode When the mode property is set to ramp, the object’s sawtooth output is determined by the setting of the increment property, and the min and maxValue property settings.

The properties offset and degreesPerCycle are ignored .

• increment —Defines the output step change. This value is added to the output

when ramping up and subtracted from the output when ramping down.

• minValue and maxValue —Defines the smallest and largest values for the

continuous ramp output.

In addition, the object’s execution frequency directly affects the output rate.

E n g

i n e e r i n g ,

c o n

t . prioritizedOutput(output pOut)

Read Only: The current calculated floatvalue, at the priority level specified inpriorityForWriting.

<f. value> @<pri. level>

<f. value>@ 16

statusOutput(input sIn )

Read Only: The current calculated floatvalue and status.

<f. value>status flags

<value>ok



General,

7 others

General

Table 5-19 FunctionGenerator (Func) object properties. (continued)


360°period

1 period1 min.

1 min.60 sec.

2 sec.exec. cycle

degreesPerCycle x x x=

360 x 1 x 1 x 21 x 1 x 60 x 1

degreesPerCycle == 1272060 =

12°exec. cycle =






FunctionGenerator

5–75

Examples Figure 5-30 shows three sinusoid examples and two ramp examples, connected to a

GxTimePlot object configured to show values from -10 to 110 in a 2-minute span.

Figure 5-30 FunctionGenerator examples.

This FunctionGenerator isset up with these values:

freq = normal (2 sec)minValue = 0.0maxValue = 100.0increment = 50.0mode = sinusoidoffset = 50.0degreesPerCycle = 6


freq = normal (2 sec)minValue = 0.0maxValue = 100.0

increment = 50.0mode = sinusoidoffset = 50.0degreesPerCycle = 2


freq = fastest (500 ms)minValue = 20.0

maxValue = 95.0

increment = 50.0mode = sinusoidoffset = 50.0

degreesPerCycle = 6


freq = normal (2 sec)minValue = 0.0maxValue = 100.0increment = 3.0mode = rampoffset = <don’t care>degreesPerCycle =<don’t care>

This FunctionGenerator is

set up with these values:freq = fastest (500 ms)minValue = 20.0

maxValue = 95.0

increment = 3.0mode = rampoffset = <don’t care>degreesPerCycle =<don’t care>

1 period = 120 sec

The period is now 360 sec (6 minutes).

The only change from the first example is asmaller degreesPerCycle.

The minValue and maxValuesettings were changed, causing

the output to be “clipped.”

20.0

95.0

This is equivalent to the first example, butin a ramp mode configuration.

Execution frequency = fastest, minValue and maxValue rescaled.






IntToFloat

5–76

IntToFloatQuick reference for all properties: Table A-41

abbrev: ItoF

Integer to Float objects (ItoF) convert an

integer value to a floating point status value.This object is used between the output of an

object that produces integer values (out) and

an input of an object that accepts only

floating point values (in).

The IntToFloat is the only conversion-type

object included in the collection of standard

control objects. However, other conversion

type objects are included as tridiumx jar file,

mainly in subfolders under the lib/programs

folder. In addition, a custom conversion

object can be easily created using a standard

Program object.


container).



Commands None.

Properties

Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInputstatusOutput

Property Quick Reference for IntToFloat Object

(only input and output types, see Table 5-20 for all pro perties)



sIn statusInput IntegerStatusType

output sOut statusOutput FloatStatusType

Table 5-20 IntToFloat (ItoF) object properties.



statusFlags,description,


— —

C

o n

f i g


normal,processor



defaultIntValue Read-Write: Value used as the input in any

of these scenarios:

• Input (sIn) is not linked.

• Input link is removed.

• Input status is fault or down.

valid integer

value

0

V i s u a



0 to 6,


2,

no (+) sign






IntToFloat

5–77

IntToFloat NotesThe IntToF object is one of the simplest objects. It is typically used to convert an

IntegerStatusType value from an shadow object or standard control object into the

more widely-used FloatStatusType value. Often, properties defaultIntValue anddecimalFormat are edited from defaults.

Example Figure 5-31 shows IntToF objects used to convert the statusElapsedActiveTime

output (runtime, in seconds) of two BO objects to float values, in order for these

values to be used in a Comparison object.

Figure 5-31 IntToFloat objects used to convert BO elapsed active time (runtime) outputs.

Note To access other conversion objects, open the Niagara Local Library and expand the

tridiumx/lib JAR. General conversion objects are under the programs/conversion

folder, and Lonworks-related conversion objects are under the programs/lon and

programs/lonHoneywell folders. All are pre-engineered Program objects.

E n g

i n e e

r i n g

minExecuteTime,maxExecuteTime,averageExecuteTime,u

serData


— —

statusInput(input sIn)

Read Only: Shows the current integer valueand status at the statusInput.

<int value>status flags

0 ok


Read Only: Shows the current float valueand status produced on the statusOutput.


0.00 ok



General,

7 others

General

Table 5-20 IntToFloat (ItoF) object properties. (continued)


IntoFloatobjects

IntegerStatusTypesIn values

FloatStatusTypesOut values






Logic

5–78

LogicQuick reference for all properties: Table A-43

abbrev: (reflects function, e.g. A_OR_B)

A Logic objects acts as a two-input logic

gate, producing a boolean result that isavailable both as a status-type and a

prioritized-type output. The level of the

prioritizedOutput is configurable to any

priority level (1 to 16).

A Logic object can be configured to perform

one of the following functions:

• A_AND_ B (AND gate)

• A_OR_B (OR gate)

• A_XOR_B (XOR gate)

• A_NOT_B (NOT gate)Parent Dependencies: None (any

container).



Commands None.

Properties

Inputs


Outputs

statusInputA

statusInputB

prioritizedOutput

statusOutput

Inputs


Outputs

executeTrigger

statusInputA

statusInputB

presentValue

prioritizedOutput

statusOutput

Property Quick Reference for Logic Object(only input and output types, see Table 5-21 for all properties)



sInA controlledVariable BooleanStatusType

sInB setpoint BooleanStatusType

output pOut prioritizedOutput BooleanPr iorityType



Table 5-21 Logic object, important properties.


S t a t u s






— —

C o n

f i g


normal,processor



defaultA Read-Write: Acts as a constant state usedfor statusInputA, when that input is notlinked (or if its value has a status “fault”).

False, True False

defaultB Read-Write: Acts as a constant state usedfor statusInputB, when that input is notlinked (or if its value has a status “fault”).

False, True False






Logic

5–79

Logic NotesLogic objects are 2-input digital gates that can be used to process booleanStatus

values in the Niagara station. Each input has a configurable default value (state),

which is evaluated whenever the input is not connected or has a fault status.

Logic objects are used singly or in combinations to provide whatever boolean logic

is needed for an application

C o n

f i g ,

c o n

t .

function Read-Write: Defines the logic function of theobject. The selected function shows in theobject’s shape.

A_AND_BA_OR_B

A_XOR_B

A_NOT_B

A_AND_B



trueCommand Read-Write: Defines the prioritizedOutputstate produced upon a true logic result.

Applies only to the prioritizedOutput.

true, false,auto

true

falseCommand Read-Write: Defines the prioritizedOutputstate produced upon a false logic result.

Applies only to the prioritizedOutput.

true, false,auto

false

V i s u a

l


activeInactiveTextactive

inactive

Read-Write: Defines the displayed states atthe statusInput, statusOutput, and

presentValue, and also how they appear onthe object’s property sheet.

Any desireddescriptors for

the two states.

true<active>,

false<inactive>

States can display ata linked GxText

object.

E n g

i n e e r i n g



— —


Read Only: Shows the current boolean stateand status at statusInputA.

false, truestatus flags

false : ok


Read Only: Shows the current boolean stateand status at the statusInputB.

false, true @<pri. level>

false : ok




false : @ 16 Displays state usingactiveInactiveText.




false : ok



General,

7 others

General

Table 5-21 Logic object, important properties. (continued)







Logic

5–80

Logic ObjectTruth Tables

Truth tables in Table 5-22 show Logic output results from different combinations at

the sInA and sInB inputs, organized by the selected logic function.

Note Outputs results shown below assume the default property values are assigned for

trueCommand (true) and falseCommand (false). Note that these properties areconfigurable to either false, true, or auto. If set to non-defaults, only the

prioritizedOutput follows those defined states, at the defined priorityForWriting

level. The statusOutput always follows the output states (sOut, pOut) shown below.

Notes • There is no operational difference between the A_XOR_B and A_NOT_B

function. Often, the A_NOT_B function is used with a single input link (for

logic inversion) and the A_XOR_B function is used with both inputs linked for

an exclusive OR operation.• Certain arrangements of logic objects provide other logic functions, such as

NAND, NOR, and EQUIV (equivalent) functions. See Figure 5-32.

Table 5-22 Truth tables for Logic object functions.

A_AND_B A_OR_B

sInA sInB sOut, pOut sInA sInB sOut, pOut

false false false false false false

false true false false true true

true false false true false true

true true true true true true

A_XOR_B A_NOT_B

sInA sInB sOut, pOut sInA sInB sOut, pOut

false false false false false false

false true true false true true

true false true true false true

true true false true true false






Logic

5–81

Examples Figure 5-32 shows various boolean operations using Logic objects.

Figure 5-32 Various Logic object examples.

This Logic object simplyinverts the boolean state

present on its sInA input.Input sInB is not linked.However, the defaultBproperty is set to true.

Simple Logic Inversion Logic Object Configuration (inversion):

defaultA: false (default)

defaultB: truefunction: A_NOT_BtrueCommand: true (default)falseCommand: false (default)

The NAND function is doneby using two objects.

The output of a Logicobject configured asA_AND_B (with defaultConfig properties) isinverted to produce aNAND gate.

NAND Gate Operation

The NOR function is doneby using two objects.

The output of a Logicobject configured asA_OR_B (with defaultConfig properties) isinverted to produce a NORgate.

NOR Gate Operation

The EQUIV function is alsodone by using two objects.

The output of a Logic

object configured asA_XOR_B (with defaultConfig properties) isinverted to produce anEQUIV gate.

EQUIV Gate Operation

When more than 2 inputsare needed in a booleanoperation, multiple Logicobjects can be cascaded.

For example, an 8-inputAND gate is made usingseven Logic objects, asshown at right. Any of theLogic objects can beconfigured separately,depending on the booleanoperation needed.

This cluster could beencapsulated inside aComposite object, so as toexpose only the first 8inputs and final output.

Cascaded Logic Objects

NAND Logic

sInA sInB sOut, pOut

false false true

false true true

true false true

true true false

NOR Logic


false false true

false true false

true false false

true true false

EQUIV Logic


false false true

false true false

true false false

true true true






Loop

5–82

LoopQuick reference for all properties: Table A-44

abbrev: (none); LOOP

Loop objects provide closed-loop PID

control (proportional, integral, derivative) atthe station level. Independent gain constants

allow the loop to be configured as P-only, PI,

or PID.

The typical Loop application is to provide

setpoint control to a variable output device

when the process variable, setpoint input, or

control variable reside in different physical

locations.

The Niagara Loop object has many

characteristics of the BACnet Loop object,

including the ability for alarming on setpointdeviation.


container).


Trigger Properties The Loop object has the standard input property, executeTrigger , (typically not used)

plus an additional trigger-type input :

• resetIntegral —Any received trigger pulse clears the current integral

component of the loop’s output calculation. If needed, this input can be linked

to another object to provide a quick purge of the integral effect. Examples

include the changeOfStateTrigger output of a related BinaryOutput object (say

for a supply fan), or a perhaps a Command object. Typically, the later would

provide more of a “debug” utility, and should not be necessary if the Loop

object’s configuration properties are correctly defined.

Also, note that whenever the Loop’s input “statusInhibit” is linked, an integralreset occurs automatically each time a false-to-true transition is received.

In addition, the Loop object also provides two trigger-type outputs:





Inputs


Outputs

controlledVariable

setpoint

prioritizedOutput

statusOutput

Inputs


Outputs

executeTrigger

statusInhibit

controlledVariable

setpoint

action

resetIntegral

eventTrigger

presentValue

prioritizedOutput

statusOutput

covTrigger

Property Quick Reference for Loop Object(only input and output types, see Table 5-23 for all properties)




sInCtrl controlledVariable FloatStatusType

sInSet setpoint FloatStatusType

action action ActionEnum

resetInt resetIntegral TriggerType


present presentValue float









Loop

5–83

CommandsFor a JDE user with “Command, Std” privileges, the following right-click commands

are available (these commands are not accessible from a Web browser):

• enableDebug —causes debug-level data on the Loop’s operation to be

continuously sent to Standard Output.An example of Loop object debug output (continuously repeating):

pGai n 0. 3000030517578125 i Gai n: 0. 0 dGai n0. 0 er r orSum 0. 0 er r or0. 30000305 pv 0. 30000305 del t aSecs 2. 003

• disableDebug —stops debug-level data from being sent to Standard Output.

If the JDE user has “Command, Admin” privileges, this additional command is

available from the JDE menu bar:




PropertiesTable 5-23 Loop object propert ies.


S t a t u s



— —

eventState,reliability,outOfService,ackedTransitionstoOffnormal,

toFault,toNormal,presentValue


— — presentValue isalways read-only.It displays in theconfigured outputunits (outputUnits).

C o n

f i g


normal,processor



defaultSetpoint Read-Write: Value used as the loop setpointin any of these scenarios:

• Setpoint input (sInSet) is not linked.

• Setpoint link is removed.

• Setpoint input status is “fault” or “down.”

valid float 0.0






Loop

5–84

C o n

f i g ,

c o n

t .

defaultAction Read-Write: Selection of loop action aseither direct or reverse acting, where:

• direct—Loop output increases as the

value of the controlled variable becomesless than the setpoint value.In a temperature loop, this is typicallyconsidered to be a heating application.

• reverse—Loop output increases as thevalue of the controlled variable becomesgreater than the setpoint value. In atemperature loop, this is typicallyconsidered to be a cooling application.

Note: In some applications usingstatusInhibit and a reverse action loop,different configurations may be desired. Seethe the “Status Inhibit Operation” section on

page 5-88 for more information.

direct, reverse directNote: Loop action isdefined in a manneropposite to most

other controlsystems.

The “action” input, iflinked, can be usedto override thisdefault action (thisrequires a customProgram object).

outputUnits Read-Write: For display purposes, definesthe engineering units of the loop output.Choose from a logical grouping, then aspecific unit.



Other,no_units

Used in display ofpresentValue,statusOutput,prioritizedOutput,many propertydescriptors on theproperty sheet.

controlledVariableUnits Read-Write: For display purposes, definesthe engineering units of the controlledvariable (received at input sInCtrl). Choosefrom a logical grouping, then a specific unit.


Other,no_units

Used in display ofsome propertydescriptors on theproperty sheet.

proportionalConstant Read-Write: Defines the value of the

proportional gain parameter used by theloop algorithm. Used to set the overall gainfor the loop.

A starting point for this value is found by:output range / throttling range.

valid float 1.0 Expressed in terms

of outputUnits overcontrolledVariableUnits.

Must be a positivevalue.

integralConstant Read-Write: Defines the integral gainparameter, in repeats per minute, used bythe loop algorithm. Also called reset rate.Acts on the magnitude of the setpoint error.

valid float,positive only

0.0(no

integral)

maxIntegralGain Read-Write: Defines the largest amount ofintegral gain allowed, typically requiredwhen using PI or PID control.

Note: For PI or PID control, this is

recommended to be set to the same valueas maximumOutput.

valid float,positive only

0.0(no

integral)

Integral effect isignored unless youenter a value here. Ifset less than themaximumOutputvalue, control offsetmay occur.

derivativeConstant Read-Write: Defines the derivative gainparameter, in seconds, used by the loopalgorithm. Acts on the rate of change of thesetpoint error.

valid float 0.0(no

derivative)

Table 5-23 Loop object properties. (continued)







Loop

5–85

C o n

f i g ,

c o n

t .

bias Read-Write: Defines the amount of outputbias added to the output to correct offseterror. In other words, the output at setpoint.

Expressed in the same units of theoutputUnits.

Note: For proportional-only use only. For PI or PID control, set bias to 0.0 (thedefault). The integral term can be hamperedby a non-zero bias.

valid float 0.0 For proportional

only control, this istypically set midway

between maximumand minimumoutput.

For a loop with anoutput of 0.0 to100.0, this is 50.0.

maximumOutput Read-Write: Defines the maximum outputvalue that the loop algorithm can produce.

valid float 100.0 maximumOutputmust be greaterthan theminimumOutput.

minimumOutput Read-Write: Defines the minimum outputvalue that the loop algorithm can produce.

valid float -100.0



covIncrement Read-Write: The minimum change for thecalculated loop output (since the last outputchange) before all outputs can update.

valid float 0.0

(nominimum)


A l a r m

S e

t u p



— — * See specificdetails oninhibitTime, the nextproperty.

inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked.The purpose is to prevent nuisance alarmson equipment startup and shutdown, andalso to selectively stop Loop output

processing.

The inhibitTime is triggered by a transitionfrom false-to-true at the statusInhibit input.

• When statusInhibit becomes true, alarmprocessing is delayed for the duration ofthe inhibit time. The loop output beginsrecalculating, with the output starting at avalue based solely on the proportional

constant (the integral term is cleared).• Whenever statusInhibit becomes false,

the loop output freezes at its last value,

and alarm processing remains inhibited.

Note: In some applications usingstatusInhibit and a reverse action loop,different configurations may be desired. Seethe the “Status Inhibit Operation” section onpage 5-88 for more information.

any practicalvalue inHr:Min:Sec

00:00:00(no inhibit) A minimum of 1second (00:00:01) isrecommendedwhenever thestatusInhibit islinked.

Alarm processingcompares thecontrolledVariableinput value to thesetpoint value (plusor minus theerrorLimit).








Loop

5–86

Loop NotesThe Loop object provides a closed-loop (feedback-based) control signal based upon

values received at its setpoint input and its controlled variable input. The loop

algorithm may be configured as proportional-only (P), proportional plus integral

(PI), or proportional plus integral and derivative (PID).

The following main topics apply to Loop objects:

• Loop Terms

• Status Inhibit Operation

• Proportional Only Control

• Proportional with Integral (PI) Control

• Proportional with Integral and Derivative (PID) Control

• Examples

A l a r m

S e

t u p ,

c o n

t . errorLimit Read-Write: Defines the maximumdeviation value between the controlledvariable and the loop’s setpoint before the

object alarms with an off-normal state.

valid float 100.0 Applied both aboveand below thesetpoint value.

deadband Read-Write: Differential value applied toerrorLimit before return-to-normal.

valid float 100.0

V i s u a



0 to 6,


2,

no (+) sign

E n g

i n e e r i n g



— —

statusInhibit

(input sInh)

Read Only: The current boolean state and

status of the statusInhibit input.

false, true

status flags

false : ok If linked, the

inhibitTime value isused.

controlledVariable(input sInCtrl)

Read Only: The current float value andstatus of the process input (sInCtrl).


00.0 ok

setpoint(input sInSet)

Read Only: The current float value andstatus of the setpoint input (sInSet).


00.0 ok


Read Only: The current float value andpriority level at the prioritized output (pOut).

<float value>@ <pri. level>

0.00 @ 16


Read Only: The current float value andstatus at the statusOutput.


00.0 ok

action(input action)

Read Only: The current action of the loopalgorithm, which can be dynamically

toggled through a link to the action input. Ifthe action input is not linked, this propertydisplays the current “defaultAction” setting.

direct, reverse direct Typically, the actioninput is not linked. If

linked, the sourcedata species mustbe actionEnum.



General,

7 others

General








Loop

5–87

Loop Terms The following terms are used ahead to describe the operation of the Loop object.

• Process variable —The controlled process, meaning the value at the

controlledVariable input. (“What you’ve got.”) Abbreviated here as “PV.”

• Setpoint —The target for the process variable, meaning the value at the

setpoint input. (“What you want.”) Abbreviated here as “setpt.”• Setpoint error —The difference between the process variable and the setpoint,

acted upon by the loop algorithm. Abbreviated as “ES.”

• Loop Output —The correction signal produced by the loop algorithm,

available at the object outputs (prioritizedOutput, statusOutput). Referred to as

“output.” The output should be linked (directly or indirectly) to an

AnalogOutput object used to position the proportionally-modulated device

(such as a valve or damper) that controls the process variable.

• Proportional gain —The value of the property proportionalConstant.

Abbreviated here as K P. Sets the overall gain of the loop, as the following ratio:

K P = Output range / effected process range (sometimes called throttling range).

• Throttling range —The amount of process variable change expected as aresult of throttling the system between the minimumOutput and

maximumOutput.

• Bias —A value added to the output to correct offset error. It is typically used in

proportional-only control as a “pivot” output value, for when the PV = setpt.

• Action —Defines the “direction” of the output relative to setpoint error, where:

– Direct—Loop output increases when PV < setpt.

– Reverse—Loop output increases when PV > setpt.

Note Action is defined in a manner opposite to most other control systems.

The property defaultAction defines the Loop object’s action, which can be

overridden by linking to the action input (this requires a Program object with

an output using the “actionEnum” data species).

• Integral gain —The value of the property integralConstant. Abbreviated as K I.

Sets the integral or “reset” gain of the loop, expressed in repeats per minute.

The K I component of the loop output reacts to the duration of the setpoint error.

• Derivative gain —The value of the property derivativeConstant. Abbreviated

here as K D. Sets the derivative or “rate” gain of the loop, expressed in seconds.

The K D component of the loop output reacts to the “rate of change” of setpoint

error, and provides a “dampening” effect.• maximumOutput —This property defines the maximum value produced by

the loop output. Must be set greater than the minimumOutput value.

• minimumOutput —This property defines the minimum value produced by the

loop output. Must be set less than the maximumOutput value.






Loop

5–88

Status InhibitOperation

The statusInhibit input, when linked , directly affects two separate functions of a

Loop object:

• Output processing —The Loop output “freezes” at the last calculated value

when this input receives a “false” (inactive).

Upon a transition to “true,” the Loop output begins processing, however, theintegral term is initially cleared . This means the loop output starts with a value

based purely on proportional gain (using the current PV and setpoint values).

Typically, this means that the loop output makes a jump towards zero (0) for

both direct and reverse acting loops. If the loop’s value is already at its

minOutput value, obviously it will not move any lower.

Note In the case of reverse acting loops, and depending on the action of the

controlled device to the PV, it may be desired for the loop's output to

move toward its maxOutput output value when the loop's statusInhibit

changes from false-to-true. This can be done by using a Math object

setup to do a Reset function connected to the output of the loop. In thiscase, the Loop would be set to be direct acting and the Reset object

would be setup to reset the loop output, for example, from 0-100 to

100-0. This configuration provides the reverse action desired, and

allows the output of the Reset object to be near the maxOutput when the

loop starts to control.

• Alarm processing —The Loop object stops all alarm processing whenever this

input receives a “false” (inactive). The alarm status of the object cannot

change. This applies whether the object’s statusFlags show a normal (“ok”)

state or “inAlarm” and/or “unackedAlarm” states.

Upon a statusInhibit input transition to “true,” the configured inhibit timer

(property inhibitTime) begins counting down towards zero, at which point theinhibit timer expires. After this inhibit time period, if the object is in an alarm

condition (as defined by its Alarm Setup properties), it will alarm.

Proportional OnlyControl

P-only control is just reset action, where loop output is directly proportional to the

magnitude of the setpoint error (ES) and the size of the proportional gain (K P).

• Output Calculation

• P-only Configuration Guidelines

Output Calculation: P-only loop output is linear, and is calculated as follows:

Output = (K P x ES) + bias (if action = direct)or

Output = – [(K P x ES) + bias] (if action = reverse

where:

ES = [setpt - PV]

A characteristic of P-only control is setpoint offset, which occurs unless the process

load just happens to be at the (one) ideal level.






Loop

5–89

P-only Configuration Guidelines

If using proportional-only control, follow these guidelines:

Output limi ts—Define the maxValue and minValue properties for the loop output,

noting that the maximum value must be greater than the minimum.

Proportional Gain—Calculate and enter a proportionalConstant (K P) property

value starting with this formula:

where throttling range is the corresponding result in the process variable.

For example, for a temperature loop where a 0-to-100% loop output results in a 20°

swing in the process variable, a starting point K P is:

When tuning the loop, you can try increasing this value (effectively using only a

portion of the throttling range) to eliminate the amount of setpoint error. However, if

you increase the K P too much, this typically results in a constant oscillation of the

process variable (above and below the setpoint).

Bias—Assign the bias property an “output-midpoint” value (for example, 50.0).

This allows for equal corrections for a process variable above or below setpoint.

Integral and Derivative Gain—Set the properties integralConstant and

derivativeConstant to 0.0 (the defaults).

Act ion—Define the defaultAction property as either direct or reverse as needed

(noting that the Niagara loop definition is typically opposite to most control systems).

Also, note that by editing the proportionalConstant property value to a negative

value, this effectively “toggles” the action definition.

Proportional withIntegral (PI)Control

PI configuration is recommended for most control loops, because the integral term

eliminates the setpoint offset inherent in P-only loops. PI control uses proportional

gain to adjust the output, and then incrementally continues to “add” (or subtract, if

appropriate) from the output value for as long as a setpoint error continues to exist.

The following topics apply to PI Loop control:

• Output Calculation• Repeats Per Minute

• Integral Overshoot

• PI Configuration Guidelines

output range (outputMax - outputMin)

throttling range

(100% - 0%) = 100% = 5

20° 20°






Loop

5–90

Output Calculation: PI loop output is calculated as follows:

Output = K P x (ES + K I ) + bias (if action = direct)

or

Output = – [(K P x (ES + K I ) + bias] (if action = reverse)

where:

ES = [setpt - PV]

The integralConstant property specifies the integral gain (K I) in “repeats per minute,”

sometimes called a “reset rate.”

Repeats Per Minute—To understand repeats per minute, consider the scenario

where a loop is controlling at setpoint. If a certain setpoint error occurs, say from a

sudden setpoint change, the loop output immediately changes by a level

corresponding to its proportional constant (acting on the P-term). During this

hypothetical example, assume the controlled process does not react from any loop

output change, but stays at the original value (setpoint error stays constant).

The loop’s integral term immediately begins increasing the output (or decreasing the

output, depending on the direction of setpoint error) at specific rate determined by

the integral term. Over the period of one minute, the amount of output change that

would occur is defined by the integralConstant (repeats per minute). A “repeat”

equals the amount of output change initially generated by the P-term. For example,

if this loop was configured with an integralConstant value of 2.0, and the original

output change was +7%, over a period of one minute the integral term would linearly

ramp up the output value an additional +14%, or “2 repeats.” See Figure 5-33.

In a real-world PI loop, of course, the process variable does respond to an output

change, and this continuously-linear ramping of the output would not occur. Instead,

the process variable would start moving towards setpoint and the setpoint error would

change (changing the proportional and integral terms, thus the loop output).

Figure 5-33 Example of Loop integral gain (repeats per minute).

Compare the output of twoLoop objects, both with thesame proportional gain. Thetopmost Loop object has anintegralConstant of 2.0, whilethis property in the otherLoop has a value of 0.0 (nointegral).

The initial setpoint shiftcauses the equivalent outputchange from both objects.The output of the Loop_PIobject continues to ramp up,however, as the process

variable does not respond.After one minute, “two resets”have occurred.

Both Loop outputs change fromP-term (first setpoint change).

P-Only Loop outputstays fixed.

PI loop outputincreased abouttwice the originalamount (tworesets) in the oneminute since thesetpoint change.

Integral from PI Loopoutput continues to rise.






Loop

5–91

Integral Overshoot

The integral term of a PI loop can cause an “overshoot” of setpoint, meaning that the

increased loop output may result in a new setpoint error in the opposite direction. In

some cases, it is possible for this overshoot to continuously repeat (oscillation),

which is typically undesired. However, a small amount of overshoot for an initial

correction is not uncommon.

To minimize overshoot, the PI loop’s integralConstant is typically kept small, and

sized appropriately for the assigned proportionalConstant.

PI Configuration Guidelines

If using PI control, follow these guidelines:

Output limi ts—Define the maxValue and minValue properties for the loop output,

noting that the maximum value must be greater than the minimum.

Proportional Gain—Calculate and enter a proportionalConstant (K P) property

value starting with this formula:

where throttling range is the corresponding result in the process variable.

For example, for a temperature loop where a 0-to-100% loop output results in a 20°

swing in the process variable, a starting point K P is:

When tuning a PI loop, you typically reduce the proportionalConstant value, becausethe integral effect on the output will correct setpoint error over time.

Bias—Assign a value of 0.0 (no output bias). A fixed bias is not desired , because the

integral term of the loop effectively creates an “adjustable bias,” as needed.

Integral Gain—Set the integral gain (property integralConstant) to a nominal value,

typically less than one (1.0). A value of 0.5 is a good starting point for many loops.

Note Make sure to change the maxIntegralGain property from its default (0.0) to a larger

value—in most cases, maxIntegralGain should equal the maxOutput value. If

maxIntegralGain is left at default, the output will not reflect any integral gain.

Derivative Gain—Disable derivative by setting the derivativeConstant property at

0.0 (the default).

Act ion—Define the defaultAction property as either direct or reverse as needed

(noting that the Niagara loop definition is typically opposite to most control systems).

Also, note that by editing the proportionalConstant property value to a negative

value, this effectively “toggles” the action definition.

output range (outputMax - outputMin)

throttling range

(100% - 0%) = 100% = 5

20° 20°






Loop

5–92

Proportional withIntegral andDerivative (PID)Control

PID loop control can be difficult to tune and (often for this reason) is seldom used.

However, in certain cases, PID control may be needed. An example is the control of

a process with a long “reaction time,” such as temperature control of a large mass.

For such a lag-oriented system, the derivative component of the PID loop output can

help prevent “overshoot” that might otherwise result from PI control.

The derivative gain (K D) exerts an anticipating “braking” effect on the loop output,

based on the rate-of-change of the process.

• Output Calculation

• PID Configuration Guidelines

Output Calculation: PID loop output is calculated as follows:

Output = K P x (ES + K I + K D) + bias (if action = direct)

or

Output = – [(K P x (ES + K I + K D) + bias] (if action = reverse)

where:ES = [setpt - PV]

In the Loop object, the derivativeConstant property specifies the derivative gain (K D)

directly in seconds (note this differs from some systems using derivative in minutes).

PID Configuration Guidelines

If using PID control, follow the the “PI Configuration Guidelines” section on

page 5-91, with the addition of defining a positive value as the derivativeConstant.

In general, a derivativeConstant less than 10 seconds should be tried first, and only

then increased (if necessary), providing that the loop output remains stable at

steady-state conditions.

Examples Due to the many unique characteristics of any loop-controlled process, the real-life

examples in Figure 5-34 are given for background information (not for duplication).

Each row gives a separate example with a brief explanation, a screen capture from

the JDE, and some of the important Loop configuration properties.






Loop

5–93

Figure 5-34 Various Loop Object Examples.

This Loop object monitorsthe hot-water supplytemperature, receives ahot-water supply setpointthat is reset by the outside

air temperature, andcalculates a 0 to 100%output. The output isrescaled by a Math objectto compensate for valvecharacteristics.

Boiler Control PI Loop Loop Object Configuration:

defaultAction: directoutputUnits: percentcontrolledVariableUnits: degreesFahrenheitproportionalConstant: 2.00integralConstant: 0.10 / min.maxIntegralGain: 100.0 %derivativeConstant: 0.0 sec.bias: 0.0 %maximumOutput: 100.0 %minimumOutput: 0.0 %

This Loop object monitorsan AHU’s discharge airtemperature, receives asetpoint from an AO object,and outputs a 0 to 100%output that is used to

position a cooling valve.

Discharge Air AHU) PI Loop Loop Object Configuration:

defaultAction: directoutputUnits: percentcontrolledVariableUnits: degreesFahrenheitproportionalConstant: 1.75integralConstant: 0.50 / min.

(other properties as listed in first example)

This Loop object monitorsthe (minimum) zone headpressure of multiple chilledwater supply lines, andreceives a constantsetpoint of 18 PSI from aMath object. The Loopoutputs a 20 to 100% signalused to control a variablefrequency drive (VFD) forthe chilled water supplypump. A Command object

is used (for tuningpurposes) to clear theloop’s integral term.

Chilled Water Supply Pump VFD Loop Object Configuration:

defaultAction: directoutputUnits: percentcontrolledVariableUnits: pounds_per_sq_inchproportionalConstant: 1.2integralConstant: 0.8 / min.maxIntegralGain: 100.0 %derivativeConstant: 0.0 sec.bias: 0.0 %maximumOutput: 100.0 %minimumOutput: 20.0 %






Math

5–94

MathQuick reference for all properties: Table A-47

abbrev: reflects function, e.g. RESET

A Math object performs a math operation

using float values present at from one to fourinputs. The float value result is available on a

status-type output and a prioritized-type

output. The prioritizedOutput level is

configurable to any priority level (1 to 16).

The function of the object is configurable as:

• Minimum (MIN)

• Maximum (MAX)

• Summation (SUM)

• Average (AVG)

• Difference (DIFF)• Absolute Value (ABS)

• Square Root (SQRT)

• Log Natural (LN)

• Log (LOG)

• Exponential (EXP)

• Sine (SIN)

• Cosine (COS)

• Tangent (TAN)

• Arcsine (ASIN)

• Arccosine (ACOS)

• Arctangent (ATAN)

• Reset (RESET)

• Multiplication (MULT)

• Division (DIV)

• Power (POW)


container).


Trigger Properties None, apart from the standard input property, executeTrigger . In certain cases,

linking to this input may provide some utility. For example, by configuring a Math

object to execute “on_trigger”, math functions can calculate only under certain

conditions, such as another object firing a trigger to indicate an alarm event.

Commands None.

Inputs


Outputs

statusInputA

statusInputB

statusInputC

statusInputD

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInputA

statusInputB

statusInputC

statusInputD

prioritizedOutput

statusOutput

Property Quick Reference for FunctionGenerator Object(only input and output types, see Table 5-24 for all properties)



sInA statusInputA FloatStatusType

sInB statusInputB FloatStatusType

sInC statusInputC FloatStatusType

sInD statusInputD FloatStatusType



Input Usage by Selected Funct ion

Any or all inputs average

minimummaximum

multiplication

summation

First two inputs(sInA and sInB)

difference (sInA minus sInB)

division (sInA divided by sInB)

power (sInA to the sInB power)

sInA (only) abs (absolute value of sInA)

sqrt (square root of sInA)

reset (of sInA value according to config properties)

All remaining functions, including trigonometric ones whichproduce an output value in radians.






Math

5–95

PropertiesTable 5-24 Math object propert ies.


S t a t u s

objectType,

statusFlags,description,presentValue,


on these common object properties.

— — For this object,




— —

C o n

f i g


normal,processor



defaultA Read-Write: Acts as a constant value usedfor statusInputA, when that input is notlinked (or if its value has a status “fault”).

valid float NaN(null)

Can apply to anyfunction selection.

defaultB Read-Write: Acts as a constant value usedfor statusInputB, when that input is notlinked (or if its value has a status “fault”).


defaultC Read-Write: Acts as a constant value usedfor statusInputC, when that input is notlinked (or if its value has a status “fault”).


defaultD Read-Write: Acts as a constant value usedfor statusInputD, when that input is notlinked (or if its value has a status “fault”).


function Read-Write: Defines the math function(operation) used by the object.

• Certain functions can make use of all (4)float status inputs, as needed. These

function selections are:minimum, maximum, summation,average, and multiplication

• Other functions use only the first 2 inputs(statusInputA and B), namely:

difference, division, and power

• The remainder of functions use only thevalue at statusInputA. Primarily, these aretrigonometric functions, and include:

abs (absolute value), sqrt (square root), ln(natural log), log, exp, sin, cos, tan, asin,acos, and atan. Also: reset.

• The reset function requires defined values

for the properties inputLowLimit,inputHighLimit, outputLowLimit, andoutputHighLimit.

minimummaximumsummation

averagedifference

abssqrtlnlogexpsincostanasinacosatanreset

multiplicationdivision

power

summation For multiplication,the output is:A X B X C X D, whereany NaN values (notlinked and no

default) are ignored.

For division, theoutput is A / B.If B is 0, the outputis NaN.

For any of thetrigonometricfunctions, units arein radians.

For the powerfunction, inputA isthe radix and inputBis the exponent.

units Read-Write: Engineering units for the mathoutput, for display purposes. Choose from alogical grouping, then a specific unit.



Other,no_units






Math

5–96

C o n

f i g ,

c o n

t .

outputHighLimit Read-Write: Defines the maximum valueproduced at the output. All internallycalculated values are clamped at this limit.

valid float NaN(none)

A reset applicationpermits theHighLimit to be less

than the LowLimit, ifa reverse resetoutput is required.

outputLowLimit Read-Write: Defines the minimum valueproduced at the output. All internallycalculated values are clamped at this limit.




covIncrement Read-Write: The minimum change for thecalculated loop output (since the last outputchange) before all outputs can update.

valid float 0.0

(nominimum)


inputHighLimit Read-Write: Applies to Reset function only.Defines the maximum input value. An input

above this value is evaluated as this value.When the input is at this value, the output isat the outputHighLimit value.


inputLowLimit Read-Write: Applies to Reset function only.Defines the minimum input value. An inputbelow this value is evaluated as this value.

When the input is at this value, the output isat the outputLowLimit value.


V i s u a



0 to 6,


2,

no (+) sign

E n g

i n e e r i n g



— —


Read Only: Current calculated float valueand status output at the statusOutput.


<NaN> ok


Read Only: Current calculated float valueand priority level at the prioritizedOutput.

<f. value> @<pri. level>

<NaN>@ 16


Read Only: Current float value and status atstatusInputA.


<NaN> ok


Read Only: Current float value and status atstatusInputB.


<NaN> ok

statusInputC(input sInC)

Read Only: Current float value and status atstatusInputC.


<NaN> ok

statusInputD(input sInD)

Read Only: Current float value and status atstatusInputD.


<NaN> ok



General,

7 others

General

Table 5-24 Math object properties. (continued)







Math

5–97

Math NotesMath objects are commonly used to process float values in the station. The function

property determines the specific math operation (minimum, maximum, averaging, so

forth) performed by the object.

Not a Number(NaN)

The absence of a float value (null value) is represented in the Niagara station as

“NaN,” for “Not a Number.” Typically, you only see NaN from outputs of a device

(shadow) object, and only while that device is down. Note that NaN is different from

zero (0.0), because an object processes zero as a valid value.

By default, a newly created Math object produces a NaN output, at least until

statusInputA is linked. This is because the “default” settings for the config properties

defaultA, B, C, and D, are NaN (and not 0.0 or any other real value). In some cases,

you might want to change these property values to a real float value, as an appropriate

fallback for that input. This default value will be used whenever its corresponding

input receives an NaN or a status “fault” (supplying object is in fault, and colored

orange).

Note that in certain scenarios, the default NaN might be the best choice. For example,

if you are averaging four values received on statusInputsA through D, and a device

that is responsible for one of the values goes down, the default NaN value would give

the most accurate output (for the remaining three input values) because the Math

algorithm ignores the NaN. This same logic applies when configured for the math

functions minimum and maximum.

When configured for other functions, however, you would typically want fallback

values rather than ignored inputs—multiplication and summation, for example. Also,

note that any of the math functions that use only one or two inputs (the majority) do

not ignore NaN. Instead, the Math object produces an NaN output . Depending on

your downstream control logic, this could produce unwanted results.

Usage Notes The following sections explain some Math object topics:

• Simplest Usage

• Reset Function

• Cascading Math Objects

Simplest Usage

A Math object can be used to simply hold a constant value, for example a setpoint,

without even linking any of its inputs. In this case, you enter the constant value as its

“defaultA” property, and simply leave the object’s function at the default of

“summation”. The Math object’s outputs can be linked to float inputs of other objectsthat require this constant value. This is the simplest use of a Math object.






Math

5–98

Reset Function

Another common use for a Math object is to perform a linear reset on the value

received at its first (statusInputA) input. The reset schedule is defined by the

following four configuration properties:

• outputHighLimit—may (or may not) be greater than the outputLowLimit• outputLowLimit—may (or may not) be less than the outputHighLimit

• inputHighLimit—must be greater than the inputLowLimit

• inputLowLimit—must be less than the inputHighLimit

A classic example is to reset a hot water (boiler) setpoint based upon the present

outside air temperature. In this case, as the outside air temperature (received on the

input) goes down, the desired boiler setpoint will go up—in other words, a reverse

reset. Engineer this by making the outputHighLimit less than the outputLowLimit.

For example, a Math object configured for a boiler setpoint (reverse) reset may have

the following values for these properties:

• outputHighLimit: 130°

• outputLowLimit: 200°

• inputHighLimit: 60°

• inputLowLimit: 0°

When the outside air temperature is 0° (or below), the boiler setpoint calculated by

the Math object will be 200°. Likewise, the boiler setpoint will be 130° when the

outside air temperature is 60° or higher. When outside air temperature is anywhere

between 0° and 60°, the setpoint output is linearly reset.

Valve Compensation—A reset-configured Math object is often used between a

Loop object and an AO object to help compensate for certain valve characteristics.For example, a valve positioned between 15% and 65% may result in from 3% to

98% flow. Although the Loop object is capable of performing a similar reset function

internally, in this case having its outputHigh and outputLow set to 65.0 and 15.0,

respectively, (versus 100.0 and 0.0), this might not be desired. For example, the

0-to-100% loop output value might be needed for display purposes, or be needed in

some other control logic. In this case, a reset-configured Math object could be used

to reset the Loop output, compensating for valve characteristics as needed.






Math

5–99

Cascading MathObjects

Math objects are frequently cascaded to perform a specific calculation. Consider the

three Math objects shown in Figure 5-35, used to calculate tonnage of cooling.

Figure 5-35 Cascaded Math objects calculating cooling tonnage.

The first Math objectfinds the differencebetween the chilledwater return temp.(sInA) and chilledwater supply temp.(sInB): the “delta T.”

The next Math objectmultiplies the delta T(sInA) and thecurrent chilled waterflow rate (sInB), ingallons per minute.

The last Mathobject divides theresult on sInA bythe constant of 24(defaultB propertyvalue).






MultistateInput

5–100

MultistateInputQuick reference for all properties: Table A-48

abbrev: MSI

MultistateInput (MSI) objects are used to

monitor a value with more than two discretestates, for example, a multi-speed fan. The

object represents the multistate values in the

control engine as integers (with associated

text descriptors), where they can be passed to

other control logic and/or be monitored for

alarm conditions.

As with Niagara AI, AO, BI, BO, and MSO1

objects, you can expose any MSI1 object in

the station as a BACnet object.

In addition to BACnet-type multistate

functions, the MSI object collects runtime(elapsed active time) and counts COS


limits, the object can be set to generate alerts

for both runtime levels and COS counts.





Note: Runtime accumulates during any

state except Off (first stateText entry).

The COS count increments only upon atransition from (or to) the Off state.


container).


Trigger Properties The MSI object has the standard input property, executeTrigger , (typically not used)




• resetElapsedActiveTimeTrigger —Any received trigger pulse clears theobject’s accumulated runtime (elapsed active time), resetting it to zero (0.0).




1. Some state limitations apply. See “stateText Considerations,” page 5-104.

Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInhibit



statusInput


eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

statusOutput


Input / Outpu t Property Reference for MSI Object(only input and output types, see Table 5-25 for all properties)



sInh statusInhibi t BooleanStatusType










sOut statusOutput IntegerStatusType






MultistateInput

5–101






(“activeTimeAlertLimit” value has been reached, or a “multiple” of this valueif “periodicAlerts’ is set to True).



CommandsFor a JDE user with “Command, Admin” privileges, the following object commands



(to-offnormal, to-fault, to-normal). Rarely required, see the “JDE Command”

section on page 5-11 for more information.

• resetChangeOfStateCount —This sets the changeOfStateCount propertyvalue to zero (0), clearing any COS count.







PropertiesTable 5-25 MultistateInput (MSI) object properties.


S t a t u s



— —



— — presentValue canbe written todirectly wheneverthe object is set tooutOfService.



null Trigger-typeinputs can beused to clear COSand runtimevalues. COS andruntime-relateddata is not visiblefrom a BACnetexposure.


integer value 0



null






MultistateInput

5–102

S t a t u

s ,

c o n

t .elapsedActiveTime Read Only: Shows the accumulated runtime

(elapsed active time) formatted inHr:Min:Sec.


00:00:00 COS andruntime-relateddata is not visible

from a BACnetexposure.timeOfActiveReset Read Only: Shows a date/timestamp forwhen the accumulated runtime (elapsedactive time) was last cleared.


null

C o n

f i g


normal,processor

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet Multi-state Input object to otherBACnet devices.

See “foreignAddress,” page 5-9, and also“stateText Considerations,” page 5-104.

0 to 4194302

or -1(not exposed)

-1 Must be a uniquenumber among allMultistateInputobjects in station.


defaultInput Read-Write: The input value used by theMSI object if its statusInput link is broken orassumes a status that includes “fault.”

Any one statedefined on theVisual tab.

Off Does not apply ifan input value isone of thefaultValues.

A l a r m

S e

t u p




inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked.


The inhibitTime is triggered by a transitionfrom false-to-true at the statusInhibit input.


• Whenever statusInhibit becomes false,alarm processing remains inhibited. Thealarm status of the object cannot change.This applies whether the object’sstatusFlags show a “normal” ok state or“inAlarm” and/or “unackedAlarm” states.


Hr:Min:Sec


A minimum valueof 1 second(00:00:01) is

recommendedwhenever thestatusInhibit inputis linked.

changeOfStateAlertLimit Read-Write: Number of COS occurrences

that generate a changeOfStateCount alert.

Positive integer 0



(Hr:Min:Sec)

00:00:00


A NotificationClass object using the samenumber should exist in theNotificationService object’s container.

0 to 8388607 0

Table 5-25 MultistateInput (MSI) object properties. (continued)







MultistateInput

5–103

A l a r m

S e

t u p ,

c o n

t .

periodicAlerts Read-Write: Determines if both COS countalerts and runtime alerts are periodicallygenerated each time the respective limit is

reached.

False, True False

alertText Read-Write: Text descriptor included ineither a COS count alert or runtime alert.

If left at the default hyphen (-), the Stationobject’s alertText is used.

Any text string,includingspaces.

-(hyphen)

alarmValues Read-Write: Defines which discrete statescorrespond to an object alarm condition.

Any states asdefined on the

Visual tab.

(none ofdefault:Off, On,

Fast)

If more than 8

stateText entries

are defined, only

the first 8 may be

used as either an

alarmValue or

faultValue.

faultValues Read-Write: Defines which discrete statescorrespond to a object fault condition.

Any states asdefined on the

Visual tab.

(none ofdefaults):Off, On,

Fast

V i s u a

l


stateText

Note: For alarm/fault

operation, only the first 8

stateText are supported.

Read-Write: Defines all possible discretestates by value-name pairs.

Each state has two fields:

• value —Unique integer, 0 to positive n.If BACnet compatibility is needed, statesmust be contiguous starting at 1.

• tag —Text to describe the associateddiscrete state. State descriptors are usedat the statusOutput, presentValue, alarmand fault values.

value: uniqueinteger, 0 to n.

tag: any textdescriptorneeded.

0 = Off 1 = On

2 = Fastdefault =

Error

State descriptorsare used in linkedMultistateLogobject collectionsand also candisplay at a linkedGxText object.

The “default” statesignals an invalidinput value.

E n g

i n e e r i n g




page 5-8.

— —

statusInhibit

(input sInh)



false : ok


(output sCnt)

Read Only: Current COS count. Available asa IntegerStatusType output.


0 : ok


(output sElpT)

Read Only: Current runtime (elapsed activetime), totaled in seconds. Available as aIntegerStatusType output.


0 : ok

statusInput

(inputsIn

)

Read Only: Current discrete state and statusat the statusInput.

<dis. state> :<status flags>

Off : ok

statusOutput

(output sOut)

Read Only: Current discrete state and statusat the statusOutput.

<dis. state> :<status flags>

Off : ok


which the object is assigned. For moredetails, see “securityGroups,” page 5-10.

General,

7 others

General

Table 5-25 MultistateInput (MSI) object properties. (continued)







MultistateInput

5–104

MultistateInput NotesThe MultistateInput (MSI) object is typically used to display a multistate value

received from an integration (shadow) object, offering configurable display text for

up to 8 discrete states. In addition, the object provides Niagara alarm capability and

the option to expose it as a BACnet Mulitstate_Input object.

The following main topics are explained on configuring a MSI object:

• Routinely Configured MSI Properties

• MSI Alarming Functions

• MSI Alert Notifications

RoutinelyConfigured MSIProperties

Among all properties on a MSI object’s property sheet, the two most typically

configured are:

• stateText (Visual tab)—Defines the object’s possible discrete (integer) states

and the associated text descriptors. A maximum of 8 states are fully supported

(including alarm/fault operation). Text descriptors appear at the object’s

outputs. They are also seen by users in linked GxText objects and in the

accumulated data of a linked MultistateLog.

See the next section “stateText Considerations” for additional details.

• defaultInput (Config tab)—Defines the statusOutput state produced

whenever a “fault” is received on the statusInput. Fault states are defined by

the faultValues property on the Alarm Setup tab.


configured from defaults. If more than 8 stateTexts are defined, only the first 8 can

be specified as an alarmState or faultState.

stateText Considerations

When exposing a Niagara MSI object as a BACnet object, be aware that you must

first edit its stateText property to be consistent with the BACnet definition.

Specifically, a zero (0) value is not allowed, plus all values must be contiguous.

Note A former issue with MSI alarming has been fixed starting in Niagara r2.3.4.

Previously, if an MSI was configured without a 0-value stateText entry (such as for

BACnet usage), alarm/fault operation would be “off by one.” This was fixed. Alarm

and fault operation could also fail if an MSI was configured with non-contiguous

stateText entries (illegal for BACnet export though); this was also fixed.

The stateText property is on the Visual tab (Figure 5-36).






MultistateInput

5–105

Figure 5-36 If exposing as BACnet, the MSI object must have stateText with contiguous values, and with no zero (0).

StateText Guidelines—If you follow these guidelines when assigning stateTextvalues, you can then expose an MSI object as BACnet.

1. Assign numerical states starting at 1 (not 0, as with a standard Niagara MSI).

For a two-speed object, for example, this means 1 = Off, 2 = On, and 3 = Fast,

vs. the numerical 0, 1, and 2 defaults used in stateText.

2. Assign state numbers contiguously (without skipping a number), as a BACnet

restriction. If alarming is needed, note that Niagara limits this to the first 8

stateText entries.

Note If you already assigned a foreignAddress value to expose the MSI object, but did so

before stateText complied with these guidelines, you will need to reassign the foreignAddress value (first to -1 and then back to the desired value).

stateText Default Feature—A Niagara MSI object provides a “default” state and

an associated text descriptor, which is used whenever a received input value does not

equal one of the assigned numerical states.

Typically, this indicates an error condition. In the stateText property, the default state

cannot be deleted. However, the text descriptor can be edited from “Error,” if needed.

Note There is no “default” state equivalent for a BACnet Multistate Input object.

This MSI object has had itsstateText property edited toremove the 0 value.

Other values were modifiedand added as needed, usingthe “StateText Guidelines” (below).

Default stateText valuesfor a Niagara MSI andMSO object include thenon-compliant “0” value.






MultistateInput

5–106

MSI AlarmingFunctions

An MSI object can be configured for alarm indication, and optionally, event (alarm)

notification. The object provides properties to define the alarm state(s), fault state(s),

alarm delay, and event notifications, using BACnet-type properties.

Note If more than 8 stateText entries exist, remember that only the first 8 are alarmable.

The MSI object can also generate “alerts” based on configurable limits for runtime

(elapsed active time) and change-of-state transitions. Alerts function the same as for

the BI object. See “BI Alert Notifications” on page 5-39 for more information.

The following subtopics apply to MSI alarming:

• MSI Alarm Detection

• MSI Alarm Notification

• MSI Alarm Inhibit

• MSI Alarm Delay

Figure 5-37 MSI objects have alarming functions with BACnet-type properties.

MSI Alarm Detection

Several properties on the Alarm Setup tab determine whether an alarm condition is

detected by the MSI object.

In order of relative importance, these properties include:

• alarmValues —State(s) in which the MSI is considered “offnormal”

(inAlarm). The object shape and its statusOutput are red during this state.

• faultValues —State(s) in which the MSI is considered in “fault” (inAlarm,

fault). The object shape and its statusOutput are orange during this state.


change occurs with the object. See “MSI Alarm Delay” on page 5-108.

inhibitTime and eventTriggerEnable areNiagara-only properties. See “MSI Alarm Inhibit”.


The alarmValues andfaultValues properties specifywhich states are “offnormal,”meaning alarm detection.







MultistateInput

5–107

MSI Alarm Notification

Alarming notification determines which type of alarm transitions are sent to the

Niagara alarming subsystem (Alarm Console). Events sent to the alarming subsystem

require user acknowledgment. Using the various recipient options for the target

notificationClass object, event notifications can also be routed to printers, e-mail

addresses, and APIs.



In the MSI object, properties on the Alarm Setup tab relating to alarm notification

are:




the alarming subsystem (to-offnormal, to-fault, to-normal). The default is allflags cleared, meaning that object alarms are not sent for notification. You must


on.








MSI Alarm Inhibit



Note Whenever the statusInhibit input is linked , the object’s inhibitTime property should

hold a defined value (not the default of 00:00:00 in Hr:Min:Sec).

Otherwise, the MSI object will not be capable of alarming.






MultistateInput

5–108



situations where a piece of equipment is turned off.

MSI Alarm Delay








Note Alarm delay is not applied on any transition to (or from) a fault state.Fault states are defined in the object’s faultValues property.




MSI AlertNotifications

In addition to (or instead of) alarming on particular discrete state(s), a MSI object is

also capable of generating “alerts,” based upon configurable limits for runtime

(elapsed activeTime) and/or number of COS transitions (change of states). Alerts are

sent to the Niagara alarming subsystem (Alarm Console), and require

acknowledgment. Like alarms, alerts are associated with a specified

notificationClass and can be routed to various recipients.

Whenever a logic false(inactive) is at the statusInhibit (sInh) input, the MSI objectcannot change status to (orfrom) an alarm condition.



inhibitTime = 00:00:30(30 seconds)






MultistateInput

5–109

MSI object alert subtopics include:

• Alarm Setup Properties for Both Alert Types

• Change-of-State (COS) Alerts

• Runtime (Active Time) Alerts

Alarm Setup Propert ies for Both Alert Types

Alarm Setup properties that apply to both types of MSI alerts (runtime and COS) are:

• alertNotificationClass —Must match a notificationClass object in the

notificationServices container. The default is 0, the same default for alarms.

• periodicAlerts —Determines whether runtime and COS alerts should repeat

upon each accrued interval of runtime or COS count. For example, if enabled

(True), and the COS count limit is defined at 150, a COS alert will be issued at

COS counts of 150, 300, 450, and so on. The default value is False.

• alertText —Any user-friendly text string wanted. Appears as a field in the alert

record for any runtime or COS alert, as a means of further description.

Change-of-State (COS) Alerts

Each state change to (or from) the “Off” state (meaning the first stateText entry)

increments the object’s COS counter by 1. For example, assuming the object’s COS

counter begins at 0, if the input changes from Off-to-On-to-Fast, then back to On and

finally to Off, the COS count will be 2—only transitions to or from Off are counted.

The COS count is available as the Status property changeOfStateCount. It is also

available as the statusChangeOfStateCount output (using integerStatus data species).

The COS count is resettable (to 0) for any JDE user with Admin-level command

rights. Also, the COS count can be reset using a Command object linked to the

object’s resetChangeOfStateCountTrigger input, if needed.

Properties on the Alarm Setup tab that apply to COS alerts include:

• changeOfStateAlertLimit —Integer value that defines the COS count that

should result in an alert notification. If periodicAlerts is set to True, an alert is


Runtime (Active Time) Alerts

Each MSI object automatically accumulates runtime, that is, elapsed active time.

Runtime accumulates for any defined state except the “Off” state (first stateText

entry). This time is available formatted in Hr:Min:Sec as the Status property

elapsedActiveTime. Runtime is also available as an output, as an integer value inseconds (using an integerStatusType data species).

Runtime is resettable (to 0) for any JDE user with Admin-level command rights.

Runtime can also be reset using a Command object linked to the object’s

resetElapsedActiveTimeTrigger input, if needed.

Properties on the Alarm Setup tab that apply to runtime alerts include:






MultistateInput

5–110

• activeTimeAlertLimit —Amount of runtime, in Hr:Min:Sec, that should

result in an alert notification. If periodicAlerts is set to True, an alert is


Examples Figure 5-39 shows two examples of MSI objects in use.

Figure 5-39 MultistateInput usage examples.

This MSI object receivesan integer value from aDMS shadow objectconfigured to poll for theCOND (condition) elementof an AI point.

The MSI object equates theinteger values to thecorresponding conditionstates.

In addition, different statescan be defined asalarmValues andfaultValues. This can beuseful when the output ofthe MSI object is linked to aGx object such as a GxTextor GxInteger. This permitsalarm indication by color(and optionally, if desired,by flashing).

In this example, an MSIobject is linked to aProgram object written to

link to Lon Devices with anNVO implemented withSNVT_lev_disc.

The Program object has aninput (sIn) usingLonLevDiscEnum (dataspecies) and an output ofIntegerStatusType.

In this case, the output ofthe MSI is using thedefaultInput (off), as thestatusInput is receiving the255 integer valuerepresenting a null value.

MSI object

On the Alarm Setup tab ofthe MSI object’s propertysheet, different states canbe defined as alarmValuesand faultValues.

The stateText property of the MSIis configured to match the CONDelement enumerations possiblefor DMS analog points.

DMS strings were used here, butany descriptors could be entered.

stateText values mustbe contiguous and no

higher than 7.

The defaultInput value is on theMSI object’s Config tab.

stateText is definedto represent theSNVT_lev_discstate enumerations.






MultistateOutput

5–111

MultistateOutputQuick reference for all properties: Table A-50

abbrev: MSO

MultistateOutput (MSO) objects provide a

prioritized multistate output signal to othercontrol logic. States are signaled as integers.

Typically, MSOs are used to provide control

of a multistate device, such as a 3-speed or

4-speed fan. A statusInput is available to use

for object alarming, based upon the received

multistate feedback signal.


any link) to an MSO object, commands at



cleared. The priorityArray input is now



output .

As with Niagara AI, AO, BI, BO, and MSI1

objects, you can expose any MSO1 object in

the station as a BACnet object.

In addition to BACnet-type multistate

functions, the MSO object collects runtime

(elapsed active time) and counts COS


limits, the object can be set to generate alertsfor both runtime levels and COS counts.





Note: Runtime accumulates during any

state except Off (first stateText entry). The

COS count increments only upon a

transition from (or to) the Off state.


container).


1. Some state limitations apply. See “stateText Considerations,” page 5-116.

Inputs


Outputs

priorityArray

statusInput

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInhibit



priorityArray

statusInput


eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

presentValue

statusOutput

prioritizedOutput


booleanStatusFbOut*


Input / Outpu t Property Reference for MSO Object(only input and output types, see Table 5-26 for all properties)






pIn priorityArray IntegerPriorityArrayType

sIn statusInput IntegerStatusTypeoutput eventTr eventTrigger TriggerType






present presentValue int

sOut statusOutput IntegerStatusType

pOut prioritizedOutput IntegerPriorityType

sFbOut statusFeedbackOutput IntegerStatusType

bsFbOut booleanStatusFeedbackOutput BooleanStatusType






MultistateOutput

5–112

Trigger Properties The MSO object has the standard input property, executeTrigger , (typically not used)














(“activeTimeAlertLimit” value has been reached, or a “multiple” of this value

if “periodicAlerts’ is set to True).As needed, these trigger-type inputs and outputs can be linked to other objects that


CommandsThe MSO object provides a right-click command menu with these commands

(default names are shown, these are modifiable using the commandTags property):

• Set —To set an output state at the Manual level (8). Default choices are Off, On,

or Fast. Requires “Command, Std” privileges.

• Auto —To clear an output state (e.g. Off, On, Fast) at the Manual level (8).

• Emergency Set —To set an output state at the Emergency level (1). Default

choices are Off, On, or Fast. Requires “Command, Emer” privileges.

• Emergency Auto —To clear an output state (e.g. Off, On, Fast) at the

Emergency level (1).




(to-offnormal, to-fault, to-normal). Rarely required, see the “JDE Command”

section on page 5-11 for more information.

• resetChangeOfStateCount —Sets the changeOfStateCount property value to

zero (0), clearing the COS count.

• resetActiveTime —Sets the elapsedActiveTime property value to 00:00:00

(Hr:Min:Sec), clearing the accumulated runtime.










MultistateOutput

5–113

PropertiesTable 5-26 MultistateOutput (MSO) object properties.


S t a t u s

objectType,




— —






null Trigger-type inputscan be used toclear COS andruntime values.

COS and runtimeproperties have noBACnet visibility ifthe object isexposed asBACnet (these arenot included instandard BACnetmultistate objectdefinitions).


integer value 0



null

elapsedActiveTime Read Only: Shows accumulated runtime(elapsed active time) in Hr:Min:Sec.

Time period upto 9999:99:99

00:00:00



null

P r i o

r i t i e s


Read Only: Shows defined states presenton each of the 16 priority level slots for thepriorityArray (pIn) input.

<state n> orauto,

levels 1 to 16

auto

1 to 16

relinquishDefault Read-Write: Defines the output state whenall 16 priority level slots have an “auto”. <state n> Off


False, True False

C o n

f i g


normal,output

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear asa BACnet Multi-state Output object to otherBACnet devices.

See “foreignAddress,” page 5-9, and also“stateText Considerations,” page 5-116.

0 to 4194302

or -1(not exposed)

-1 Must be a uniquenumber among allMultistateOutputobjects in station.


restartDisable Read-Write: Determines whether the outputis automatically set to the previous statefollowing a station restart (reboot) or powerfailure. If set to True, an “Off” state atmanual level (8) is issued following such anoccurrence.

False, True False






MultistateOutput

5–114

C o n

f i g ,

c o n

t .

minimumOnTime Read-Write: Upon a command from the“Off” state to any other state, results in thestate command to be stored at the Minimum

On Off priority level (6) for this time(Hr:Min:Sec).


00:00:00

minimumOffTime Read-Write: Upon a command from anyother state to the “Off state,” results in theOff command to be stored at the MinimumOn Off priority level (6) for this duration(Hr:Min:Sec).


00:00:00

perStateMinimumOnTime

Read-Write: Specifies whether theminimum On time is applied between allstates (True) or only from the Off state (firststateText entry) to any other state (False).

False, True False

interstartDelayTime Read-Write: Defines the time period(Hr:Min:Sec) that the output is held in the“Off” state following a command to anyother state. Used to prevent multiplesimultaneous starts. Applies to commandsat all priority levels except Emergency (1).


00:00:00

A l a r m

S e

t u p







• When statusInhibit goes false-to-true,alarm processing is delayed for the inhibittime.

• When statusInhibit goes true-to-false,alarm processing is delayed for three



Hr:Min:Sec


A minimum valueof 1 second(00:00:01) is

recommendedwhenever thestatusInhibit inputis linked.

Alarm processingcompares thestatusInput(feedback) state topriorityArray(command) state.


Positive integer 0

activeTimeAlertLimit Read-Write: Amount of runtime (elapsed

active time), in Hr:Min:Sec, that generates aruntime alert.

Any value up to

9999:59:99(Hr:Min:Sec)

00:00:00



0 to 8388607 0

Table 5-26 MultistateOutput (MSO) object properties. (continued)







MultistateOutput

5–115

A l a r m

S e

t u p , c o n

t .

periodicAlerts Read-Write: Determines if both COS countalerts and runtime alerts are periodicallygenerated each time the respective limit is

reached.

False, True False


If left at the default hyphen (-), the Stationobject’s alertText is used.


characters.

-(hyphen)

V i s u a

l


stateText Read-Write: Defines all possible discretestates by value-name pairs.


• value—Unique integer. If BACnetcompatibility is needed, states must becontiguous starting at 1.

• tag—Text to describe the associateddiscrete state. State descriptors are usedat the statusOutput, presentValue, alarmand fault values.

Unique integer,8 or more states

are allowed.

For BACnet, seethe value

description.

0 = Off 1 = On

2 = Fastdefault =

Error

State descriptorsare used in linkedMultistateLogobject collectionsand also candisplay at a linkedGxText object.


commandTags Read-Write: Defines the labels used to listcommands that appear on the right-clickcommand menu.

Default values for commandTags are:

• Set (manualSet)


• Emergency Set (emergencySet)

• Emergency Auto (emergencyAuto)

When the user selects a manualSet or

emergencySet command, a drop-downselection list of states shows the stateTextentries. For example, Off, On, or Fast.


spaces andnumerals.

Seedescrip.


E n g

i n e e r i n g



— —

statusInhibit

(input sInh)

Read Only: Current boolean state andstatus of the statusInhibit input.


false : ok


(output sCnt)

Read Only: Current value and status of theCOS count.



0 : ok


(output sElpT)

Read Only: Current runtime (elapsed activetime), totaled in seconds.


<seconds> :status flags 0 : ok Status propertyelapsedActiveTim

e shows this valuein Hr:Min:Sec.

statusInput

(input sIn)

Read Only: Current discrete state andstatus received on the statusInput.

<dis. state> :status flags

Off : ok

statusOutput

(output sOut)

Read Only: Current discrete state andstatus of the statusOutput.


Off : ok








MultistateOutput

5–116

MultistateOutput Notes

The MSO object is typically used for control of a multistate device or mode ofoperation. In some cases, a MSO object is used to directly control a physical output

of a remote device, represented by a shadow object.

RoutinelyConfigured MSOProperties

The three most typically configured properties for a MSO object are:

• relinquishDefault (Priorities tab)—Defines the MSO object’s output state

when all 16 of the priority-level slots at the priorityArray input have an “auto.”

The default value is Off (first stateText entry).

• stateText (Visual tab)—Defines the object’s possible discrete (integer) states

and the associated text descriptors that appear at the object’s outputs. Eight (8)

or more states can be defined. Descriptors are seen as options in right-click

“Set” and “Emergency Set” command menus, also in linked GxText objectsand in the accumulated data of a linked MultistateLog.

See the next section “stateText Considerations” for additional details.

• commandTags (Visual tab)—Defines how user commands appear on the

object’s right-click command menu. See “MSO Command Tags” on

page 5-118.



stateText Considerations

When exposing a Niagara MSO object as a BACnet object, be aware that you must

first edit its stateText property to be consistent with the BACnet definition.

Specifically, a zero (0) value is not allowed, plus all values must be contiguous.

The stateText property is on the Visual tab (Figure 5-40).

E n g

i n e e r i n g , c

o n

t .

prioritizedOutput

(output pOut)

Read Only: Current discrete state andpriority level of the prioritizedOutput.

<dis. state> :@ <pri. level>

Off : @ def


(output sFbOut)

Read Only: Current discrete state andstatus of the feedback supplied on thestatusInput. If statusInput is not linked, thisoutput always mirrors statusOutput.


Off : ok

booleanStatusFeedbackOutput

(output bsFbOut)

Read Only: Current command state as aboolean, either false if command is “Off” ortrue if any other command. Status followsstatusFeedbackOutput.


false : ok



General,

7 others

General








MultistateOutput

5–117

Figure 5-40 If exposing as BACnet, the MSO object must have stateText with contiguous values, and with no zero (0).

StateText Guidelines—If you follow these guidelines when assigning stateTextvalues, you can then expose an MSO object as BACnet.

1. Assign numerical states starting at 1 (not 0, as with a standard Niagara MSO).

For a two-speed object, for example, this means 1 = Off, 2 = On, and 3 = Fast,

vs. the numerical 0, 1, and 2 assignments used in stateText defaults.

2. Assign state numbers contiguously (without skipping a number). This

contiguous restriction is from BACnet.

Note If you already assigned a foreignAddress value to expose the MSO object, but did so

before stateText complied with these guidelines, you will need to reassign the

foreignAddress value (first to -1 and then back to the desired value).

Niagara stateText Default Feature—A Niagara MSO object provides a

“default” state and an associated text descriptor, which is used whenever a received

input value does not equal one of the assigned numerical states. Typically, this

indicates an error condition. In the stateText property, the default state cannot be

deleted. However, the text descriptor can be edited from “Error,” if needed.

Note There is no “default” state equivalent for a BACnet Multistate Output object.

Control RelatedPropertiesThe MSO object includes several Config properties that directly determine thecontrol operation of its main outputs (prioritizedOutput and statusOutput).

• restartDisable —Determines how outputs are set following a station restart,

host reboot, or power failure. Settings False and True are as follows:

– False (the default), restores outputs automatically to the previous state.

– If set to True, outputs are set to Off at the “Manual” level (8).

This MSO object has had itsstateText property edited toremove the 0 value.

Other values were modifiedand added as needed, usingthe “StateText Guidelines” (below).

Default stateText valuesfor a Niagara MSI andMSO object include thenon-compliant “0” value.






MultistateOutput

5–118

• minimumOnTime —Defines the time period in which any “non-Off”

command at the “Minimum On Off” priority level (6) will exist, as a result of

any command transition from Off to that state. This can prevent equipment

short-cycling.

• minimumOffTime —Defines the time period in which an Off command at the

“Minimum On Off” priority level (6) will exist, as a result of any commandtransition from “non-Off” to Off. This can prevent equipment short-cycling.

• perStateMinimumOnTime —Specifies whether the minimum On time is

applied between all states or only from Off (0) to any other state.

– False (the default), minimum On applies only from Off to any other state.

– If set to True, minimum On applies to all transitions between states.

• interstartDelayTime —Defines a delay period, in seconds, before a command

from Off to any other state becomes effective. Does not apply with a command

to Off. Applies to all priority levels except Emergency Manual (1). The default

value of zero (0) means no delay time.

You can use this property to prevent multiple simultaneous starts to

MSO-controlled loads, which might otherwise cause energy (demand) spikes.

MSO CommandTags

MSO objects are typically configured with custom command “labels,” using the

commandTags property, on the Visual tab of the property sheet (Figure 5-41).


right-click menu than the default values, for example, “Change Speed” vs. “Set.”

In addition, you can clear any tags to make those commands unavailable

(Figure 5-41). This is often done for emergency-level commands, for example.







MultistateOutput

5–119

MSO AlarmingFunctions

Alarm detection for a MSO object requires a separate link to a statusFeedback input,

which receives the “actual” integer value of the controlled device. This state is

compared against the current “controlled/commanded” state, and can result in an

alarm (if the two integer values are different). See Figure 5-42.

The following subtopics apply to MSO alarming:

• MSO Alarm Inhibit

• MSO Alarm Delay

• MSO Alarm Notification

Often, another input is linked as well: statusInhibit (sInh), coming from the

controlling source. See the “MSO Alarm Inhibit” section on page 5-120.

Note The MSO object can also generate “alerts” based on configurable limits for runtime

(elapsed “non-Off” time) and change-of-state transitions. MSO alerts operate the

same as for BinaryInput (BI) objects. See “BI Alert Notifications” on page 5-39.

Figure 5-15 shows the grouping of Alarm Setup properties for a MSO object.

Figure 5-43 MSO objects have alarming functions with BACnet-type properties.

Figure 5-42 MultistateOutput alarming.

An MSO alarm condition iswhen the control commandstate is different from thefeedback state at the

statusInput input(feedback).


An alarm occurs uponany mismatch betweencommand and feedback.

inhibitTime and eventTriggerEnable areNiagara-only properties. See “BO Alarm Inhibit”.

“Alert” properties define alert notification,which includes change-of-state alerts andruntime (“non-Off” time) alerts.

timeDelay specifies an alarm delay period forany sensed alarm condition.







MultistateOutput

5–120

MSO Alarm Inhibi t




MSO Alarm Delay









momentary change in the received integer (state) value. Typically, when both an

alarm delay and alarm inhibit is used, timeDelay is less (shorter) than inhibitTime.

MSO Alarm Notification

Alarming notification determines which type of alarm transitions (events) are sent to


subsystem require user acknowledgment. Using the various recipient options for the

target notificationClass object, event notifications can also be routed to printers,

e-mail addresses, and APIs. If the MSO object is exposed as a BACnet object,




Figure 5-44 MultistateOutput statusInhibit input and inhibitTime property.

The statusInhibit input istypically linked to the samesource that is controllingthe MSO.

When the MSO iscommanded from Off toany other state, any alarmstatus change is inhibitedfor the specified

inhibitTime, in seconds.

When commanded to Off,any alarm status change isinhibited for 3 times theinhibitTime, in seconds.

priorityArray input linkfor control command


Example:inhibitTime = 30 (seconds)

When commanded to Off fromany other state, the alarm inhibitdelay will be 90 seconds.

statusInhibit (sInh) link (BooleanStatusType data species)






MultistateOutput

5–121

In the MSO object, properties on the Alarm Setup tab relating to alarm notification

are:




the alarming subsystem (to-offnormal, to-fault, to-normal). The default is all



on.













MultistateOutput

5–122

Examples Figure 5-45 shows two examples of MultistateOutput objects in use.

Figure 5-45 MultistateOutput examples.

This MSO object providesa command menu forsetting the HVAC mode of a

LON device. The MSOoutput is linked to aProgram object, whichproduces an enumeratedoutput.

The command menuincludes the 13 possibleenumerations forSNVT_hvac_mode.

The Program object has aninput (sIn) usingintegerStatus (dataspecies) and an output ofLonHvacModeEnum.

The output of the Programobject is linked to an NVI ofthe LON device that usesSNVT_hvac_mode.

This MSO object wascreated in a DMSintegration to command aDMS 2S point (2-speedstart-stop). When using thePointListManager to create

a “Cmd:Write,” both theDMS shadow object andthe MSO are createdtogether, with linksbetween them alreadyestablished.

In this example, an MSIobject has been added todisplay “Off”, “On” and“Fast” for the integer outputproduced by the DMSshadow object.

MSO object’s right-click

command menu

LON device with NVI usingSNVT_hvac_mode

Program object

The MSO object’s

stateText propertydefines the integeroutputs and associatedcommand states.

Shadow object forDMS 2S pointMSO object

Right-clickcommand forMSO object






MultistateOverride

5–123

MultistateOverrideQuick reference for all properties: Table A-51

abbrev: MSOvrd

A MultistateOverride (MSOvrd) object

provides a prioritized, discrete-level(Off/On/Fast) output signal that is controlled

from a right-click command menu.


for a specified duration, canceling an

override, and selecting the override state.


configurable to any level (from 1 to 16). In

addition, text descriptors for the different

discrete states are editable. This allows the

right-click command menu to show

commands as needed, for example, “override

Occupied” and “override Standby” instead of

“override Off” and “override Fast.”


container).


Trigger Properties The MSOvrd object has the standard input property, executeTrigger , (typically not


• overrideTrigger —Any received trigger pulse starts an override, at the

configured overrideValue (state), overrideTime, and priorityForWriting.


example, a Command object. This would allow a user to start an override at the

configured overrideValue (state), but not any other states. The linked Command

object would also not allow a user to cancel an override, or change its duration. An

override would be started each time a trigger pulse is received at this input.

CommandsFor any user with “Command, Std” privileges, an MSOvrd object provides a

right-click command menu with these commands:

• override —To start an override and specify the duration, in minutes.


• setOverrideValue —To select the discrete state of the override. A drop-down

selection list provides the available discrete states.

Inputs


Outputs


prioritizedOutput

Inputs


Outputs

executeTrigger

overrideTrigger

inOverride

statusInOverride

prioritizedOutput




override overrideTrigger TriggerType



pOut priori tizedOutput IntegerPriorityType






MultistateOverride

5–124

PropertiesTable 5-27 MultistateOverride (MSOvrd) object properties.


S t a t u s

objectType,




— —



False, True False boolean data species.

C o n

f i g


normal,input





Any prioritylevel,

from 1 to 16

ManualOperator

(8)




up to 32-bitlimit.

60 This override time isdisplayed (and can beadjusted) each timean override is issued.

overrideValue Read-Write: Defines the last given overridestate. This value was issued at the prioritylevel defined in the priorityForWritingproperty.

Note: Any pulse received at theoverrideTrigger causes an override at this

state (one of the stateText values).

(any of thestateText tags)

Off Editing this from theproperty sheettypically makes nodifference (theobject’s secondarycommand menualways allows

overrides to anyspecific state).

V i s u a

l


stateTextvalue,tag

Read-Write: Defines all possible discretecommands by value-name pairs.

Each command state has two fields:

• value—Unique integer. If BACnetcompatibility is needed, states must becontiguous starting at 1 (1 to 8, max.).

• tag—Text to describe the associateddiscrete state. Descriptors are used in the“setOverrideValue” command menu.

Uniqueinteger, with up

to 8 statesallowed.

For BACnet,see the valuedescription.

0 = Off 1 = On

2 = Fastdefault =

Error

State descriptors areused in the right-click(secondary) popupmenu to“setOverrideValue.”


E n g

i n e e r i n g



— —

statusInOverride(input sInOv)

Read Only: Shows if an override is activeand also the status of the object.


Inactive,Active

status flags

Inactive :ok

booleanStatusTypedata species






MultistateOverride

5–125

MultistateOverride NotesThere are two basic ways to use an MultistateOverride object:



Directly Available The right-click menu for an MultistateOverride object provides the user a list of


• Initiate an override, specifying the duration in minutes.


• Change the state for an override (setOverrideValue).

Note A setOverrideValue command does not affect an override in progress.

If changed, the duration of override and/or the override value are stored in the

object’s Config properties. These values become the defaults for the next command,and are seen when the command’s popup control appears.


In some scenarios, direct access to a MultistateOverride object may provide too much

user control for changing override parameters (duration times and override states). In

this case, linking a Command object to the object’s overrideTrigger may be better.


directly to the MultistateOverride object). This allows the initiation of an override,

but no other control (including canceling an override). The outputTrigger text

property of the Command object should be given a descriptive label for the

configured override action (Figure 5-8).

E n g

i n e e r i n g ,

c o n

t . prioritizedOutput(input pOut)

Read Only: Shows the state and prioritylevel currently on the prioritizedOutput.


Inactive,Active

@ <pri. level>

Inactive :@ def

IntegerPriorityTypedata species



General,

7 others

General

Table 5-27 MultistateOverride (MSOvrd) object properties. (continued)







MultistateOverride

5–126

Figure 5-46 Control from a Command object allows override initiation but no other actions.


remaining override time. Two links are required to the MultistateOverride object.

Figure 5-47 RemainingOverrideTime object in Local Library (tridiumx/lib/programs/hvac).






Two links are required between theAnalogOverride object and the Programobject (RemainingOverrideTime):









PeriodicTrigger

5–127

PeriodicTrigger Quick reference for all properties: Table A-63

(abbrev: Ptrig)

PeriodicTrigger objects are one of several

trigger-type objects. This object provides asingle trigger output that fires each time a

continuously repeating interval elapses. A

typical use is to perform trigger-initiated

functions with a log-type object (do clear, do

archive).


DateTimeTrigger and Command objects.


container).

Resource CountRange

36 to 46

Trigger Properties The Ptrig object has the standard input property, executeTrigger , (never used) plus an

additional trigger-type output :

• trigger —The “business end” of this object. Fires at the continuously repeating

interval defined by the Config property triggerPeriod.

The purpose of this object is to link this output to other object’s trigger-type inputs,

as needed, to perform a periodic function.

CommandsFor a user with “Command, Std” privileges, the object provides the following

right-click command:

• reset —Restarts the periodic interval (note this does not fire the trigger output.)

Properties

Inputs


Outputs

(none shown) (none shown)

Inputs


Outputs

executeTrigger trigger

Property Quick Reference for PeriodicTrigger Object(only input and output types, see Table 5-28 for all properties)



output trigger trigger BooleanPriorityType

Table 5-28 PeriodicTrigger object, important properties.


S t a t u s


See Table 5-3 on page 5-8 for information onthese common object properties.

— —

nextTriggerTime Read Only: Shows a date/timestamp for the

next calculated trigger pulse.

C o n

f i g

executionParameters See “execution Parameters,” page 5-9. — normal,processor



triggerPeriod Read-Write: Repeating interval (Hr:Min:Sec)at which the trigger output fires.

Interval up to99999:99:99

1:00:00(hourly)






PeriodicTrigger

5–128

PeriodicTrigger NotesThe PeriodicTrigger can be used whenever a constantly repeating command is

needed at one or more objects that have triggerType inputs. Likely candidates include

log type objects, and/or log-service objects.

For example a PeriodicTrigger can be linked to the “doArchiveTrigger” input of the

AuditLogService, to force an archive at some regular, repeating interval.

V i s u a

lposition Read-Write: See “position,” page 5-9. — — —

E n g

i n e e r i n

g


See Table 5-3 on page 5-8 for information onthese common object properties. — —



General,

7 others

General

Table 5-28 PeriodicTrigger object, important properties. (continued)







Totalizer

5–129

Totalizer Quick reference for all properties: Table A-75

abbrev: Total

A Totalizer (Total) object totalizes the value

received on a single floating-point input.Totalization can be configured to use either a

minutely or hourly basis.

A Totalizer object is typically linked to a float

value that represents a rate, such as electrical

power (kW) or material flow (for example,

gallons per minute). The Totalizer then

accumulates consumption in kWh or gallons.


container).


Trigger Properties The Totalizer object has the standard input property, executeTrigger , (typically never


• resetTotalTrigger —Any received trigger pulse clears the object’s current

statusTotal output, resetting it to zero (0). The object restarts totalizing.

In addition, the Totalizer provides a trigger-type output :

• updateOutputTrigger —Fires each time the statusTotal output value changes.

This output can be linked to any trigger-type input, as needed.

CommandsFor a JDE user with “Command, Admin” privileges, this menu bar command is

available (the object’s property sheet must be displayed):

• Commands > resetTotal —Clears the value at the statusTotal output, resetting

it to zero (0.0). The object starts totalizing again.

Properties

Inputs


Outputs

statusInput statusTotal

Inputs


Outputs

executeTrigger

statusInput

resetTotalTrigger

statusTotal

updateOutputTrigger

Property Quick Reference for Totalizer (Total) Object(only input and output types, see Table 5-29 for all properties)




resetTr resetTotalTrigger TriggerType


updateTr updateOutputTrigger TriggerType

Table 5-29 Totalizer object properties.


S t a t u s objectType,statusFlags,

description,presentValue,

See Table 5-3 on page 5-8 for informationon these common object properties. — — presentValue can bewritten.

C o n

f i g


normal,input








Totalizer

5–130

Totalizer NotesThe Totalizer object is typically used for totalizing energy, material consumption, and

refrigeration (BTU) tonnage. Figure 5-48 shows an example of a Totalizer object

used for totalizing ton-hours.

Figure 5-48 Example Totalizer object for BTU Tons-hours calculation.

C o n

f i g ,

c o n

t .

defaultInput Read-Write: Acts as the statusInput valuewhenever that input has status flags ofeither fault or down, or if it is not linked.

valid float 0.0

units Read-Write: Engineering units for thetotalized output, for display purposes.Choose from a logical grouping, then aspecific unit.


Other,no_units

For selections see“About Units,” page5-6.

totalizationInterval Read-Write: Defines the interval oftotalization. Typically, this relates to the timeinterval of the rate input.

minutely,hourly

minutely For power inputs ofkW or MW, choosehourly.

startTime Read-Only: Shows the date/timestamp forwhen the current totalization period started(time of the last resetTotal command).

null

V i s u a


decimalFormat Read-Write: Sets decimal position of theoutput from 0 to 6 places, and optionally

force (+) sign for positive values.

0 to 6,


2,

no (+) sign

E n g

i n e e r i n g



— —

statusInput(input sIn)

Read Only: Current float value and status atstatusInput.


0.0 ok

statusTotal(output sTot)

Read Only: Current calculated float valueand status output at the statusOutput.


0.0 ok



General,

7 others

General

Table 5-29 Totalizer object properties. (continued)


This Totalizer objectreceives a BTU Tonsvalue calculated by aProgram object.

The totalizationIntervalis set to minutely, andthe output (units) are inton_hours.





CHAPTER

6–1

6

Apps Objects

This chapter describes each of the standard Niagara Apps objects, that is, those

provided in the apps folder of the tridium JAR file. General information on apps

objects is provided first, as follows:

• About Apps Objects

– BACnet Heritage

– Selecting Apps Objects

• Common Apps Object Things

– Trigger Properties

– Common Apps Object Properties

• Log Objects

– Logs (Samples)

– Log Storage

– Log Object Views

– Common Log Properties

Individual apps object descriptions follow, arranged alphabetically as follows:

• AdminTool

• AnalogLog

• BinaryLog

• Calendar

• IntegerLog

• MultistateLog

• Program• Schedule

• StringLog





Chapter 6 Apps Objects

About Apps Objects

6–2

About Apps ObjectsApps objects provide a variety of system functions that are linkable to a station’s

control logic, including:

• Global schedule operation of binary-controlled loads, including holiday andspecial-event definitions.

• Data-logging of various values and status originating from object outputs.

• Custom control routines, using a “design-your-own” (Program) object.

• Special Niagara station utilities.

All of these things can be needed when engineering a building automation system.

Apps objects are executed in the station by the “control engine” (managed by the

ControlEngineService ), along with all “control” objects. Most Niagara stations are

engineered to use some control and apps objects, in addition to other child-only

(primitive) objects. These other objects include shadow objects and Gx objects.

BACnet Heritage

Selected Niagara apps objects are implemented like the equivalent BACnet objects

(used to model data in BACnet devices). Because a Niagara station is inherently

capable of being integrated as a BACnet device, this feature allows it to expose these

objects directly as BACnet objects, namely:

• Calendar objects

• Schedule objects

In a BACnet integration, the BACnet service makes the Niagara station a BACnetserver to provide client access to these objects (to other networked BACnet devices).

At the same time, the BACnet service allows the station to have client access to

BACnet objects in remote BACnet devices, through the use of special BACnet

shadow objects. Currently, however, Calendar and Schedule objects can only be

exported (no shadow objects for foreign BACnet Calendar and Schedule objects).

Refer to For detailed information on Niagara and BACnet, refer to the Niagara BACnet

Integration Reference document.




About Apps Objects



Selecting Apps Objects

Until you become familiar with the different Niagara apps objects, it may not be

immediately clear which types provide common functions. The table below crosses

some standard system routines to the appropriate object type.

Application Routine Needed Niagara Apps Object Used

• Logging or trending of any:

– Floating-point value AnalogLog

– Boolean state (On/Off, etc.) BinaryLog

– Integer value IntegerLog

– Multistate value (Off/On/Fast, etc.) MultistateLog

– String (alphanumeric text, or text

results of most any type output)

StringLog

• Holiday definitions Calendar

• Scheduling control Schedule

• Search and replace routine for propertyvalues in the stations database.

AdminTool

• Any custom application routine or controlfunction routine not available by using

other apps objects or standard controlobjects.

Program






Common Apps Object Things

6–4

Common Apps Object ThingsLike control objects, apps objects have properties common to all Niagara object

types, such as the status properties “objectType” and “description”. Most apps object

types also include common properties that affect the object’s execution, security

(user access), and other common parameters. Also, when using the JDE, each appsobject has a “dump” command for debug purposes.

Rather than cover these things in detail for each object type, they are explained in this

section. Several apps object types are log objects, and so have common properties.

See the following the “Log Objects” section on page 6-7.

TriggerProperties

In this chapter, the description for each apps object type includes a “Trigger

Properties” section that lists and describes the object’s available trigger properties.

executeTrigger—Except for the AdminTool and Program object, every apps object

has a linkable input property, executeTrigger. This input is rarely used . The intention

of this input is to have the object execute (once) each time a trigger pulse is received.

In this case, you would set the object’s configuration property execution Parameters,

“freq” field from the default setting of “normal” to “on_trigger”. Otherwise, the

object would continue to execute during each ongoing cycle of the control engine

(ControlEngineService), and it would ignore any received trigger pulses.

This is mentioned only because the executeTrigger input is shown for each object

type in the “All Inputs / Outputs” figure. However, be aware that for most apps

objects, this input has limited or no application.

Debug

Command

If you have “Command, Admin” privileges, this menu bar command is available in

the JDE for any apps object (you must have the object’s property sheet displayed):


including the objects swid, handle, name, parent, properties and values, and links.

Note Typically, the dump command is used only during development. The JDE right-click

command Go > Report is a more flexible utility that provides similar information.

Various apps object types have other available commands, both right-click types

(which are available when accessing the station using a browser), and JDE accessible

commands. Each object’s available commands are listed in subsequent descriptions.







Common Apps Object Properties




Table 6-1 Common propert ies for al l apps objects.


S t a t u s

objectType Read Only: The apps object type. Bydefault, a newly added object uses thisstring in its name (until renamed).

The full string for the object type is shown,for example, AnalogLog or Calendar.


For most object types, astandard abbreviation forthat type appears insidethe object’s shape (nearthe top).

This abbreviation isnoted in the individualdescriptions for eachapps object.

statusFlags Read Only: Current state of the object’s

status flags. A “normal” state (no flags set)is where the status flags value is “ok”, andthe object’s color is gray.


• down—The station is down or offline.The object ‘s shape and outputs areyellow.

either:

ok (no flags)

or

down

ok Unlike many control

objects, apps objects donot have alarm states,nor do they “assume”alarm or fault conditionsfrom linked inputs.

description Read-Write: Permits a user-defined textdescriptor for describing the object. Anyprintable characters, including spaces andmixed case characters, are allowed.

See description — Not available for anAdminTool object.

For a log object, ifdescription is entered, itappears in the object’sLogChart title.

Also used to list the log inthe station’s log indexand in the Log Selector .

C o n

f i g

executionParameters

Read-Write: Defines the frequency andorder for the object as it is executed by thestation’s control engine.

• freq (frequency)—Specifies how often theobject is executed. For most apps objects,the default frequency (normal) isacceptable. For Calendar and Schedule

objects, frequency is fixed at minutely.

• order—Specifies the order of execution ineach cycle. On each cycle of the control

engine, objects specified as inputs areprocessed first, then processors next, andlastly the outputs.

By default, all apps objects default to theprocessor order.


minutelyon_trigger

order:input

processor output

freq:normal

order:<see

descrip>

This property is notavailable (nor applies to)an AdminTool object.

Usually, default valuesare recommended.

Frequency selectionsare exclusive.

For example, ifon_trigger is selected,the object will execute

only if the inputexecuteTrigger is linkedand a trigger pulse isreceived on that input.

For related details, seeControlEngineServiceConfig property“executionFrequency”.







6–6

C o n

f i g ,

c o n

t .

foreignAddress Read-Write: BACnet usage only. Exposesthe Niagara object as a BACnet object.

Note: Currently, this property has apractical application only for apps objecttypes Calendar and Schedule (as well ascontrol objects AI, AO, BI, BO, MSI, MSO).

For these object types, a valid value is from0 to 4194302 (BACnet maximum), or -1if not exposed to BACnet.

SeeDescription

If assigned, this

number mustbeunique in the

station within

an object type

(Calendar,Schedule, etc.)

-1

(not used)

Not shown for anAdminTool object.

Before using, the

BACnet service must beinstalled and configuredin the station.


V i s

u a

l





(container)object’s “size”

property value.


when theobject is

firstcreated.

Typically, you don’tmanually enter positionvalues, but use themouse to drag the objectas needed on the JDE

Workspace.


E n g

i n e e r

i n g

minExecuteTime Read-Write: Can show the object’sminimum execution time, in mil liseconds.

Shows MAX_VALUE if “profileNodes” in theControlEngineService was not previouslyset (since the last station start).


Providing that theControlEngineServicewas set to“profileNodes”, theseproperties show theobject’s executionstatistics. Typically, youdo not leave theControlEngineServiceconfigured this wayexcept for brief periodsto collect these values.

This properties are notavailable (nor apply to)an AdminTool object.




averageExecuteTime


Shows 0.0 if “profileNodes” in theControlEngineService was not previouslyset (since the last station start).



Any desiredtext string for

servlet/API use.

<blank>

S e c u r i t y


Refer to the “Security Tab” section onpage 1-20 (Station object UserAdmin topic)for more details on how securityGroupssettings apply.


•General•HVAC

•Security

•Life Safety

•Group 4

•Group 5

•Group 6

•Group 7


Table 6-1 Common properties for all apps objects. (continued)








Log Objects

Five of the apps object types are log-type (log) objects, including the following:

• AnalogLog

• BinaryLog• IntegerLog

• MultistateLog

• StringLog

These objects are globally managed by the station’s LogService. Each log object type

has a group of common status and config properties. All log objects except the

StringLog also feature graphical views for accessing log data.

The following topics apply to all of the log objects:

• Logs (Samples)

• Log Storage• Location of Log Objects

• Log Object Views

• Common Log Object Properties

Logs (Samples) Each log (sample) recorded by a log object has three main parts:

• timestamp —When the sample was recorded. The format is:

<time> <day-mo-year> <time zone>, for example:

12: 07: 49PM 25- J un- 2001 EDT (see section “Timestamp notes”)

• value —The value, state, or string at the log object’s statusInput.

• status —The corresponding input status at the statusInput.

(If a StringLog, status is not recorded—only timestamp and value.)

These appear as columns in the object’s list of recorded logs, shown in its LogTable

view. The LogTable is accessible from both JDE and a Web browser (Figure 6-1).

Figure 6-1 LogTable view (JDE and browser) lists logs with timestamp (tstamp), value, and status.

JDE LogTable view

In the case of anAnalogLog (as here),

values are formattedusing the object’sdecimalFormat setting.

Browser LogTable view

AnalogLog values do not use theobject’s decimalFormat setting, butdisplay the full decimal component.







6–8

Timestamp notes

When viewing logs, the timestamps (date, time, and time zone) always reflect the

serving Niagara host’s time—that is, the station with the log objects. For example, a

BinaryLog object in a station in New York (EST, or Eastern Standard Time zone)

showing On/Off times of 8:00AM/5:00PM would have a LogTable similar to:

The time zone is actually stored as an integer “offset” from UTC (Universal Time,

Coordinated)—specific to the Niagara host that contains the log. Note that UTC “0”

(no offset) is equivalent to GMT (Greenwich Mean Time). This integer is visible

when saving log data in a pure text format, such as “text/comma-separated-values.”

For example, if saving the BinaryLog data above as “text/tab-separated-values,” theinteger offset (for time zone) is “-5” (EST is five (5) hours behind GMT).

2002- 03- 15T08: 00: 00. 78-5 t r ue On ok2002- 03- 15T17: 00: 12. 78-5 f al se Of f ok2002- 03- 16T08: 00: 10. 79-5 t r ue On ok2002- 03- 16T17: 00: 12. 78-5 f al se Of f ok

In the United States, these UTC offsets appear as:

• -5 for EST (Eastern Standard Time)

• -6 for CST (Central Standard Time)

• -7 for MST (Mountain Standard Time)

• -8 for PST (Pacific Standard Time)

Archive Timestamps—Archives, meaning logs that have archived to a Web

Supervisor station (see “Archive (SQL) Storage”) have a timestamp reflecting the

archive host’s time zone. In many cases the Web Supervisor (archive host) and remote

stations are in the same time zone. However, be aware that if a remote station is in a

different time zone from the Web Supervisor, that archive data from it appears with a

timestamp relative to the Web Supervisor.

For example, if the BinaryLog object (above) in New York archived remotely to a

Web Supervisor running in Los Angeles (PST, or Pacific Standard Time zone), the

archive data would be relative to PST, and look like:

tstamp value status

8: 00: 10 15- Mar - 2002 EST On ok

17: 00: 12 15- Mar- 2002 EST Of f ok

8: 00: 10 16- Mar - 2002 EST On ok

17: 00: 14 16- Mar- 2002 EST Of f ok

TSTAMP VALUE STATUS

5: 00: 10 15- Mar- 2002 PST t rue ok

14: 00: 12 15- Mar - 2002 PST f al se ok

5: 00: 10 16- Mar- 2002 PST t rue ok

14: 00: 14 16- Mar - 2002 PST f al se ok







Order of Logs

The LogTable view for any log object lists logs from top-to-bottom chronologically

(Figure 6-2). The oldest logs are at the top; the newest are at the bottom.

Figure 6-2 Oldest logs are at the top and most recent logs at the bottom.

The same ordering occurs when viewing archived log data, that is, logs archived to

the supervisor station (Figure 6-3). See “Archive (SQL) Storage” on page 6-10.

Figure 6-3 Archived log data also shows oldest logs first.

Note A maximum of 2500 archived logs can be viewed. A warning appears on any request

where more than 2500 log samples exist, as shown in Figure 6-3.

Oldest log

Newer logs

JDE DatabaseBrowser access

Browser archive access







6–10

Log Storage A log object collects and stores logs locally, in its own log buffer . The buffer

designates an area of RAM allocated by the station for logs. It is important to note

that the station treats buffered logs as critical data, and periodically stores them as

persistent data—in fact, as part of the station’s runtime database. Whenever a Niagara

station is backed up, this includes the contents of all log objects’ buffers.

Note The LogChart view (available for any AnalogLog, BinaryLog, IntegerLog and

MultistateLog), and the LogTable view (available for any log object) shows log data

from logs stored in the object’s log buffer . All logs in the buffer are included.

Archive (SQL) Storage—In addition to its log buffer, each log object can archive

its logs to an application database, meaning the SQL relational database running on

the supervisor station. The station’s LogService performs this archive routine.

Each log object has an “archiveSetup” config property that specifies archive times,

such as “nearFull” and “daily” (plus a trigger input to cause an archive). When a log

object archives its logs, its log data is “pushed” to the SQL database on the supervisorstation. Log samples in the object’s log buffer remain unaffected. Refer also tothe

“DatabaseService” section on page 4-15 and the “LogService” section on page 4-30.

Note If a job has one or more stations configured with the PollArchiveService (Niagara

module “multisite”), log data in remote stations can be “pulled” to its SQL database.

To use this feature, log objects require the “polled” flag to be set in their

archiveSetup property (along with any other archive flags). For more details on this

service, refer to the “PollArchiveService” section on page 4-40.

Buffer Size and Resource Count

The size of any log object’s buffer is configurable (property bufferSize). The default

buffer size is 60, with an allowable range from 1 to 11,5201.

Caution A log object consumes a station “resource count” in direct proportion to its

configured bufferSize. This applies whether or not any log samples (logs) exist.

A log object with the default bufferSize (60) consumes a resource count of

approximately 120 to 150 (this allows 60 to 90 for the object’s overhead).

The same object assigned a bufferSize of 1000 consumes a resource count of 1060

to 1090 (note the “one-to-one” increase in bufferSize to resource count).

If bufferSize is set to the 11,520 maximum, the object consumes a whopping 11,600

resource count! Obviously, this is not desirable, especially in a JACE-4/5 stationdatabase that may be limited to a total resource count of 300,000.

Resource count is less of an issue when engineering a station database for a JACE-NP

or a Web Supervisor. However, other considerations apply to locating log objects,

especially in multi-station jobs. See the next section, “Location of Log Objects.”

1. Niagara release 2.2 bufferSize limit is 11,520. In release 2.1, the limit is 1500.







Location of LogObjects

In a typical multi-station job, decisions must be made where to locate log objects.

Essentially, there are two competing philosophies:

• Log objects can reside in the Web Supervisor (Web Supervisor Storage).

• Log objects can reside in the JACE controllers (JACE Controller Log Storage).

Each approach has its advantages and compromises, explained below.

Web Supervisor Storage

The Web Supervisor is typically engineered to provide the browser user interface,

serving up GxPages. It also runs the DatabaseService and archives locally, as it

contains all log objects.

This method requires an external (interstation) link from each Web Supervisor log

object to the source control object in JACE controllers. These link types are

supported for all log objects (AnalogLog, BinaryLog, IntegerLog, MultistateLog,

and StringLog).

Advantages—The following advantages exist with Web Supervisor log storage:

• JACE controllers do not require the WebUIService to see logs in chart form,

because the buffered log data is being served up by the Web Supervisor.

• JACE-4/5 controllers, in particular, have more operating RAM and object

space without the addition of log objects.

• Browser users are not required to “sign on” when accessing log data sourced

from a JACE, because the log data resides locally in the Web Supervisor.

• Exposed (public) IP addresses are not required for each JACE controller to

view log data from an Internet connection—only for the Web Supervisor.

Compromises—These compromises exist with Web Supervisor log storage:• For a large job with many JACE controllers, the need for a huge amount of log

objects in the Web Supervisor may require a server-class PC to operate

efficiently. In particular, RAM and CPU resources may be severely tested.

JACE Contro ller Log Storage

In a distributed log system, typically the Web Supervisor is still engineered to provide

the browser user interface, serving up GxPages. It also runs the DatabaseService and

is the archive supervisor, typically for all log objects in the system. However, each

JACE controller contains its own log objects.

Browser user access to log data can be provided, for example, from Web Supervisor

GxPages. In the case of an AnalogLog, this can be done with a link between a Gx

object and the statusOutput of the log object. For other log object type (which do not

have a linkable output), a url can be entered in the Gx object’s hyperlinkUrl property.

Advantages—The following advantages exist with JACE controller log storage:

• Logging is not dependent on network connectivity. If, for some reason,

connections are lost, logging continues uninterrupted.







6–12

Compromises—These compromises exist with JACE controller log storage:

• A browser user will need to “sign on” to a JACE before viewing its log data,

following a link from a Web Supervisor graphic.

If user access is needed from the Internet, this means that each JACE must have

an exposed IP address, or some other proxy-type mechanism on the JACE

LAN must be in place, such as a VPN (virtual private network).

• Each JACE with logs that are exposed to users requires the WebUiService, in

order for the log data to be displayed in the graphical (LogChart) manner.

• JACE-4/5 controllers, in particular, will have reduced capacity for other

objects due to the RAM requirements of log objects.

Log ObjectViews

With the exception of the StringLog, all log objects have two special views of

object’s buffered log data:

• LogChart —Shows a graph with values on the y-axis and time on the x-axis

(Figure 6-4). This is the default view in the JDE, when you double-click on the

object in the Tree View. If the station has the WebUIService, the chart applet

provides a browser-accessible version of the LogChart.

The LogChart view is not available for a StringLog object.

• LogTable —A table listing of logs, starting with the oldest (at top) and

continuing to the most recent (at bottom), as shown in Figure 6-1. This view is

provided by the LogService (WebUIService is not needed for browser access).

Each log object has some number of properties on its Visual tab that control the

appearance of its LogChart, for example, the chart type and color. These properties

are explained in the sections ahead for each log object type.

LogChart Controls

Areas and controls in the LogChart view are the same in the JDE and Web browser

(Figure 6-4 and Figure 6-5).







Figure 6-4 LogChart areas and main controls for a log object.

Toolbar buttons in the LogChart view are labeled in Figure 6-5. Note that some

controls, such as “Bring to Front” and “Save to Server” are designed for use after

selecting multiple log objects in the browser-accessible “Log Selector” dialog.

The two most commonly-used toolbar buttons are shown labeled in bold (Zoom Out

and Toggle Grid).

Figure 6-5 LogChart toolbar buttons and areas.

Toggles Toolbar visibility. Toggles Legend visibility.

Legend area.

You must toggle it tovisible and click on theobject (as shown) toenable most buttons inthe Control Bar, at thescreens bottom.

Logs (data) area.

To zoom in on an area, clickand drag on any x-axis

portion. The area becomeshighlighted while dragging.When you release themouse button, theLogChart zooms in on theselected area.

Toolbar area.This entire line of user controls can be toggled on and off. See Figure 6-5 for button definitions.

AveragesBar

Toggle3DChart

CycleColor

BringtoFront

SendtoRear

ZoomOut

ToggleGrid

AreaPlot

Min/MaxCandleBar

Time (x-axis) controls, including:

Auto,Y (year),M (month),D (day),H (hour),M (minute,

S (second)

LinePlot

Save toServer

Status li ne

Shows informationabout current cursorposition, both in thelogs (data) area and incontrols areas.







6–14

Log Selector

The log selector is a special feature of the WebUIService. A browser user can use the

log selector to graph multiple log objects and/or archives in the same LogChart. The

user can also use the log selector to select a single log object or archive, and direct its

output to the browser as a text table in a selectable format of either HTML, CSV

(comma-separated-variable), or XML.

The URL to launch the station’s log selector is:

ht t p: / / <host >/ char t / l og

This produces the log selector dialog, as shown in Figure 6-6.

Figure 6-6 Log selector dialog is a special feature of the WebUIService.

A link to the Log Selector is included among the list of “Browser View” links in the

station’s Niagara Help Index. For more details on special browser views that apply

to log objects, refer to Chapter 4, “Services.”

TipIf you want to provide a link to the log selector from the LogChart view forany log object, you can copy the defaultChartTemplate.html file from the

tridium JAR, and then edit it (adding a line for the log selector, Figure 6-7).

Then save the template file in a folder under the station’s database. Reference

this template file in each log object’s property, chartTemplateUrl, as needed.

Selection buttons forlisting logs by objectname only, or by swid.

Also, options to selectarchives only, orarchives and logs byswid (applies if stationhas DatabaseService).

You can “title” a log selectorselection. This title appears inthe LogChart results.

This is also this file name used(in a charts folder under thestation folder) if the if the “Saveto Server” button is used.

Selection list ofavailable log objectsand/or SQL archives.

Currently selected logsand/or SQL archives.

Chart button runs theLogChart, showing allselected items.

Text format buttons (HTML, CSV, XML)are available only if a single log or archiveis currently selected.







Figure 6-7 Log selector link can be added to a modified chart template HTML file.

Common LogObjectProperties

Log objects have a group of “Common Log Properties”, similar to many used for theBACnet Trend Log object. These status and config properties are explained in this

section. In the case where a property variation exists for a particular object type, that

difference is noted in the property table for that specific object.

Trigger Properties

All log objects have identical trigger-type properties, both inputs and outputs. These

properties are explained here and also listed and described in the “Trigger Properties”

section in each object’s description.



Trigger Inputs—Aside from the common “executeTrigger” input (rarely used),

each log object has two additional trigger inputs:



• doClear —A received pulse causes all log data currently held in the object’s

log buffer to be cleared.

Trigger Outputs—Each log object also has two trigger outputs:

• recordedTrigger —Fires upon each recorded log sample.


Log ObjectCommands

For any log object, a JDE or Web browser user with Admin-level privileges has the

following right-click commands available:



In this example, a single line was added to thedefaultChartTemplate.html file (before the server line):

<a href=”/chart/log”> Run Chart Selector </a>

After editing and saving the HTML template file, you willneed to reference its URL from any log object that needsto use it. (chartTemplateUrl property, on the Visual tab.)

The browser user nowhas a Log Selector linkwhen viewing the logobject’s LogChart.







6–16




Note, however, that no archived data is removed from the SQL database.

Not typically needed (or wanted), except in cases where a running station

database was saved and loaded in a new host, or perhaps where host time waserroneously set ahead, archives made, and then time was corrected.

Common LogProperties

Each log object includes a number of status and config properties common to all log

objects, described in Table 6-2. Essentially, these properties function the same for

any type of log object. Differences, if any, are noted in each log object section.

The AnalogLog and IntegerLog object have additional Config properties, which are

described in the properties table for those object types.

Table 6-2 Status and Config properties common to all log objects (AnalogLog, BinaryLog, and others).


S t a t u s

description Read-Write: Permits a user-defined textdescriptor for describing the log. Anyprintable characters, including spaces andmixed case characters, are allowed.

If description is entered, it appears in theobject’s LogChart title.

See description — Also used to list thelog in the station’s logindexhttp://<sta>/log/indexand in the LogSelector .

lastArchiveTimestamp Read Only: Shows a date/timestamp forwhen the last archive occurred. Shows “null”if there have been no archives or if theclearLastArchive command was given.

— null As with buffered logdata, is saved in thestations configdatabase.

C o n

f i g


normal,processor

foreignAddress Read-Write: Does not apply to a log object. -1 -1

bufferSize Read-Write: Defines the number of logsamples for the object that can reside locally(in RAM

The necessary allocation of “resourcecounts” (RAM) is set aside based upon theentered number.

1 to 11520 60

stopWhenFull Read-Write: If set to True, logging stopswhen the number of unarchived log samplesequals the configured bufferSize.

If set to False (the default), the log bufferalways rotates—this means that the oldestsample is overwritten as each new logcontinues to be recorded.

False, True False If archiveSetup is setto nearFull, astopWhenFull of Trueis overridden (loggingcontinues). IfarchiveSetup is set todaily but

stopWhenFull isTrue, loggingcontinues after thedaily archive, at leastuntil the log buffer isfull.







Log ObjectNotes

See the following sections for specific details on each log object type:

• AnalogLog

• BinaryLog

• IntegerLog

• MultistateLog

• StringLog

C o n

f i g ,

c o n

t .

archiveSetup Read-Write: Defines the events that causethe object’s log data to be archived. Flagscan be set in any combination.

• nearFull—Archive occurs at 80% of thelog buffer size.

• daily—Archive occurs daily, at the timeconfigured in the LogService.

• polled—Applies only if another (remote)Niagara station is configured with thePolled Archive (multisite) service.


nearFull,

daily,polled

(noneselected)

logEnableDefault Read-Write: Defines if logging occurs withno link (or “fault”) at the logEnable input.

The default is True—logging occurs. If set toFalse, a link with an active state is requiredto enable logging.

False, True True

collectionMode Read-Write: Defines the manner used to

record log samples, as follows:• interval—Log samples record on a timed

basis using the interval property value.

• change_of_value—Log samples recordupon each change of value that exceedsthe changeTolerance property value, ifpresent.

change_of_value

interval

See Notes Default differs

according to log type.• AnalogLog default

is interval.

• All other log typeshave default ofchange_of_value.

daysOfTheWeek Read-Write: Defines days on which loggingoccurs. Can be set in any combination.

Sun, Mon, Tue,Wed, Thu, Fri,

Sat

(all daysselected)

daysOfTheWeek andtimeRange settingsapply to both collection modes(meaning either interval or

change_of_value).

timeRange Read-Write: Defines the time period inwhich logging occurs (on valid days ofweek), using a start time and end time.

If you check exclusive, logging occurs onlyoutside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

not

exclusive

interval Read-Write: Defines, in minutes, the periodbetween log sample records when thecollectionMode is set to interval.

Does not apply if collectionMode ischange_of_value.


up to 32-bitlimit.

1

Table 6-2 Status and Config properties common to all log objects (AnalogLog, BinaryLog, and others).







AdminTool

6–18

AdminToolQuick reference for all properties: Table A-1

abbrev: (none); AdminTool

The AdminTool object is a special “utility”

apps object, available in the Local Library(tridium JAR file: tridium/apps/AdminTool).

This object provides an admin-level

command to “Search and Replace” property

values for objects in the station database.

Config properties define the property name to

search, new value to write, plus other

parameters for filtering and recursion. This

operation automates what would otherwise

be a manual process of opening and

modifying multiple objects’ property sheets.

Parent Dependencies: None (anycontainer).



CommandsA JDE user with “Command, Admin” rights has this available right-click command:

• searchAndReplace —Executes the object’s search and replace function, as

defined in its Config properties.

Caution There is no undo for any station database changes made with the AdminTool object.

It is recommended that you export the station database frequently.

Also, no range-checking is performed before changing property values (unlike

when using the property sheet of an object). You are responsible for entering

appropriate new values when using the AdminTool object.

Properties

Inputs


Outputs

(none) (none)

Inputs


Outputs

(none) (none)

Input / Output Property Reference for AdminTool Object(only input and output types, see Table 6-3 for all properties)


input — — —

output — — —

Table 6-3 AdminTool ob ject proper ties.


S

t a t u s objectType,

statusFlagsSee Table 6-1 on page 6-5 for information onthese properties common to all apps objects.

— —

C o n

f i g

rootNode Read-Write: The swid of the starting point(upper hierarchy) of the station database inwhich the AdminTool function operates.

This can range from the station’s root(/db/stationName) to any container or primitiveobject in the station’s database. If therecurseChildren property is True, theAdminTool function applies to any and allobjects under the rootNode swid.

valid swid forthe station

— In Tree View, aright-click “copy” onany object under thestation captures itsswid. Use CTRL-Vto paste the swidinto the rootNodefield of the propertysheet.






AdminTool

6–19

C o n

f i g ,

c o n

t .

propertyName Read-Write: The target property name, exactlyas shown on the object(s) property sheet(s).The property should be a read-write type.

Not all properties can be modified.

valid propertyname

-

elementName Read-Write: Not required for most propertiesthat specify a single value of type float, integer,boolean, or string. Example properties of theabove types, in order:

highLimit, notificationClass, restartDisable,alarmText.

However, elementName is required for “flag”properties shown as check boxes, propertieswith time in Hr:Min:Sec, and several otherproperties that have separate fields.

See descrip. - See Table 6-4 onpage 6-20 for exactelementNameproperty valuesrequired for selectedproperty types.

newValue Read-Write: The new value assigned to allmatching properties in (and under) the

specified rootNode.• Enter float, integer, or string values directly.

• For boolean-type properties represented as:

– False or True

– Inactive or Active (or the equivalent text)

Enter “false” or “true” (without quotations).

• If a check box property, also use false (toclear) and true (to set) the specified flag.

See descrip. - No range-checkingis performed

(illegal values arepossible)!

For selectedproperty types,exact newValueproperty values arerequired. SeeTable 6-4 onpage 6-20.

recurseChildren Read-Write: Defines if the search-and-replacefunction is extended to all children (andsubchildren, etc.) of the specified rootNode.

False, True False If set to False, onlythe rootNode objectis affected.

objectTypeFilter Read-Write: Defines a match filter, meaning

only objects of this matching type are affected.The asterisk (*) is used as a “wildcard.”

Partial strings of object types are supported, forexample, AnalogO* will apply to object typesAnalogOutput and AnalogOverride.

valid Niagara

object types

* See the examples

shown in Figure 6-8 and Figure 6-9,

nodeNameFilter Read-Write: Defines a match filter, meaningonly objects with matching name are affected.The asterisk (*) is used as a “wildcard.”

Partial strings of object names are supported,for example, AHU_1* will apply to objectsnamed AHU_1_SA and AHU_1_RA.

valid objectnames in the

station’sdatabase

* See the exampleshown inFigure 6-10, and the“Wildcard Notes”section onpage 6-25.

C o n f i

g ,

c o n

t . propertyValueFilter Read-Write: Defines a match filter, meaningonly objects with this exact value are affected.

The asterisk (*), when used alone, acts as a“wildcard.” (A value AND asterisk do not work.)

existing valueof the target

property

* See the exampleshown in Figure 6-8.

V i s u a




General,

7 others

General

Table 6-3 AdminTool object propert ies. (continued)







AdminTool

6–20

AdminTool NotesThe AdminTool object can save time when engineering a Niagara station, especially

when the same property change needs to be made to multiple existing objects.

Consider it a “power user” tool. However, be aware that there is no undo for any

station database changes that you make with it. For this reason, it is recommended

that you first use the AdminTool object in a “test” setting, for example, with the Niagara demo database. This will allow you to see how the object works.

Notes • The AdminTool object “search-and-replace” function is performed only by a

running station—in other words, the station is doing the work. This object you

use in the JDE merely provides an interface to this routine.

• Ideally, when engineering a station, property values of objects should be set

carefully before the objects are replicated throughout the station’s database.

However, the AdminTool object can be useful if this was not done.

• Some properties cannot be modified via the AdminTool object. These include

ones with complex datatypes (arrays of strings, etc.).

• Properties with multiple elements can only be modified “one element at a

time.” For example, limitEnable for an AI or AO object requires different

AdminTool configurations to set both flags (“low-limit” and “high-limit”).

• In the JDE, you can run the object’s searchAndReplace command directly from

its open property sheet—access it from the Commands menu.

• Results to Standard Output are limited, but you can observe some information

by opening a Standard Output window before issuing the searchAndReplace

command. Typically, successful operations have lines with “Checking:

<objectName> [number] <objectType>,” and end with “Script complete!”

Element NameReference

For most simple float, integer, boolean, or string value properties, the elementName

property can be left blank. Table 6-4 provides information needed when modifying

some properties that do require the elementName field.

Table 6-4 AdminTool Config properties (elementName, newValue) selected properties.

Property to be Modified JDE Property Sheet Descrip. Required element ame Required newValue

activeInactiveText active For any:same as JDE description

For any:desired text descriptor inactive

archiveSetup nearFull For any:

same as JDE description

For any:

false or truedaily

polled

chartTemplateUrl chartTemplateUrl url swid to HTML template file

commandTags

(AO and MSO objects)

manualSet For any:same as JDE description

For any:desired command textmanualAuto

emergencySet

emergencyAuto






AdminTool

6–21

commandTags

(BO object)

manualActive For any:same as JDE description

For any:desired command textmanualInactive

manualAuto

emergencyActive

emergencyInactive

emergencyAuto

daysOfTheWeek Sun sun For any:

false or trueMon mon

Tue tue

Wed wed

Thu thu

Fri fri

Sat sat

decimalFormat Precision precision 0 to 6 (integer)

Force Sign forceSign false or true

delayTime Hr:Min:Sec (0:00:00) duration 0 to n (integer of seconds)

eventEnable to-offnormal toOffnormal For any:

false or trueto-fault toFault

to-normal toNormal

eventTriggerEnable to-offnormal toOffnormal For any:

false or trueto-fault toFault

to-normal toNormal

executionParameters freq(drop-down selection box:

never, slower, normal, faster,fastest, minutely, on_trigger)

frequency Either:never, slower, normal, faster, fastest,

minutely, on_trigger

order (drop-down selection box:input, output, processor)

order Either:input, output, processor

font (name) such as: Helvetica name Either:Courier, TimesRoman, Helvetica,MonoSpaces, SansSerif, Serif, Dialog,DialogInput

(size) such as: 12 size Either:8, 10, 12, 14, 16, 18, 20, 24, 32

(style) such as: Plain style Either:0 (Plain), 1 (Bold), 2 (Italic),3 (Italic-Bold)

highDeltaColor highDeltaColor

Note: This elementName andnewValue method works forany color-defined property, forexample, backgroundColor .

rgb A hexadecimal (hex) number for eachof the three (red, green, blue) rgbvalues, with a leading "00" prefix.

Example, for white (rgb 256, 256, 256decimal, in that order):newvalue should be 00FFFFFF

inhibitTime Hr:Min:Sec (0:00:00) duration 0 to n (integer of seconds)

Table 6-4 AdminTool Config properties (elementName, newValue) selected properties. (continued)







AdminTool

6–22

Note Depending on need, Table 6-4 may be expanded in a later document revision.

limitEnable low-limit lowLimitEnabled For any:

false or truehigh-limit highLimitEnabled

lowDeltaColor lowDeltaColor rgb Same method as for highDeltaColor.

midDeltaColor midDeltaColor rgb Same method as for highDeltaColor.

priorityForWriting (drop-down selection box,levels 1 through 16)

ControlPriorityEnum level_1to

level_16

securityGroups GeneralHVACSecurityLife SafetyGroup 4Group 5Group 6Group 7

mask A hexadecimal (hex) number for abinary-to-bitmapped mask where a setbit (1) enables that group.

From MSB to LSB, the bits mean:

For example, to set securityGroups toGroup 6, Life Safety, and General:

01001001 which is 49 hex

Therefore newValue = 49

templateUrl templateUrl url swid to HTML template file

triggerPeriod Hr:Min:Sec (0:00:00) duration 0 to n (integer of seconds)

timeRange (time) (starting) to startTime For any:00:00 to 00:00 (24-hour format)(00:00=12:00AM, 23:59=11:59PM)

(time) (ending) endTime

exclusive (check box) exclusive false or true

Table 6-4 AdminTool Config properties (elementName, newValue) selected properties. (continued)


Group7

Group6

Group

5Group

4

LifeSafety

Security

HVAC

General

0 0 0 0 0 0 0 0

MSB LSB






AdminTool

6–23

Examples The following examples show different examples of using the AdminTool object.

• Changing Log Object End Times

• Stopping FunctionGenerators

• Changing LimitEnable for AIs

Changing Log Object End Times

The example shown in Figure 6-8 has an AdminTool object configured to change the

end time for all log objects in the station that currently have a end time of 5:00PM.

The new end time is set to 5:30PM.

Figure 6-8 AdminTool object showing element usage and object type and value filter.

The required elementName entry (endTime) for the property timeRange can be found

in the Table 6-4.

The objectTypeFilter property is set to “*Log” so that only log-type objects are

affected (AnalogLog, BinaryLog, and so forth). Note the wildcard (*) can be used

either before (as here) or after other characters, as in other AdminTool examples. In

this example, because the “timeRange” property is also common to notification

recipient objects, the “*Log” objectTypeFilter limits the action to only log objects.

Times must be specified using a 24-hour format, so the newValue and

propertyValueFilter entries reflect this (17:30 for 5:30PM and 17:00 for 5:00PM).

Because the rootNode has been set to the station “root level,” when the object’s

“searchAndReplace” command is given, all log objects in the station NetSup2000

with an end time currently set to 5:00PM will be changed.

Because it has multiple elements,this property requires an exact string entered in elementName.

Setting recurseChildren to True isnecessary to modify all child objects.

Filter properties are “match” filters, and can be used incombination (as done here).






AdminTool

6–24

Stopping FunctionGenerators

In this example, shown in Figure 6-9, the AdminTool object is configured to stop all

FunctionGenerator objects under a container “/db/NetSup2000/TestAHU_Type_1.”

The required elementName entry (frequency) and the different newValue

enumerations for the property executionParameters can be found in the Table 6-4.

Figure 6-9 AdminTool object showing element usage and object type filter.

Changing LimitEnable for AIs

The example shown in Figure 6-10 has an AdminTool object configured to set the

“high-limit” flag for all AI objects in the station with a name containing “RATemp.”When working in property sheets, the high-limit flag is set or cleared using a check

box for the limitEnable property.

Figure 6-10 AdminTool object setting a “check box” type property, using filters.

Because it has multiple elements,this property requires an exact string entered in elementName.

Func* is more than sufficient toaffect only FunctionGenerators.

Later, this can be set back to normal and the object’s command rerun(to restart the FunctionGenerators).

Because it has multiple elements,

this property requires an exact string entered in elementName.

Setting recurseChildren to True isnecessary to modify all child objects.

Filter properties are “match” filters, and can be used incombination (as done here).






AdminTool

6–25

The required elementName entry (highLimitEnabled) for the property limitEnable

can be found in the Table 6-4. The objectTypeFilter property is set to “AnalogIn” so

that only AnalogInput objects are affected.

The newValue is set to “true” (to set the flag). To clear the flag, newValue would be

set to “false”. In this case, the propertyValueFilter was set to “false” just to prevent

changing something that already existed.

AuditLog Notes

All property value changes made using the AdminTool object are recorded by the

station’s AuditLogService, complete with a timestamp and the new property value.

Note, however, that the userName field will report “unknown” for these changes.

Wildcard Notes

The following two search filter properties for object type and object name work with

wildcard (*) characters that are either leading, trailing, or at both ends.

• objectTypeFilter —To match the Niagara object type.• nodeNameFilter —To match the name of the object(s).

The default value for each property is the single wildcard character: *

which matches all types or names.

A leading wildcard example is an objectTypeFilter of: *Input. This would apply to

object types AnalogInput, BinaryInput, and MultistateInput.

A trailing wildcard example is a nodeNameFilter of: Ch1*. This would apply to any

object with a name beginning with “Ch1,” such as Ch1sPump, Ch1rTemp,

Ch1sTemp and so on.

Wildcards at both ends of the value also can be used. An example is a

nodeNameFilter of: *1s*. This would apply to any object that contains the characterstring “1s” in its name, for example, Ch1sTemp, Ch1sPump, AHU1sFan, and so on.

Note The propertyValueFilter property value can also contain a single wildcard (*),

the default. However, a wildcard does not work with any entered value.






AnalogLog

6–26

AnalogLogQuick reference for all properties: Table A-3

abbrev: (none); AnalogLog

AnalogLog objects store the analog value

received on a float input along with status anda timestamp. Logs are recorded either at

regular intervals or upon change-of-values,

depending on the object’s configuration.

This object has the standard config properties

that define the size and operation of the log

buffer, log archive schemes, and log

collection modes. Linkable inputs are

available to enable/disable log sampling,

trigger log archiving, or trigger the clearing

of log samples. Trigger outputs fire upon

each log sample and when logs are archived.

This object is unique among log objects

because it has a statusOutput , producing a

value based upon recorded logs. This value is

configurable to be the current (last) log value,

or the minimum, maximum, average, or sum

value of the accumulated logs.


container).

Resource CountRange

115 to 160, assuming bufferSize of 60 (default).

Add 1 resource count for each 1-increase in the object’s bufferSize.

Trigger Properties The AnalogLog object has the standard input property, executeTrigger , (typically not

used) and also two other trigger-type inputs:








CommandsAdmin-level users have a right-click command menu, providing these 3 commands:






Inputs


Outputs

statusInput (none)

Inputs


Outputs

executeTrigger

doArchiveTrigger

doClearTrigger

logEnable

statusInput

recordedTrigger

archivedTrigger

statusOutput

Input / Output Property Reference for AnalogLog object(only input and output types, see Table 6-5 for all properties)



doArchi doArchiveTrigger TriggerType

doCleari doClearTrigger TriggerType

enable logEnable BooleanStatusType


output recorde recordedTrigger TriggerType

archive archivedTrigger TriggerType







AnalogLog

6–27

PropertiesTable 6-5 AnalogLog ob ject proper ties.


S t a t u s

objectType,



on these properties common to all appsobjects.

— — If description is

entered, it appears inLogChart title, alsoto list the log in thestation’s log index:http://<sta>/log/index

lastArchiveTimestamp See Table 6-2 on page 6-16 for moreinformation on this log object property.

— null

C o n

f i g


normal,processor



bufferSize,stopWhenFull,

archiveSetup,logEnableDefault,collectionMode,daysOfTheWeek,timeRange,interval

See Table 6-2 on page 6-16 for moreinformation on these properties common to

all log objects.

— — The collectionMode default is interval.

outputFunction Read-Write: Determines the method used tocalculate the statusOutput value usingrecorded logs, where the output is either:

• current—The last recorded log sample.

• minimum—The minimum recorded log.

• maximum—The maximum recorded log.

• average—The average of recorded logs.

• sum—The sum of all recorded logs.

current,minimum,maximum,average,

sum

current When chainingAnalogLog objects,the average selectionis often used.

changeTolerance Read-Write: Used only if collectionMode isset to change_of_value. Defines theminimum ± change required at thestatusInput (since the last recorded logsample) before a new sample is recorded.

Any positivevalue

0.00000000001 (1.0E-11)

toMAX_VALUE

0.01

deltaLogging Read-Write: Defines if log samples arerecorded as the actual statusInput value, asin the default (False), or the difference (delta) between samples (if True).

If set to True, a log sample will have anegative sign when decreasing, or be

unsigned when increasing.

Note: Delta logging is also reflected at thestatusOutput.

False, True False Typically, when usingdeltaLoggingcollectionModeshould be set tointerval. Otherwise,log samples will show

only thechangeTolerancevalue (positive ornegative).






AnalogLog

6–28

AnalogLog NotesThe AnalogLog object is used to trend any analog value in the station. It is typically

the most widely-used type of log object. These notes apply to the AnalogLog:

• statusOutput Notes

• Delta Logging Notes

• Visual Properties Notes

C o n

f i g ,

c o n

t .


For selections see “About Units,” page 5-6.Units appear on the LogChart showing theobject’s log data. Units can also appear ona GxText object linked to the statusOutput.


Other,no_units

Units are not used inthe object’s LogTableview, nor with any

access to archivedlog data.

V i s u a

l


chartType Read-Write: Defines the chart (graph) styleused to present log data in the LogChart.

The object’s LogChart is seen by a JDEuser and (if WebUIService is licensed) by aWeb browser user.

plot,area,bar,

candle,bar_3d,

candle_3d

plot For an example ofeach chart type, seeFigure 6-14.

chartColor Read-Write: Defines the color used in theLogChart to represent recorded log data.

Any desiredcolor

Red

(255,0,0)

chartTemplateUrl Read-Write: Specifies the swid to an HTMLtemplate used to frame the LogChart whenviewing it in a Web browser.

If left blank, the “default” HTML template isused (defaultChartTemplate.html).

Valid swid to anappropriate

HTMLtemplate.

— See the Tip onpage 6-14 for anexample of using thisproperty.

decimalFormat Read-Write: Sets decimal position from 0 to6 places, optionally forces (+) sign forpositive values. Decimal format is used inthe y-axis scale values on the object’sLogChart, also in displayed values in theJDE LogTable view.

0 to 6,


2,

no (+) sign

Decimal format is not

used in browseraccess to the object’sLogTable view, norwith any access toarchived log data.

E n g

i n e e r i n g


Properties common to all apps objects. Formore information, see Table 6-1 onpage 6-5.

— —

logEnable(input: enable)

Read Only: Shows the current boolean stateand status of the logEnable input.


false : ok Shows false iflogEnable is notlinked.




00.0 ok




00.0 ok



General,

7 others

General

Table 6-5 AnalogLog object propert ies. (continued)







AnalogLog

6–29

statusOutputNotes

The AnalogLog object has a statusOutput and a outputFunctionconfig property. Use

of this output is optional. However, it can be useful when gathering analog data.

• The statusOutput value is based on recorded logs— with the outputFunction

set to current (the default), the output value is the last recorded log.

• By setting outputFunction to either average, minimum, maximum, or sum, theoutput value reflects the math operation on the object’s recorded logs.

The typical use of statusOutput is for “chaining” AnalogLog objects (Figure 6-11).

Figure 6-11 AnalogLog objects can be chained together using the statusOutput.

Note A benefit of chaining AnalogLog objects is that fewer links are required to the source

object. When engineering a Web Supervisor station, most log objects are externally

linked to objects in JACEs.

Delta LoggingNotes The AnalogLog object has delta logging option, which records the difference (delta)values between recorded logs. This feature can be useful in “performance trending.”

Figure 6-12 shows delta logging used (along with the logEnable input) to track the

effect on return air temperature following an AHU system start.

Figure 6-12 AnalogLog object configured for deltaLogging (with logEnable linked).

1. OATMinuteLog

bufferSize = 60collectionMode = interval

interval (min.) =1outputFunction = average

2. OATHourLog


interval (min.) = 60outputFunction = average

3. OATDayLog


interval (min.) =1440

1. OATMinuteLog, holds the last hour’s (60 minutes) outside temperatures.

2. OATHourLog, holds average hourly outside temperatures for the last 48 hours.

3. OATDayLog, holds average daily temperatures for the last 35 days.

Sourceobject

When linked, an active isrequired on logEnableduring logging.

tstamp value status

17:30:00 23-Jul-2001 EDT 0.02 ok

8:00:00 24-Jul-2001 EDT 7.20 ok

8:01:00 24-Jul-2001 EDT -0.61 ok

8:02:00 24-Jul-2001 EDT -0.73 ok

Values are the differencesbetween current samplevalue and previous value.

AH1_RATlog

bufferSize = 60stopWhenFull = FalsecollectionMode = intervalinterval (min.) =1

deltaLogging = True

Example log dataportion at systemstart (cooling cycle).






AnalogLog

6–30

Figure 6-13 shows a similar example, but with the addition of a DateTimeTrigger

object that periodically clears the AnalogLog object’s buffer, which is set to

stopWhenFull. In this case, only the first hour’s operation is wanted, so the bufferSize

is set to 60, with an interval of 1.

Figure 6-13 AnalogLog object configured for deltaLogging, logEnable, doClearTrigger.

In this example, the DateTimeTrigger object is configured to fire daily at 3:00 AM,clearing all logs from the buffer. This occurs after the daily archive of the station’s

log data (as defined in the LogService object), which in this case is at 12:01 AM.

Visual PropertiesNotes

The Visual tab of the log object’s property sheet provides several properties that

affect the graphical presentation of log data. These properties are:

• chartType —Determines the charting style used to show log data in the

LogChart view, as seen in the JDE or from a Web browser. For an AnalogLog

object, the default is plot , a standard x-y line-plot. For a comparison of all chart

styles, see Figure 6-14.

• chartColor —Determines the color used to display the object’s log values. The

default color is red.• chartTemplateUrl —(optional) Specifies the path to an HTML template used

to frame the chart applet (when accessing the LogChart using a Web browser).

Any named template overrides the “defaultChartTemplate.html” template.

Notes • These 3 chart properties apply only if the station is running the WebUIService.

• Any template referenced by the chartTemplateUrl property must be available

to the station, otherwise the object’s LogChart will not appear.

Another Visual tab property is decimalPrecision, which determines the decimal

format used to display the y-axis (value) scale in the LogChart view. It also specifies

the decimal format used for values in the JDE LogTable view (Figure 6-1).

AH1_RATlog

bufferSize = 60stopWhenFull = TruecollectionMode = intervalinterval (min.) =1deltaLogging = True

DateTimeTrigger(linked to doClearTrigger )

triggerDay = Date ** *** ****triggerTime = 3:00 AM






AnalogLog

6–31

Figure 6-14 shows how the same log data (sine wave, values ranging from 50 to 90)

appears in a LogChart using different chartType selections.

Figure 6-14 AnalogLog chartType selections determine how the object’s log data appears in the LogChart view.

plot: The plot chartType appears as a continuous line, with thelog value on the y-axis against time on the x-axis.

candle: The candle chartType is similar to the bar chart, butbars average changes in log values over repeating periods.

area: An area chartType follows the same plot contour, but fillsin the entire region below recorded log values.

bar_3d: The bar_3d chartType is like the bar type, but simplyadds shadow details for a 3D effect.

bar: The bar chartType shows averages for the log valuesover a repeating time period (for each bar).

candle_3d: The candle_3d chartType is like the candle type,but simply adds shadow details for a 3D effect.






BinaryLog

6–32

BinaryLogQuick reference for all properties: Table A-10

abbrev: (none); BinaryLog

BinaryLog objects store the boolean value

(state) received on a boolean input along witha status and timestamp. Log samples occur at

regular intervals or upon change-of-state,











container).

Resource Count Range: 115 to 160,

assuming bufferSize of 60 (default).

Add 1 resource count for each 1-increase in

the object’s bufferSize.

Trigger Properties The BinaryLog object has the standard input property, executeTrigger , (typically not









CommandsFor any user with Admin-level privileges, a right-click command menu provides

these commands:

• clear —Clears all log data currently held in the object’s log buffer.• archive —Archives all log data currently held in the object’s log buffer.




Inputs


Outputs

statusInput (none)

Inputs


Outputs

executeTrigger

doArchiveTrigger

doClearTrigger

logEnable

statusInput

recordedTrigger

archivedTrigger

Input / Output Property Reference for BinaryLog o bject














BinaryLog

6–33

PropertiesTable 6-6 BinaryLog object proper ties.


S t a t u s

objectType,






lastArchiveTimestamp See Table 6-2 on page 6-16 for moreinformation on this log object property.

— null

C

o n

f i g


normal,processor



bufferSize,stopWhenFull,

archiveSetup,logEnableDefault,collectionMode,daysOfTheWeek,timeRange,interval

See Table 6-2 on page 6-16 for moreinformation on these properties common to

all log objects.

— — The collectionMode default is

change_of_value .Typically, this is left atdefault.

V i s u a

l


chartType Read-Only: Defines the chart (graph) styleused to present log data in the LogChart.

The object’s LogChart is seen by a JDEuser and (if WebUIServices are licensed) bya Web browser user.

area area See Figure 6-15 foran example.

chartColor Read-Write: Defines the color used in the

LogChart to represent recorded log data.

Any desired

color

Red

(255,0,0)




HTMLtemplate.


activeInactiveText Read-Write: Defines how log samples arestored and described in the LogTable andLogChart.


Active,Inactive

E n g

i n e e r i n g



— —








00.0 ok



General,

7 others

General






BinaryLog

6–34

BinaryLog NotesBinaryLog objects are typically used to track the time of state changes, therefore, the

collectionMode property should be left at the default: change_of_value.

The default view for a BinaryLog object is its LogChart, which uses a fixed “area”

style plot. This results in bar-type graph (Figure 6-15).

Figure 6-15 LogChart view for a BinaryLog object.

The LogTable view (Figure 6-16) may also be needed, as each timestamp lists the

exact time for each change of state.

Figure 6-16 LogTable view for a BinaryLog object (JDE and Web browser).

The two possiblestates (values) appearusing the object’sactiveInactiveText

descriptors.

Active time is indicated by the solid colorareas, using the object’s chartColor setting.

Inactive time is indicated bythe white (blank) areas.

As in the LogChart, the twopossible states (values) arelisted using the object’sactiveInactiveText descriptors.

LogTable in JDE

LogTable in a browser

Timestamps for eachstate change.






Calendar

6–35

Calendar Quick reference for all properties: Table A-14

abbrev: Cal

The Calendar object is an extension of a

BACnet Calendar object, and can be exposeddirectly as such. Calendar objects define a list

of dates, which are typically used in the

system as holidays. As needed, calendar dates

can be single days or span consecutive days.

Dates are entered and reviewed graphically,

using calendar-based views.

Note: The station requires the

WebUIService in order for these views

to be Web browser-accessible.

By default, the object’s statusOutput is active

during a calendar date (holiday). Typically,

you link this output to the holidayOverride

input of one or more Schedule objects,

providing holiday control. The object also

has 3 trigger outputs that fire, respectively, on

any change of value, a change to-active, and

a change to-inactive.

Calendar objects have “slave sync” inputs

and outputs, used to link multiple Calendar

objects in different stations (providing global

editing control).


container).


Trigger Properties In addition to the standard input property, executeTrigger (typically not used), the

Calendar object also has 3 trigger-type outputs:

• covTrigger —Fires upon any statusOutput change (to-active and to-inactive).

• onActiveTrigger —Fires each time the statusOutput changes to active.

• onInactiveTrigger —Fires each time the statusOutput changes to inactive.



ViewsFor a Calendar object, a JDE user has a right-click Go > <command> menu

providing these views (in addition to standard Go commands: Properties and Links).

Inputs


Outputs

(none) statusOutput

Inputs


Outputs

executeTrigger

statusInput

slaveIn

presentValue

statusOutput

covTrigger

onActiveTrigger

onInactiveTrigger

masterOut

Input / Output Property Reference for Calendar object(only input and output types, see Table 6-7 for all properties)



sIn statusInput BooleanStatusType

slaveIn slaveIn SlaveSyncType

output present presentValue boolean



onActiv onActiveTrigger TriggerType

onInact onInactiveTrigger TriggerType

master masterOut SlaveSyncType






Calendar

6–36

• Calendar —Shows the current calendar month with defined dates indicated by

shading. Arrow controls allow you to scroll through months and/or years.

Button controls allow new dates to be defined and existing dates deleted.

• CalendarSummary —Shows the entire calendar year (all 12 months), with

defined dates indicated by shading. Controls allow you to scroll through years.

A click on any date opens that calendar month view (above), in which you cancreate and delete calendar dates.

• EntryList —Shows a tabular listing of all defined calendar dates, showing the

type (date, date range, week and day) and the exact dates defined.

Notes • The Calendar view is the default view for a Calendar object in the JDE

(double-click on object in Tree View). It is also the default view from a Web

browser, providing that the station has the WebUIService.

The browser Calendar view differs slightly by providing a right-click menu to

create or delete calendar dates, as opposed to the dedicated button controls in

the JDE. See Figure 6-19.• Admin-level-write privileges are required for any user to create, delete, and

modify calendar dates.

PropertiesTable 6-7 Calendar ob ject proper ties.


S t a t u s


See Table 6-1 on page 6-5 for informationon these properties common to all appsobjects.

— —

presentValue Read Only: Required for BACnet. Reflectsthe object’s statusOutput state.

Inactive,Active

Inactive Displays in theobject’s configured:

activeInactiveText

C o n

f i g


fixed_minutely,

processor

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet Calendar object to other BACnetdevices. See “foreignAddress,” page 6-6,for more information.

0 to 4194302

or -1(not exposed)

-1 If set, must be aunique numberamong all otherCalendar objects instation.


activeInactiveText Read-Write: Defines how states display atthe statusOutput, presentValue, andstatusInput, and also how they appear onthe object’s property sheet.


Active,Inactive







Calendar

6–37

Calendar NotesA Calendar object is typically linked to one or more Schedule objects. The link is

from its statusOutput to the holidayOverride input of the Schedule object, as shown

in Figure 6-17.

The following Calendar topics are explained ahead:

• Calendar Object Processing and Priorities

• Output Configuration

• Master / Slave Operation

• Calendar View Notes

V i s u a

l


templateUrl Read-Write: Specifies the swid to an HTMLtemplate used to frame the object’s

calendar dates in the calendar applet (whenviewing it in a Web browser).

If left blank, the station’s calendar templateis used (WebUIService’s Config property,calendarTemplateUrl). If that property isblank, the stations “defaultTemplateUrl” isused—also a WebUIService property.


HTMLtemplate.

— Does not apply if theCalendar object

resides in a stationwithout theWebUIService.

E n g

i n e e r i n g



— —


Read Only: Shows the current value andstatus produced on the statusOutput (the

main linkable property of this object).




• An active overrides the statusOutput toactive (at the top of the minute).

• Inactive allows normal scheduleoperation.


statusInputDefault Read-Write: Default value for statusInput if itis not linked, or if it has a “fault” status.

False, True False Typically seldom (ifever) set to True.

masterOut(output: master )

Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync No real-t ime status(or indication of amaster/slave link) isprovided on the

property sheet.

slaveIn

(input: slaveIn)

Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync



General,

7 others

General

Table 6-7 Calendar object propert ies. (continued)







Calendar

6–38

Figure 6-17 Calendar is typically linked to a one or more Schedule objects.

Calendar ObjectProcessing andPriorities

As with Schedule objects, the ControlEngineService executes Calendar objects once

at the top of each minute (fixed). This means that changes in calendar dates and/or a

change at the statusInput become effective only once a minute.

The object’s statusInput, if linked, is given the top priority. This means that:

• Whenever an active is present at the statusInput, the statusOutput is overridden

to active (holiday).

• When inactive (or if not linked), normal calendar-date operation continues.

Calendar OutputConfiguration

The Calendar object has a single main output: statusOutput, using the

BooleanStatusType data species. Another output, presentValue, is available that

reflects the same state, but uses the primitive “boolean” data species.

A collection of three trigger-type outputs provide trigger pulses on any change of

state, change to-active, and change to-inactive.

Master / SlaveOperation

The Calendar object’s output masterOut and input slaveIn allows a single “master”

Calendar object to globally define all holiday-type calendar dates in all of its linked

“slave” Calendar objects. Any calendar date change made in the master Calendar

object is immediately copied to its slave objects.

This is particularly useful in multi-station jobs. The typical application is as follows:

• “Master” Calendar objects reside in the Web Supervisor.

• “Slave” Calendar objects reside in JACE controllers.

• You link the masterOut from a Web Supervisor-resident Calendar object to the

masterIn input of one or more JACE-resident Calendar objects.

In case of a communications failure between devices, each JACE retains holiday

configurations, as this data is persistently stored in all Calendar objects.

Calendar object






Calendar

6–39

Notes • If a Calendar object is linked as a slave, its calendar setup cannot be directly

modified . Its Calendar view still shows the calendar dates as programmed in

the master Calendar, but as read-only. Note that the master/slave relationship

applies to the object’s config property activeInactiveText, as well.

• A linked slave object receives all of the master’s calendar dates only upon an

date change in the master object (with communications OK). This applies

mostly to a newly-linked slave Calendar object, but can apply if changes are

made when device communications are down.

• Typically, when engineering master/slave Calendar objects in stations,

corresponding master/slave Schedule objects are also used.

Calendar ViewNotes

In the JDE, the Calendar view for a Calendar object provides a graphical calendar to

access calendar dates, as shown in Figure 6-25. Controls for editing dates are at the

bottom of the view, and become active when a day (or days) are selected.

Figure 6-18 Calendar view in JDE for a Calendar object.

When accessing a Calendar object using a browser, the same general view is

presented. However, editing controls (new, delete, etc.) are right-click options for any

selected day or days (Figure 6-18).

Outer (double)arrows are toscrollback andforward

throughyears.

Controls for editing datesbecome active after clicking on(selecting) one or more dates.

Inner(single)arrows are toscrollback andforward

throughmonths.

Calendar datesare indicated byshading.

Cancel merely deselects any

selected day or days.

Next year

Next monthPrevious year and month

http://-/?-

http://-/?-






Calendar

6–40

Figure 6-19 Browser access to Calendar object provides a similar view, but with right-click

menu controls for adding and deleting calendar dates.

Note There is no browser-accessible equivalent to the JDE CalendarSummary view, wherecalendar dates for all 12 months of the year can be examined.

Template Prior ities

The calendar applet is framed within an HTML template defined by either of these

properties, in order of priority:

a. The template referenced by the Calendar object’s templateUrl property (on

the object’s Visual tab). If this value is blank, then:

b. The template referenced by the WebUIService’s calendarTemplateUrl

property (on the WebUIService’s Config tab). If this value is blank, then:

c. The defaultTemplateUrl, also on the WebUIService’s Config tab.

Scroll controls work in thesame fashion as in the JDE.

Click or dragto select dayor days.

Previous month

Previous year

Right-click for menuoptions to add, delete, or listcalendar dates.

Save button is available afterchanges are made, but not yetwritten to persistent storage. Reload button recalls only

those calendar datescurrently stored persistently.






IntegerLog

6–41

IntegerLogQuick reference for all properties: Table A-40

abbrev: (none); IntegerLog

IntegerLog objects store the integer value and

status received on the statusInput along witha timestamp. Log samples occur either at

regular intervals or upon change-of-values,











container).





Trigger Properties The IntegerLog object has the standard input property, executeTrigger , (typically not









CommandsAdmin-level users have a right-click command menu, providing these commands:


• archive —Archives all log data currently held in the object’s log buffer.• clearLastArchive —Resets the status property lastArchiveTimestamp from a



Inputs


Outputs

statusInput (none)

Inputs


Outputs

executeTrigger

doArchiveTrigger

doClearTrigger

logEnable

statusInput

recordedTrigger

archivedTrigger

Input / Output Property Reference for IntegerLog object(only input and output types, see Table 6-8 for all properties)














IntegerLog

6–42

PropertiesTable 6-8 In tegerLog ob ject proper ties.


S t a t u s

objectType,







— null

C o n

f i g


normal,processor



bufferSize,stopWhenFull,archiveSetup,logEnableDefault,collectionMode,daysOfTheWeek,timeRange,interval

See Table 6-2 on page 6-16 for moreinformation on these properties common toall log objects.

— — The collectionModedefault ischange_of_value .In some cases,interval may be bettersuited.

deltaLogging Read-Write: Defines if log samples arerecorded as the actual statusInput value, asin the default (False), or the difference (delta) between samples (if True).

If set to True, a log sample will have anegative sign when decreasing, or beunsigned when increasing.

False, True False


For selections see “About Units,” page 5-6..


Other,no_units

Units appear on theLogChart showingthe object’s log data.

V i s u a

l



The object’s LogChart is seen by a JDEuser and (if WebUIServices are licensed) bya Web browser user.

plot,area,bar,

candle,bar_3d,

candle_3d

plot


Any desiredcolor

Red(255,0,0)




HTMLtemplate.







IntegerLog

6–43

IntegerLog NotesThe IntegerLog object can be used to trend any integer value in the station.

As far as the required data species for linking to the object’s statusInput, the

IntegerLog object is interchangeable with the MultistateLog object—both require a

property link to an output using the IntegerStatusType data species.

However, these two log objects should be applied differently, depending on the input

source. Specifically:

• The IntegerLog object is used to log analog values that happen to be integers,

for example, “counts” or seconds. Examples include the changeOfStateCount

and statusElapsedActiveTime properties of BI and BO objects. Recorded logs

will display values numerically. In the object’s LogChart, the object’s assigned

units descriptor will display along the numbers labeling the y-axis.

• The MultistateLog object is used to log discrete values (states), which haveassociated integer values. Examples include the statusOutput of MSI and MSO

objects. Recorded logs will display values using the assigned stateText

descriptors (not the integer values). In the object’s LogChart, the assigned

stateText descriptors also display along the chart’s y-axis.

Similarity to AnalogLog

Basically, the IntegerLog object operates like the AnalogLog object, offering the

same choices for units, deltaLogging, and chartTypes. The basic difference is the

absence of a statusOutput, outputFunction, and decimalFormat properties.

For more information on topics common to both log objects, see the following:

• the “Delta Logging Notes” section on page 6-29.

• the “Visual Properties Notes” section on page 6-30.

Note The default collectionMode for an IntegerLog is change_of_value (unlike the default

of interval for an AnalogLog). Depending on your application, you may wish to

change this to interval, particularly if this is a rapidly changing value.

E n g

i n e e r i

n g


userData


— —







<int value>status flags

0 ok



General,

7 others

General

Table 6-8 IntegerLog object propert ies. (continued)







MultistateLog

6–44

MultistateLogQuick reference for all properties: Table A-49

abbrev: (none); MultistateLog

MultistateLog objects store the multistate

value received on the statusInput along with astatus and timestamp. Log samples occur at

regular intervals or upon change-of-state,











container).





Trigger Properties The BinaryLog object has the standard input property, executeTrigger , (typically not










these commands:

• clear —Clears all log data currently held in the object’s log buffer.• archive —Archives all log data currently held in the object’s log buffer.




Inputs


Outputs

statusInput (none)

Inputs


Outputs

executeTrigger

doArchiveTrigger

doClearTrigger

logEnable

statusInput

recordedTrigger

archivedTrigger

Input / Output Property Reference for MultistateLog object














MultistateLog

6–45

PropertiesTable 6-9 Mult istateLog object propert ies.


S t a t u s

objectType,







— null

C o n

f i g


normal,processor



bufferSize,stopWhenFull,archiveSetup,logEnableDefault,collectionMode,daysOfTheWeek,timeRange,interval

See Table 6-2 on page 6-16 for moreinformation on these properties common toall log objects.

— — The collectionMode default ischange_of_value .Typically, this is left atdefault.

V i s u a

l



The object’s LogChart is seen by a JDEuser and (if WebUIServices are licensed) by

a Web browser user.

area area


Any desiredcolor

Red

(255,0,0)




HTMLtemplate.


stateText Read-Write: Defines all possible discretestates by value-name pairs.


• value—Unique integer from 0 to 7.

• tag—Text to describe the associateddiscrete state. State descriptors are usedat the statusOutput, presentValue, alarmand fault values, and in both the LogChartand LogTable views.

Up to 8 statespermitted,

numericallyfrom 0 to 7.

0 = Off 1 = On

2 = Fastdefault =

Error


For log accuracy,verify that stateTextconfigurationmatches stateText inthe source MSI orMSO object.






MultistateLog

6–46

MultistateLog NotesThe MultistateLog object is used to trend the statusOutput of either a MultistateInput

(MSI) or MultistateOutput (MSO) object, or a BACnet MSI or MSO shadow object.

Similarity toBinaryLog Object

Basically, the MultistateLog operates like the BinaryLog object, offering similar

options for display text (stateText , equivalent to activeInactiveText ). Also, the

MultistateLog is typically used to track the times of state changes, therefore, the

collectionMode property should be left at the default: change_of_value.

Note For accuracy in logging, verify that the stateText property in the MultistateLog is

configured to match the stateText property in the source MSI or MSO object.

Another similarity is the fixed chartType of “area.” The LogChart view of a

MultistateLog object is also similar to the BinaryLog’s, but typically has more than just 2 levels. An “Error” level is automatically added at the top (Figure 6-20).

Figure 6-20 Example MultistateLog LogChart view.

E n g

i n e e r i

n g


userData


— —








00.0 ok



General,

7 others

General

Table 6-9 MultistateLog object properties. (continued)


stateText descriptorsare used intheLogCharty-axis.

An “Error” level appears at top—anerror results when an integer valuenot included in stateText is received.

Different statesappear atdifferent levels,using the object’schartColor .

The first state isno color (white).






Program

6–47

ProgramQuick reference for all properties: Table A-68

abbrev: Prog

The Program object lets you build a custom

application program (control function) as areusable object. A Program object is defined

by a program that you write and compile

using “TRIPL” (Tridium Programming

Language). Each Program object has a

ProgramEditor and ProgramDebugger, used

to write and compile its particular program.

These views are available as right-click “Go

menu” options in the JDE Workspace.

The object’s TRIPL program defines both the

“external” view of the object (the number and

types of inputs and outputs, Config

properties, and right-click commands) and

also its “internal” workings—how the object

processes received data, uses properties, and

outputs values.

Simple uses for Program objects are to

convert data types (data species) from one

type to another. More complex applications

can also be accomplished—refer to the

standard Niagara tridiumx/lib JAR file of the

Local Library for various examples.

Parent Dependencies None (any container).

Resource Count Range: 52 and up

Notes • For detailed information on TRIPL, refer to the Niagara Framework TRIPL

Reference, available in the JDE Help system as one of the online manuals.

• In Release 2.3, the tridiumx/lib JAR includes new psychrometric and

thermistor functions. Refer to the programlanguageextensions.html

document in the tridiumx/lib/docs folder for more information.

Commands If any “commandable inputs” are included in the object’s custom TRIPL program,

right-click (user) commands for run-time operation may be made available.

In addition, all Program objects include these right-click Go > <commands> when

working in the Workspace of JDE:

Inputs


Outputs

(none) (none)

Inputs


Outputs

(as defined) (as defined)

Input / Output Property Reference for Program Object(only input and output types, see Table 6-10 for all standard properties)


input (as written) (as written) (as written)

The number of, names, and types of inputs vary among Program objects.All input types except TriggerType are allowed.

output (as written) (as written) (as written)

The number of, names, and types of outputs vary among Program objects.All output types (including TriggerType) are allowed.

Note: TRIPL is loosely based on the Java programming language.Using TRIPL requires a good working knowledge of the variousNiagara data species, plus a basic understanding of programmingtechniques (keywords, variables, operators, and conditionals).

?






Program

6–48

• ProgramEditor —Opens the object’s TRIPL program in the full width of the

Workspace (Figure 6-21). The JDE toolbar and menu bar includes editing

commands, such as cut, copy, paste, find, replace, and goto. After making any

changes to the program, you must “Compile and Save.” Errors found by the

compiler, if any, appear in the status line at the window’s bottom.

• ProgramDebugger —Opens a two-pane view in the Workspace (Figure 6-22),with the left-side showing the object’s TRIPL program and the right-side

providing a “Watch” view. The JDE toolbar and menu bar includes commands

that allow you to run or “step” through the program, and right-click commands

provide removable break points and the ability to change values.

PropertiesTable 6-10 Program object properties (standard, not counting those properties added in TRIPL).




See Table 6-1 on page 6-5 for informationon these properties common to all appsobjects.

— —

C o n

f i g


normal,processor



typeString Read-Write: Defines the name of an HTMLfile used for “on context” Help when theobject’s property sheet is open in the JDE.

This file must have a tridium\docs file path.

Program Program

displayTypeString Read-Write: Defines the text label thatappears inside the top of the object’s shapewhen viewed in the JDE Workspace. Alsoused as the “Type” field (and filter) for the

Status servlet of the WebUiService.The default is “Prog” (for Program).

Examples: “Pulse Gen” or “Num Ramp.”

Any desiredASCII text

string, includingspaces

Prog Short text strings arerecommended,because the objectshape expands to

accommodate longtext strings.

V i s u a

l



0 to 6,


2,

no (+) sign

icon Read-Write: Defines the “icon” used torepresent the object in the JDE Tree View.

The default is the standard “scroll” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/program.gif

Any .gif file thatcan be

accessed bythe station,

using a size of16 x 16 pixels.

Seedescrip.

E n g

i n e e r i n g



— —

inDebugSession Read-Only: Shows True whenever theobject is running in the ProgramDebugger.

At all other times, this property is False.

False, True False






Program

6–49

Program NotesThe Program object is typically used whenever a routine is not easily done using

standard control objects. Like other apps objects and control objects, program objects

are executed by the station’s ControlEngineService. However, be aware that Program

objects consume more processing (CPU) time than standard objects, and for that

reason should not be used indiscriminately.

The following Program object subtopics are discussed:

• Program Editor

• Program Debugger

• TRIPL Program Overview• Simple Program Example

Program Editor The Program Editor in the JDE provides a number of controls for creating and

modifying the TRIPL program used by a Program object.

Figure 6-21 Program object Program Editor is used to write and compile a TRIPL program.



General,

7 others

General

Table 6-10 Program object properties (standard, not counting those properties added in TRIPL). (continued)


Tool bar buttons for:Debug Mode, Compile and Save, Cut, Copy, Paste, Find, Replace, and Goto.

Errors when compilingappear in the status line.






Program

6–50

Notes • You can also use standard Windows shortcuts to copy (CTRL-C) blocked text

and paste (CTRL-V) when working in the ProgramEditor.

• The “Compile and Save” button remains dimmed until you make a change.

• Any change in the program text must successfully compile before it is saved.If a compile error occurs, you will see a message in the status line giving you

a reason, and the cursor will move to the line with the offending statement.

• When editing an existing Program object, you may need to remove links to

inputs or outputs first (if changes to the TRIPL program affect them).

ProgramDebugger

The Program Debugger provides two separate panes in the Workspace (Figure 6-22).

• The left pane shows the lines in the TRIPL program and provides

run/break/step control. Break points can be inserted by lines in the left margin.

• The right pane is a “Watch” view. It shows the values of outputs, inputs,

variables, and properties as you run or step through the program.

Figure 6-22 Program object Program Debugger is used to step through and analyze.

TRIPL ProgramOverview

From a high-level perspective, a typical TRIPL program includes:

• A number of comment lines, which begin with either:

– Two slashes (//) and continue to the end of that line, or

– Slash-asterisk (/*), continuing as needed to the next asterisk-slash (*/).

Right click menusallow setting breakpoints and addingitems to the Watchpane.

Line numbersappear as youmouse over theleft margin.

Tool bar buttons for:Edit Mode, Run, Break, and Step.

TRIPL programshows in this pane.

Watch view showsin this pane.






Program

6–51

Comments are not executed by the station but serve as documentation

comments and/or labels for sections of the program.

• A number of sections, each used to define the object’s:

– Inputs

– Outputs– Properties

– Variables

– Processing

Program lines (statements) within each section must use the proper rules for

variable declarations, expressions, and control flow.

Simple ProgramExample

A simple example of a Program object is to allow a momentary action switch to

trigger a timed override, as defined in a BinaryOverride object. The Program object

in this example merely fires a trigger output each time a linked input to a BI object

receives an active signal—in this case, from a shadow object (not shown) that

represents a momentary action switch input.

Figure 6-23 Program triggers a BinaryOverride from a momentary switch/BI output.

In this example, the Program object’sproperty displayTypeString wasassigned a value of “PushSwitch,” whichappears inside the object’s shape.






Schedule

6–52

ScheduleQuick reference for all properties: Table A-70

abbrev: Sched

The Schedule object is an extension of a

BACnet Schedule object, and can be exposeddirectly as such. Schedule objects provide

binary (On/Off) event control using a

repeating 7-day schedule. Schedule events

are defined by time-of-day and day-of-week.

Multiple events can be entered for any and all

days, up to 10 events (5 cycles) per day.

Aside from regular (repeating) schedule

events, the object allows definition of

“special events,” which are assigned as

needed to a specific day(s). A special events

day replaces all normal time-of-day events.

In addition, a holidayOverride input can be

linked to a Calendar object, for appropriate

holiday action (as configured in the Schedule

object’s Holiday schedule).

All schedule events are entered and reviewed

graphically, using schedule-based views.

Note: The station requires the

WebUIService in order for these views to

be Web browser-accessible.

If the Schedule object is linked to a Calendar

object, access to its calendar configuration is

automatically included.

A Schedule object’s current event action is

available at both the statusOutput and

prioritizedOutput. Other outputs provide data

on the next scheduled event, and trigger

pulses on event changes.

Schedule objects have “slave sync” inputs

and outputs, used to link multiple Schedule

objects in different stations (providing global

editing control).

Parent Dependencies: None (any container).


Trigger Properties In addition to the standard input property, executeTrigger (typically not used), the

Calendar object also has 3 trigger-type outputs:

• covTrigger —Fires upon any statusOutput change (to-active and to-inactive).

Inputs


Outputs

holidayOverride

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

overrideIn

holidayOverride

slaveIn

isActive

statusOutput

prioritizedOutput

nextEventTime

nextEventValue

covTrigger

onActiveTrigger

onInactiveTrigger

masterOut

Input / Output Property Reference for Schedule object(only input and output types, see Table 6-11 for all properties)



override overrideIn BooleanPriorityType

hday holidayOverride BooleanStatusType

slaveIn slaveIn SlaveSyncType

output isActive isActive boolean



nxtTime nextEventTime DateTimeType

nxtVal nextEventValue BooleanStatusType


onActiv onActiveTrigger TriggerType

onInact onInactiveTrigger TriggerType







Schedule

6–53

• onActiveTrigger —Fires each time the statusOutput changes to active.

• onInactiveTrigger —Fires each time the statusOutput changes to inactive.

CommandsFor any user with “Command, Admin” privileges, a right-click command menu

provides this command:• cleanupSpecials —Removes any previously-executed special events

(providing they are older than the number of days defined by the config

property specialCleanup).

ViewsFor a Schedule object, a JDE user has a right-click Go > <command> menu

providing these views (in addition to standard Go commands: Properties and Links).

• ScheduleEditor —Provides a two-paned graphical view (Figure 6-25) with

four different tabs, including:

– Weekly: The primary tab, showing days of the week (Sun through Sat)

where daily events are graphically reviewed and modified.– Holiday: Defines the schedule events (if any) that are executed during a

holiday (when an active is present at the holidayOverride input).

– Special Events: Using the right-side calendar pane and the ScheduleEditor

menu bar pull-down, special events can be added and configured. Special

events are typically “one-time” events occurring on one or more days.

– Links: Shows a list of objects, by complete swid, that are under control of

the Schedule object (linked to an output).

• EventCalendar —Shows the entire calendar year (all 12 months), with special

events (or holidays from a linked Calendar object) indicated by shading. Arrow

controls allow you to scroll backwards and forwards through the years.

Notes • The ScheduleEditor view is the default view for a Schedule object in the JDE

(double-click in Tree View) and from a linked Gx object in a Web browser

( providing that the station with Schedule object also has the WebUiService).

However, the browser view differs slightly by offering a “Schedule Summary,”

instead of tabs for selecting event-time editors (Figure 6-26). The list of objects

controlled by the Schedule (Links) is not available to a Web browser user.

• Admin-level-write privileges are required for any user to create, delete, and

modify schedule events. If you provide access to a browser user to a Schedule

through a linked Gx object, be aware of this. Unlike commands through a

linked Gx object, which are checked against the user’s privileges for the Gx

object , Schedule events are considered config properties of the target object.

http://-/?-

http://-/?-






Schedule

6–54

PropertiesTable 6-11 Schedule object properties.


S t a t u s

objectType,




— —

isActive Read Only: Required for BACnet. Reflectswhether the object is capable of providingevent-time scheduling control (is operatingwithin its effectivePeriod).

False, True True See the ConfigpropertyeffectivePeriod.

C o n

f i g


fixed_minutely,

processor

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet Schedule object to other BACnetdevices. See “foreignAddress,” page 6-6,for more information.

0 to 4194302

or -1(not exposed)

-1 If set, must be aunique numberamong all otherSchedule objects instation.



Any prioritylevel,

from 1 to 16

Schedule(16)

effectivePeriod Read-Write: Defines a “to” and “from”date range, in which the object’s outputs areallowed to be made active from scheduledactive event-times.

The date format is <day <mo> <year>, withwildcards set by asterisks (*).

Typically left at default (year-round).

See descrip. 1 Jan ****to

31 Dec****

If a slave object, thisrange is read-only(set in master).

The effectivePerioddoes not apply toactive valuesreceived at theoverrideIn input.

activeInactiveText Read-Write: Defines how states display atthe statusOutput and prioritizedOutput.


Active,Inactive


specialCleanup (d) Read-Write: Defines the number of daysthat must transpire before any expiredspecial events are removed from theobject’s EventCalendar (when using theobject’s command cleanupSpecials).

positive integernumber of days

14

(2 weeks)

0 is up to previousday. Negativenumbers can be usedto remove up to thecurrent day’s (-1) orbeyond (future).

trueCommand Read-Write: Defines how an activeschedule event-time or overrideIn inputappears at the object’s outputs.

true, false, auto true Selection of autoapplies to theprioritizedOutputonly—this isequivalent to a false

for the statusOutput.

falseCommand Read-Write: Defines how an inactive

schedule event-time or overrideIn inputappears at the object’s outputs.

true, false, auto false

V i s u a

l


activeColor Read-Write: Defines the color used in theevent-time columns of the ScheduleEditor to denote active (On) event times.

Any colorselectable in

the Edit dialog.

green

inactiveColor Read-Write: Defines the color used in theevent-time columns of the ScheduleEditor to denote inactive (Off) event times.

Any colorselectable in

the Edit dialog.

dark gray






Schedule

6–55

Schedule NotesThe Schedule object is typically linked to one or more BinaryOutput (BO) objects,

using the prioritizedOutput. This provides regular “time-of-day, day-of-week”

control for any linked BO-type objects. As shown in Figure 6-24, it is also typical for

a Schedule object to have its holidayOverride input linked to a Calendar object,

which defines holiday dates that override regular schedule operation.

Note The holiday action (for example, Inactive) is defined in the Schedule object itself.

See Figure 6-25 on page 6-58 for a typical example.

The following Schedule topics are explained ahead:

• Schedule Object Processing and Priorities

• Output Configuration

• Master / Slave Operation

• ScheduleEditor Notes

V i s u a

l , c o

n t .

templateUrl Read-Write: Specifies the swid to an HTMLtemplate used to frame the object’sschedule in the schedule applet (when

viewing it in a Web browser).If left blank, the station’s schedule templateis used (WebUIService’s Config property,scheduleTemplateUrl). If that property isblank, the stations “defaultTemplateUrl” isused—also a WebUIService property.


HTML

template.

— Does not apply if theSchedule objectresides in a station

without theWebUIService.

E n g

i n e e r i n g



— —

holidayOverrideDefault

Read-Write: Default value for theholidayOverride input, used if it is not linked,or if it has a “fault” status.

False, True False Typically seldom (ifever) set to True.


Read Only: Shows the current state andstatus of the statusOutput, one of the twomain linkable outputs.



Read Only: Shows the current state andpriority level of the prioritizedOutput, theother of the two main linkable outputs.


Inactive :@ 16

masterOut(output: master )

Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync No real-t ime status(or indication of amaster/slave link) isprovided on theproperty sheet.

slaveIn(input: slaveIn)

Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync

S

e c u r i t y securityGroups Read-Write: Shows the security groups to



General,

7 others

General

Table 6-11 Schedule object properties. (continued)


http://-/?-

http://-/?-

http://-/?-






Schedule

6–56

Figure 6-24 Schedule is typically linked to a Calendar object and one or more BO objects.

Schedule ObjectProcessing andPriorities

As with Calendar objects, the ControlEngineService executes Schedule objects once

at the top of each minute (fixed). This means that changes in schedule times and input

changes (overrideIn, holidayOverride) become effective only once a minute.

How the outputs respond to the object’s configured schedule event-times and

override inputs is done in a prioritized fashion on each execution cycle.

From highest to lowest, the priorities of evaluation can be summarized as follows:

1. overrideIn input (if linked)

2. Special Events, as configured—replace holiday and weekly events

3. holidayOverride input (if linked)—replace weekly events

4. weekly schedule —normal time-of-day (weekly) events

Table 6-12 provides a matrix showing output action, beginning with the “normal”

weekly schedule control.

Schedule object

Table 6-12 Schedule object priority evaluations (at the top of each minute).

Weekly schedule

action

overrideIn

Input

Special Event

action if any)

holidayOverride

Input

statusOutput, prioritizedOutput)

active none or auto none none or inactive trueCommand(@priorityForWriting)

inactive none or auto none none or inactive falseCommand(@priorityForWriting)

whatever active whatever whatever active1(@priorityForWriting)

1. Note an active or inactive at the overrideIn input bypasses the trueCommand or falseCommand property configurations.

whatever inactive whatever whatever inactive1(@priorityForWriting)

whatever none or auto active whatever trueCommand(@priorityForWriting)

whatever none or auto inactive whatever falseCommand(@priorityForWriting)

whatever none or auto none active (Follows the holiday schedule, either):falseCommand(@priorityForWriting),or trueCommand(@priorityForWriting)

A holiday schedule should not be left

blank (no events), “assuming” inactive.

Otherwise, an output that is active upontransition to the holiday day will remain

active. See Figure 6-25 on page 6-58.

http://-/?-

http://-/?-

http://-/?-






Schedule

6–57

OutputConfiguration

The Schedule object has two main outputs: statusOutput and prioritizedOutput.

Three config properties directly affect how these outputs operate, as follows:

• priorityForWriting —Defines the priority level (from 1 to 16) that is always

used at the prioritizedOutput. By default, this is 16 (“Schedule” level).

• trueCommand —Defines the output state (true, false, or auto) producedduring an “active” schedule event-time, where true = active, false = inactive.

By default, this is true. (Note: auto is equivalent to true for the statusOutput).

• falseCommand —Defines the output state (true, false, or auto) produced

during an “inactive” schedule event-time, where true = active, false = inactive.

By default, this is false. (Note: auto is equivalent to false for the statusOutput).

All three of these properties are typically left at default values. However, in the

situation where the output of one (overriding) Schedule object feeds the overrideIn

of another Schedule object, either the trueCommand or falseCommand of the

overriding Schedule object should be set to auto. Otherwise, both objects will operate

strictly from the overriding Schedule object’s action.

Master / SlaveOperation

The Schedule object’s output masterOut and input slaveIn allows a single “master”

Schedule object to globally define all scheduling event-times, including special

events, in all of its linked “slave” Schedule objects. Any event-time change made in

the master Schedule object is immediately copied to its slave objects.

This is particularly useful in multi-station jobs. The typical application is as follows:

• “Master” Schedule objects reside in the Web Supervisor.

• “Slave” Schedule objects reside in JACE controllers.

• You link the masterOut from a Web Supervisor-resident Schedule object to the

masterIn input of one or more JACE-resident Schedule objects.

In case of a communications failure between devices, each JACE retains schedule

configurations, as this data is persistently stored in all Schedule objects.

Notes • If a Schedule object is linked as a slave, its schedule setup cannot be directly

modified . Its ScheduleEditor view still shows the weekly, holiday, and special

event times as programmed in the master Schedule, but as read-only.

However, note that most properties on its property sheet are independent, for

example, priorityForWriting, trueCommand, falseCommand, and others.

Exceptions to this include the effectivePeriod and activeInactiveText

properties, which do have a master/slave relationship.

• A linked slave object receives all of the master’s schedule event-times only

upon an event-time change in the master object (with communications OK).

This applies mostly to a newly-linked slave Schedule object, but can apply if

changes are made when device communications are down.

• Typically, when engineering master/slave Schedule objects in stations,

corresponding master/slave Calendar objects are also used.






Schedule

6–58

ScheduleEditorNotes

In the JDE, the ScheduleEditor view for a Schedule object provides three separate

tabs to enter event-times, as shown in Figure 6-25.

• Weekly —Provides 7 columns, one for each day of the week.

• Holiday —Provides a single column, which describes the schedule events (if

any) that occur for any day designated as a holiday.• SpecialEvents —Provides a single column, used to define the schedule events

for the day (or days) for the currently selected special event.

Figure 6-25 ScheduleEditor in JDE has 3 tabs for entering schedule event-times.

Notes • On a special event day, all normal time-of-day (weekly) events are replaced .

• To add a special event using the JDE, click the day or days on the calendar side,

then select ScheduleEditor > Add Special Event from the menu bar. This

produces a dialog in which you can enter a descriptor and priority level.

Note that the priority level applies only to “overlapping” special events, and

does not affect the prioritizedOutput level (defined by priorityForWriting).

• Browser access to a Schedule object differs somewhat in that a Schedule

Summary (with links) replaces the tabs approach. See Figure 6-26.

Weekly schedulehas 7columnsfor all thedays ofthe

week. The Holiday tab isa single column thatdefines theschedule actionwhenever theholidayOverrideinput is active.

It is recommendedthat you do notleave this blank (no event times),but instead enter anevent—even if just“Inactive” starting at12am midnight andcontinuing for therest of the day (asshown here).

Otherwise, loadsmay unexpectedlycontinue operationover a holiday.

In the JDE, the right side of theScheduleEditor showscalendar with any specialevent days or holidaysindicated by shading.

The SpecialEvents tab workswith the currentlyselected day (ordays) on theright-sidecalendar view todefine specialevent actions.

In this case, theday selected isnot a SpecialEvent day.

When a SpecialEvent day isactive, eventsreplace all normaltime-of-dayevents.

http://-/?-

http://-/?-






Schedule

6–59

When accessing a Schedule object using a browser, the weekly, holiday, and special

events views are on separate links of a “Schedule Summary” page (Figure 6-26).

Figure 6-26 Browser access to Schedule object starts with a Schedule Summary, providing a row of links.

Notes • The Special Events link provides a list of all special events for the Schedule

object (unlike the graphical “day” indication on a calendar when using the

JDE). You can select a listed special event to display or delete, if needed (but

not to modify). Or, choose New to add a new special event.

• Time-of-day events are added in the same graphical manner as in the JDE.

However, date selections for special events use a text dialog vs. a calendar.

The Schedule Summary page providesseparate links to the weekly, holiday, andspecial events views.

If the object is linked to a Calendar object,a link to its Calendar view also appears.

Links to the weekly, holiday and specialevents run the schedule applet within thedesignated HTML template.

This is defined in the Schedule object’s

Visual property templateUrl (or if notdesignated there) in the WebUIService’sproperty scheduleTemplateUrl.

The weekly and holidayschedule operate like the tabequivalents when using theJDE ScheduleEditor.

The Special Events linkprovides a listing of all specialevents for object.

You can select one to eitherreview (Display) or delete, butyou cannot modify one.

You can, however, add a newspecial event.






StringLog

6–60

StringLogQuick reference for all properties: Table A-73

abbrev: (none); StringLog

StringLog objects store the value received on

the statusInput as an ASCII string, adding atimestamp. The “FlexBindingType” input

allows you to link it to most object outputs

(excepting TriggerTypes). As with other log

objects, log samples occur at regular intervals

or upon change-of-value, depending on the

object’s configuration.










container).





Trigger Properties The StringLog object has the standard input property, executeTrigger , (typically notused) and also two other trigger-type inputs:









these commands:






Inputs


Outputs

statusInput (none)

Inputs


Outputs

executeTrigger

doArchiveTrigger

doClearTrigger

logEnable

statusInput

recordedTrigger

archivedTrigger

Input / Output Property Reference for BinaryLog o bject






in input FlexBindingType








StringLog

6–61

Properties

StringLog NotesRecorded logs differ from other log objects in that only two fields are present:

• timestamp —When the log was recorded. The format is:<time> <day-mo-year> <time zone>, for example:

12:07:49 25-Jun-2001 EDT

• value —The ASCII string at the log object’s statusInput.

Also, there is no LogChart view for a StringLog object. The default view is the

LogTable view.

Table 6-13 Str ingLog object propert ies.


S t a t u s

objectType,





entered, it is used tolist the log in thestation’s log index:http://<sta>/log/index


— null

C o n

f i g


normal,processor



bufferSize,

stopWhenFull,archiveSetup,logEnableDefault,collectionMode,daysOfTheWeek,timeRange,interval

See Table 6-2 on page 6-16 for more

information on these properties common toall log objects.

— — The collectionMode

default ischange_of_value .Typically, this is left atdefault.

V i s u a


E n g

i n e e r i n g



— —





input(input: in )

Read Only: Shows the current string valuereceived on the input.

Any ASCIIstring

Unbound



General,

7 others

General






StringLog

6–62

FlexBinding Input The statusInput of a StringLog object uses a “FlexBindingType” data species—this

means it is link-compatible with almost any object output (not just “String” types).

For example, if linked to the prioritizedOutput of a BO object (Figure 6-27), the

StringLog logs a string value of either “true @<level>” or “false @<level>”, where

<level> is a number from 1 to 16, or “def” (for default).

Figure 6-27 Example StringLog object linked to a BO prioritizedOutput.

Note that if the object’s collectionMode is configured for change_of_value, in this

example it will capture any command change from the source BO. This is true even

if the object’s state does not change (as opposed to the operation of a BinaryLog).

Of course you can link a StringLog object to a string-type output as well, as shown

in Figure 6-28. This log records the runtime (in Hr:Min:Sec) of a chilled water pump.

Figure 6-28 Example StringLog object linked to a String type output.

StringLog object, linked to aprioritizedOutput of a BO.

Example recorded logs ofthe StringLog, shown in itsLogTable view.

StringLog object, linked to aString type output of aconversion Program object.

In this case, the StringLogcollectionMode is set tointerval, with its interval setto 60 (minutes).

Example recorded logs ofthe StringLog, shown in itsLogTable view.





CHAPTER

7–1

7

Container Objects

This chapter describes each of the standard Niagara container-type objects, that is,

those provided in the containers folder of the tridium JAR file. General information

on container-type objects is provided first, as follows:

• About Container Objects

– Tree View Controls

– Container Functions

– Inputs and Outputs

– Layers in Containers

– Browser Views

• Common Container Object Things

– Security Groups and Containers

– Alarm and Alert Text

– Common Container Object Properties

• Containers That “Composite”– To Composite

– Or Not to Composite

Note For the remaining sections, the term container object is used generically for any

container -type object (any type listed below). Whenever a specific type of container

is described, including the Container object, it is capitalized.

Individual container object descriptions follow, arranged alphabetically as follows:

• Bundle

• Composite

• Container

• GxPage

• PollAlways

• PollOnDemand

• ServiceContainer





Chapter 7 Container Objects

About Container Objects

7–2

About Container ObjectsContainer objects provide the means to organize standard primitive objects (control,

apps, and Gx), plus other container objects, in a hierarchical manner. In use, they

contain “child” objects, meaning other objects reside in their Workspace. In fact, the

Workspace view is the primary view for any container object1 —double-click theobject in the JDE Tree View, and its Workspace appears.

Note The ultimate container object (although not categorized as such) is the Station object,

as all other objects in the station can be considered its child objects.

Tree View Controls

Container icons in the JDE Tree View differ among the different container types.

Default container icons are shown in Figure 7-1, left.

Figure 7-1 Default container icons seen in the Tree View.

The Tree View has special navigational functions that work with container objects.

A container’s parental status is indicated by an “expand” control to the left of its icon.

Expand the control and its child objects are revealed (Figure 7-1, right).

As most containers allow multiple levels, additional containers may exist as child

objects, each with their own child objects. Right-click commands allow you to cut,

copy, and paste objects, including containers, as needed in the station database. This

is especially useful when replicating an application that consists of one or additional

(nested) containers, or when saving applications to your local library.

In summary, a container object is defined mainly by its collection of child objects.

Often, the properties of the container object itself are of minor importance.

1. The one exception is the station’s ServiceContainer, which has no Workspace. The primaryview for a ServiceContainer is the ServiceManager view.

Bundle orComposite

GxPage

Container

PollAlways

PollOnDemand

Expandmeanschild objectsexist. Child

objects




About Container Objects



Container Functions

For selection purposes, the functions provided by container objects—by object type,

include:

• Simple “folder” organization— Container and PollAlways.

• Encapsulation of child objects into a simpler object— Bundle and Composite.

• Browser-accessible graphic with real-time values— GxPage.

• Demand-based polling of child integration objects— PollOnDemand .

• Folder for all station services— ServiceContainer .

Some container objects are executed in the station by the “control engine” (managed

by the ControlEngineService ), along with “control” and “apps” objects. These

include the more complex Bundle, Composite, and GxPage objects.

Inputs and Outputs

The simplest container objects (Container, PollAlways, PollOnDemand, and

ServiceContainer) act mainly as folders. These containers provide no inputs or

outputs, meaning links cannot be made directly to them—only to child objects.

However, the remaining container types (Bundle, Composite, and GxPage) have an

available “composite” mechanism. This allows contained child objects, on a

configurable basis, to have their outputs and/or inputs “exposed through” the parent

container—meaning that the container object acquires outputs and inputs.

This mechanism can be thought of as encapsulation, where only the most likely

linkable properties are exposed. Those needed only internally are left inside the

container’s Workspace.

See the “Containers That “Composite”” section on page 7-8 for more information.

Layers in Containers

Containers have independent layer controls for both the Workspace and the

WorkspaceEditor views. Typically, layers are important only in GxPage containers,

as each Gx object has an associated “layer” property, used for overlap control. For

more information on GxPage layers, see the “Layer Control” section on page 7-26.

However, in any container holding control logic, you may want to add GxText

objects, say, for annotations. This may be useful when in the WorkspaceEditor, but

undesirable when observing real-time values in the Workspace (monitor mode).






Common Container Object Things

7–4

In this case, you could use layer assignments in the container so that the Gx objects

are visible only in the WorkspaceEditor, but not in the Workspace (Figure 7-2).

Note To access the layer editor in the WorkspaceEditor or Workspace view of any

container, right-click on the background and select Layers.

Browser Views

The Workspace view of a GxPage is available through a Web browser connection (ifthe station is running the WebUIService). This feature is unique among all container

objects. It is the basis for a universal user interface provided by a Niagara station.

Common Container Object ThingsContainer objects have properties common to all Niagara object types, such as the

status properties “objectType” and “description”. A few common properties have

special significance for containers. Rather than cover these things in detail for each

object type, they are explained in this section. Several container object types can also

be given a “composite” interface, this feature is explained in the “Containers That“Composite”” section on page 7-8.

The following common things apply to container objects:

• Security Groups and Containers

• Alarm and Alert Text

• Commands

• Common Container Object Properties

Figure 7-2 Layer control can be used in any type of container, but applies mainly to Gx objects.

GxText objects(layer_3) are visiblein theWorkspaceEditor .

In the container’s Workspace,layer_3 (used by GxTexts) has

been made not visible.







Security Groups and Containers

Like Niagara primitive objects, container objects have a securityGroups property.

This property is available on the object’s property sheet, on the Security tab.

Security settings for a container determine the following things:

• Whether or not a JDE user has Tree View access to it—including all child

objects. Note that it makes no difference if a user has security rights to child

objects, if security rights to the container are not assigned. If (read) security

rights are missing, the container does not appear in the Tree View of the JDE.

• Whether a browser user has access to the container (GxPage). If the user does

not have security rights, an HTTP “403: Access Denied” error appears upon

any link or URL direction to it.

Alarm and Alert Text

All containers have alarmText and alertText properties, found on Alarm Setup tab ofthe object’s property sheet. This feature allows you to use the same (global) alarm or

alert message text for any alarm or alert-capable child object in that container.

• Alarm-capable objects include the AI, AO, BI, BO, Loop, MSI, and MSO.

• Alert-capable objects include the BI, BO, MSI, and MSO.

The requirement is that the child object(s) use the default value for their alarmText

or alertText properties. The default is a single hyphen (-), and no other characters.

For example, a Container object is given an alarmText property of “Investigate alarm

condition in AHU-1.” The object contains two BI objects configured for alarming,

AHU1_Filter and AHU1_sLock.

• The BI object named AHU1_sLock has the default alarmText of “-”.

• The BI object named AHU1_Filter has an alarmText of “Check AHU-1 Filter,

note that a maintenance schedule is posted on the side of unit.”

When these BI objects alarm, only the first (AHU1_sLock) includes the Container

object’s (global) alarm message text in the alarm record sent to the Alarm Console.

Because the other BI has a non-blank, non-default alarmText value, it is used instead.

Pass UpProcess

If both the container’s alarmText or alertText and a child object’s alarmText or

alertText is at the default hyphen (-), the next (higher) parent container’s alarmText

or alertText value is used. This “pass up” process continues, potentially all the wayto the Station object, until the first “non-default” alarmText or alertText is found.

Note that a “blank” alarmText or alertText is not the same as the default hyphen (-).

Instead, a blank alarmText or alertText will stop the “pass up” process and result in

an empty messageText field in the alarm or alert record.







7–6

Commands

Container objects have no right-click commands. However, for a JDE user with

“Command, Admin” privileges, the “dump” command is available for any of the

simpler container objects (Container, PollAlways, PollOnDemand):


including the objects swid, handle, name, parent, properties, links, and children.

Common Container Object Properties




Table 7-1 Common propert ies for al l container objects.


S t a t u s

objectType Read Only: The container object type. Bydefault, a newly added object uses thisstring in its name (until renamed).This textappears inside the object’s shape in JDE.

The full string for the object type is shown,for example, Composite or GxPage.


For any of the complexcontainers (Bundle,Composite, GxPage),you can edit this usingthe displayTypeStringproperty.

statusFlags Read Only: Current state of the object’sstatus flags. A “normal” state (no flags set)is where the status flags value is “ok”, andthe object’s color is gray.



The object ‘s shape and outputs areyellow.

either:

ok (no flags)

or

down

ok Unlike many controlobjects, containers donot have alarm states.

In the case ofcomposited containers,they do not “assume”alarm or fault conditionsfrom linked inputs.

description Read-Write: Permits a user-defined textdescriptor for describing the container. Anyprintable characters, including spaces andmixed case characters, are allowed.

See description — For a GxPage container,this is sometimes linkedto a GxText object in thatcontainer (or anotherGxPage).

C o n

f i g

executionParameters

Read-Write: Applies to a Bundle,Composite, or GxPage only. Defines thefrequency and order for the object as it isexecuted by the station’s control engine.

• freq (frequency)—Specifies how often theobject is executed. For most containers,

the default frequency (normal) isacceptable.

• order—Specifies the order of execution ineach cycle. On each cycle of the controlengine, objects specified as inputs areprocessed first, then processors next, andlastly the outputs.

By default, the Bundle, Composite, andGxPage containers default to theprocessor order.


minutelyon_trigger

order:input

processor output

freq:normal

order:<see

descrip>

Not available for any ofthe simpler containertypes, namely theContainer, PollAlways,and PollOnDemand.

Usually, default values

are recommended.The selection on_triggeris not valid forcontainers.

For related details, seeControlEngineServiceConfig property“executionFrequency”.







C o n f i g ,

c o n

t .foreignAddress Read-Write: BACnet usage only. Exposes

the Niagara object as a BACnet object.

Note: Currently, this property does notapply to any container object.

-1

(not used)

-1

(not used)

These properties are notshown for the simplercontainers.

Leave at default settings.

membershipGroups Read-Write: (Future use only.) niagaraR2 niagaraR2

V i s u a

l







when theobject is

firstcreated.

Typically, you don’tmanually enter positionvalues, but use themouse to drag the objectas needed on the JDEWorkspace.


E n g

i n e e r i n g

minExecuteTime Read-Write: Can show the object’sminimum execution time, in milliseconds.

Shows MAX_VALUE if “profileNodes” in theControlEngineService was not previouslyset (since the last station start).


Providing that theControlEngineServicewas set to“profileNodes”, theseproperties show theobject’s executionstatistics. Typically, youdo not leave theControlEngineServiceconfigured this wayexcept for brief periodsto collect these values.

This properties are notavailable (nor apply to)

any of the simplercontainers.




averageExecuteTime


Shows 0.0 if “profileNodes” in the

ControlEngineService was not previouslyset (since the last station start).



Any desiredtext string forservlet/API

usage.

<blank>

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the container is assigned. A usermust have the appropriate privileges in atleast one security group to view and modifyproperties and issue commands.

Refer to the “Security Tab” section onpage 1-20 (Station object UserAdmin topic)

for more details on how securityGroupssettings apply.


•General

•HVAC

•Security

•Life Safety

•Group 4•Group 5

•Group 6

•Group 7

General For more information,see the “Security Groupsand Containers” sectionon page 7-5.

Also refer to the “AboutSecurity” section onpage 1-21.

Table 7-1 Common properties for all container objects. (continued)







Containers That “Composite”

7–8

Containers That “ Composite”Three types of container objects have “composite” capability. This means that you

can selectively expose inputs and outputs of their child objects at the container-level.

Essentially, this “encapsulates” the inner workings of the object, and highlights

important inputs and outputs for linkage to other objects (Figure 7-3).

These container types are:

• Bundle

• Composite (surprise)

• GxPage

Figure 7-3 Example Bundle and GxPage objects with exposed (composite) properties.

Note “Composited” containers shown above are from one of the standard tridiumx/lib

applications, available in the Local Library (tridumx/lib JAR, applications folder).

In general, these applications are excellent examples of using composited containers.

Bundle objects GxPage obj ect







To Composite

When working inside the WorkspaceEditor for any of these objects, a “Composite”

command is available (Figure 7-4). This command is present on the right-click menu

for any child object, and even when no child object (only background) is selected.

Figure 7-4 Composite command available on Bundle, Composite, or GxPage Workspace.

The following composite-related topics follow:

• Composite Editor

– About Composite Property Names

– Adding Properties

– Deleting Properties

• Inputs and Default Values

Caution There are known limitations of composited containers, particularly for use with

control logic. See the “Or Not to Composite” section on page 7-13 and the “Bundle

Issues” section on page 7-16 for more details.

Composite command opensthe Composite Editor for thatcontainer object.







7–10

CompositeEditor

As shown in Figure 7-5, the composite editor is where you choose properties (inputs

and outputs) of the container’s child objects to expose at the container level—an

optional task. However, for Bundle and Composite containers, this ability is what sets

them apart from simple “Container” objects. For a GxPage, this is usually done only

if also preparing composited Bundle objects.

About Composite Property Names

When you click (select) a property of a child object, a default property name appears

in the “Selected Property” field. This names the input or output at the container level.

The default name format is: <property name or abbreviation><object name>

For example, for an AI object named AirFlow, a few default property names are

• sOutAirFlow —for the statusOutput of AirFlow.

• eventTriggerAirFlow —for the eventTrigger output of AirFlow.

When adding a property, you can accept the default name or simply retype it.

Notes • Typically when adding properties, you should not use default names. This is

important when making composites for Bundles and GxPages, where the“Match” feature (in the Link Editor) depends on identical property names.

For example, you might change the default name of “sOutAirFlow” in a

Bundle to simply “AirFlow.” In the composite of a GxPage, you could change

the default name of “bindingAirFlowValue” to a matching “AirFlow.”

• Use the Rename option to change the name of a selected property. This can be

done after it is added (or even after it has been linked). Note that when

renaming, the Rename button remains grayed until you type in a new name.

Figure 7-5 Composite editor has a Properties side and an Exposed side.

The Properties side lists allinputs and outputs for one child object. Select any childobject using the drop-downlist, which refreshes the liston the Properties side.

The Exposed side lists allinputs and outputs that arecurrently exposed. Thisincludes inputs and outputsfrom all child objects.

This figure shows thecomposite editor for a Bundlebefore any inputs or outputshave been exposed—theExposed side is blank. Also,no property is currentlyselected on the Propertiesside—the Selected Propertyis blank and its action buttonsare grayed (unavailable).

Properties side Exposed side

Drop-down listto select achild object, byobject name.

Selected Property field and associated action buttons.







AddingProperties

Adding (exposing) new inputs and outputs is straightforward. In the composite

editor, these properties do not show a “composite” icon ( ) beside the input or

output symbol (as the property appears on the Properties side). They are also not

listed on the Exposed side.

Note Any input must be unlinked (unless a trigger type) before it can be added.

Procedure 7-1 Adding (exposing) a property at the container level.

Step 1 In the composite editor, click the drop-down list of child objects and select an

object.

Step 2 Click a property to select it.

The default name appears in the Selected Property field.

Step 3 Edit the default name, as needed (or optionally accept it).

Step 4 Click Add.

The property appears on the exposed side. It will be exposed when you click OK toclose the composite editor (as well as any other changes done while in the editor).

DeletingProperties

Deleting existing composite properties can be more involved, particularly when

properties are linked. Understand that deleting a property means that it is removed

from the container’s exposure (shape)—however, the associated child object

property is not affected. Exposed properties are listed on the Exposed side of the

editor, and also appear on the Properties side with the “composite” icon ( ).

Notes • Any composite property must be unlinked before you can delete it.

• Furthermore, you cannot delete a property if another composite property islisted below it (in the Exposed side), and that property is linked .

• In either case above, the same type of Error popup appears (Figure 7-6).

Procedure 7-2 Deleting a composite (exposed) property.

Step 1 In the composite editor, click the property in the Exposed list side to select it.

The Properties side updates to show all properties of that child object.

Step 2 Click Delete.

a. If the property is unlinked (and no other properties listed below it are linked),

it is removed from the Exposed properties list. It will be removed when youclick OK to close the composite editor.

b. If the property is linked, or another property listed below it is linked, an Error

dialog appears (Figure 7-6). You will need to close the composite editor and

unlink one or more properties (depending on what is found after opening the

WorkspaceEditor of the object containing the container object).







7–12

Figure 7-6 Error popup dialog when attempting to delete a composite property.

Inputs andDefault Values

When exposing inputs of child objects that use “status type” data species

(FloatStatusType, BooleanStatusType, IntegerStatusType), note that each exposed

input has an available default property value at the Composite (parent) level. As

shown in Figure 7-7, you can access and modify default values on the Config tab ofthe Composite object’s property sheet.

This attempt to delete OccStatus (second propertyfrom the bottom), produced an Error popup.

Possible reasons for this error:1. OccStatus is linked, and/or 2. ZoneTemp (property below it) is linked.

In this particular case, theOccStatus property wasalready unlinked—however,the ZoneTemp property(below it) was linked.

Here, ZoneTemp must beunlinked before the propertyabove it can be removed.

If needed, ZoneTemp canbe re-linked afterwards.

Figure 7-7 Default Input properties are for status-type inputs of a Bundle or Composite.

The default value is used bythe child object whenever thecomposite input is not linked,or if a “fault” or “down” statusis received on that input.

Note: Composite-leveldefault input settings overrideany corresponding defaultinput settings that exist at the

child-object level.

Default properties appear foreach status-type inputexposed among theComposite’s child objects.







Or Not to Composite

In general, all of the following statements are thought to be true. Please draw your

own conclusions about using the composite feature.

• There are known drawbacks when using Bundle or Composite objects to

encapsulate control logic, including:

– Control response time is affected. The container now needs to execute

during the object execution cycle, in addition to all of its child objects.

Values coming in and out of a Bundle or Composite are not “as fresh” as

when links are made directly between child objects.

Note This is why you should not “nest” composited containers—it is

recommended that a maximum of one level of encapsulation is used.

– Properties using certain data species do not work correctly when exposed

through a Bundle or Composite. See the “Bundle Issues” section on page 7-16 for more details.

Note Control logic using Bundle-to-Bundle and/or Composite-to-Composite

links has proven particularly problematic. Make control logic links

directly between control and apps objects, whenever possible.

• If the control logic in a composited container needs to be modified, some of the

composite’s properties may first require unlinking, even if they appear

unrelated to modifications. See the “Deleting Properties” section on page 7-11.

• GxPages are often (and quite successfully) not “composited.” In this case, links

need to be made directly from control and apps objects to the contained Gxobjects—individually, and one-at-a-time.

– For unique applications, existing only once or twice, this is fine.

– In the case of an application that is replicated many times, yet wholly

contained within the same station, this is typically not an issue. This

assumes, of course, that the application is built such that a parent container

contains the complete application—including the GxPage container(s),

containers with control objects, apps objects, and all links among them.

– In the case of an application that is replicated many times, but parted out

between stations (think Web Supervisor for GxPages and possibly logs,

JACE-4/5 for control logic), a significant linking effort may be needed.

Each Gx object on each GxPage of each application will require to beindividually linked. In this case, composites of GxPages in the Web

Supervisor (along with Bundled control logic in the JACE-4/5) can save

much engineering time as a result of the linking “match” feature.

• Bundle and Composite objects exist to be “composited.” If child properties are

not exposed, either type functions like the simpler Container. However, the

Bundle or Composite is still processed by the control engine. For this purpose,

a Container object uses less overhead and is a better choice.






Bundle

7–14

BundleQuick reference for all properties: Table A-13

abbrev: (none); Bundle

The Bundle object is the successor to the

Composite object, offering a method toencapsulate child objects. However, the

Bundle provides more—user access to

commands and views of exposed child

objects (if linked to a GxPage composite).

Note: A Bundle is useful for linking

exposed control logic (outputs) to a

composited GxPage (inputs). However,

to avoid possible problems, do not

make “logic-to-logic” links that pass

through a Bundle or Composite.

Instead, make these links directly

between the primitive child objects.

As with Composite and GxPages objects, a

“Match” (by-name) feature is available when

linking exposed inputs and outputs.


container).



Caution Bundles have known issues associated with some link types. In addition,

performance can degrade if control logic passes through Bundle links. See the

“Bundle Issues” section on page 7-16.

Commands None from the Workspace containing the Bundle object.

For a JDE user with Admin-level write privileges, the WorkspaceEditor for a

Container provides these right-click menu commands:

• Layers —Produces the Layer Options editor for the Workspace. Not typically

used for a Bundle, as numbered layer settings apply only to Gx objects.

• Arrange —Produces the Arrange Glyphs editor, which allows you to globally

position child objects within the container’s Workspace, using display order,

name, or type. Typically used before links between objects are made.

• Reorder —Produces the Reorder editor. Allows you to change the order that

child objects are listed under the Bundle in the Tree View. It does not affect

placement of child objects on the Workspace.

• Composite —Produces the composite editor (see page 7-10).

Inputs


Outputs

(none) (none)

Inputs

Example Inputs / Outputs

Outputs

(as exposed fromchild objects)


Input / Output Property Reference for Bundle Object(only input and output types, see Table 7-2 for all properties)

Type Label / Property Name Data Species

input1

1. For a variety of reasons, inputs to contained control objects shouldgenerally not be exposed.

(as exposed in Composite Editor) (as in the exposed child object)

output (as exposed in Composite Editor) (as in the exposed child object)






Bundle

7–15

PropertiesTable 7-2 Bundle object proper ties.


S t a

t u s objectType,



these properties common to all control objects.

— —

C o n

f i g


normal,processor



typeString Read-Write: (Future Use) Defines the name ofan HTML file used for “on context” Help whenthe object’s property sheet is open in the JDE.This file must have a tridium\docs file path.

Bundle Bundle Not currentlyimplemented.

displayTypeString Read-Write: Defines the text label that appearsinside the top of the object’s shape whenviewed in the JDE Workspace.

The default is “Bundle.”

Examples: “VAV1 Logic” or “AHU Logs.”


string, including

spaces

Bundle Short text stringsare recommended,to keep the object

shape from undulyexpanding.

A l a r m

S e

t u p

alarmText Read-Write: The message text used in thealarm record for a child object alarm, providingthat object has a default hyphen (-) alarmText.



- For either, if left atdefault hyphen (-),the alarmText oralertText of thenext (up) parentcontainer is used.

alertText Read-Write: The message text used in the alertrecord for a child object alert, providing thatobject has a default hyphen (-) alertText.

-

V i s u a

l


decimalFormat Read-Write: Sets decimal precision for floatvalues of exposed inputs and output as seen onthe object’s shape in the JDE.

0 to 6,


2,no (+) sign

Has little practicaluse—does notaffect links to

outputs.icon Read-Write: Defines the “icon” used to

represent the object in the JDE Tree View.

The default is the standard “jigsaw” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/composite.gif

Any .gif fileaccessible bythe station,


SeeDescrip.

size Read-Write: Defines (in pixels) the overall sizeof the container’s Workspace. Dimensions arespecified by x (width) and y (height).

x: 10 to 1500

y: 10 to 1500

x:800 y:550

backgroundColor Read-Write: Specifies the background color ofthe container’s Workspace.

Any color, asset in the

Color Editor

(white)r255, g255

b255

alarmPageUrl Read-Write: (Future Use) Specifies the URL todisplay on alarm.


E n g


maxExecuteTime,averageExecuteTimeuserData

Properties common to Bundle, Composite, andGxPage container objects. For moreinformation, see Table 7-1 on page 7-6.

— —



General,

7 others

General






Bundle

7–16

Bundle NotesThe following topics apply to Bundle objects:

• When to Use

• Bundle Issues

• Example

When to Use In this particular scenario, using Bundle objects can save engineering time:

1. An application with GxPages is replicated many times.

2. The Web Supervisor contains the GxPages, but control logic resides in JACEs.

In this case, you can save considerable linking time between stations by using the

“Match” feature to link between composited GxPages (Web Supervisor) and

application control logic in JACEs (residing in Bundles). However, note that

consistency is required when assigning names to composite properties in both the

Bundle and the GxPage. See “Example” on page 7-17.

Bundles (or Composites) are not recommended for links between control objects,however, because of known issues. See “Bundle Issues.”

Notes • Bundles are used in all of the standard Niagara applications (tridiumx/lib JAR,

applications folder). In these applications, Bundles are the containers used to

hold control objects and log objects. The Bundle scheme supports division of

an application between two stations—bundled control logic in the JACE

station, and the composited GxPages (and perhaps bundled logs) in the Web

Supervisor. The time-saving feature is realized when linking graphics-to-logic

(or logs-to-logic) between stations, using the “Match” command.

• The lib applications demonstrate good techniques for using Bundle objects.

Bundle Issues Bundle (and Composite) objects have several known limitations and issues. Please

review Table 7-3 carefully to avoid incorrect use when exposing child objects.

Table 7-3 Bundle (and Composite) object l imitations, general guidelines.

Known Limitations General Guidelines

Exposed inputs and outputs that use the following dataspecies do not work consistently.

Therefore, do not expose inputs or outputs of these types:

• Any that use a “non-native” Niagara types, such as:LON (SNVT) types. For example, LonOccupancyEnum,

SnvtSwitchValueType, and so forth.• slaveIn

• slaveOut

• priorityArray


Avoid exposing inputs (of any type) to any contained control

objects and apps objects (Calendar, Schedule, and Program). Ifan input is exposed, then any link to it must pass through theBundle. This adds an extra overhead of Bundle processing.

Instead, when bundling these objects for linkage to composited

GxPages, it is recommend to expose only outputs (not inputs).This is only logical, as a composited GxPage has only inputs.Note you can still link directly to outputs of exposed objects toinputs of other control objects. Control response does not suffer,because additional Bundle object execution time is not a factor.

Note: Inputs to log objects (AnalogLog, BinaryLog, etc.) can besuccessfully exposed in a Bundle.

A Bundle within a Bundle does not operate correctly. Never “nest” a Bundle or Composite object within anotherBundle or Composite object.






Bundle

7–17

Example The following example is from a standard applications in the tridiumx/lib JAR

(tridiumx/lib/applications//tridiumx/lib/applications/VAV_Type_1.sns). This

application uses two Bundle objects—one with control logic, the other with logs.

Figure 7-8 Dividing a “bundled” application between two Niagara stations.

At right, the sns file for theapplication has been copiedfrom the Local Library andpasted into the station for theWeb Supervisor (MyStation).

Also, the container“FunctionGenerators” wasmoved under the Bundleobject named “Control”(using the Tree View anddragging the container to theControl container, selecting“Move” after dropping).

This was done because the

“Control” Bundle will be cutand pasted next, and theFunctionGenerator links arewanted intact.

At right, the Tree View is usedto cut the “Control” Bundlefrom the Web Supervisorstation.

This leaves the Bundle forlogs (“Logs”) and thecomposited GxPage in theWeb Supervisor.

At right, the Tree View is usedto paste the “Control” Bundleinto a JACE controller station(CntrlEngSvcTest). In thiscase, the Bundle is pastedinside a Container named

“Logic.”Because this application wasbuilt using Bundles, thenecessary external linksbetween the GxPage(graphics), logs, and controllogic can be done quicklyusing the “Match” feature(Figure 7-9).






Bundle

7–18

This example continues as the interstation (external) links are made.

Left to do in this specific application: link (or cut, paste, and link) the Schedule object

(in the Web Supervisor) to the “OccStatus” object inside the “Control” Bundle.

Figure 7-9 Using the “Match” feature when linking a Bundle object.

Linking between objects indifferent stations is doneusing the Tree View and

right-click commands“Link From”, “Link To <obj>”.

At right, the compositedGxPage (“Graphics”) isselected as “From”, and theBundle “Control” (in the JACEstation) is selected as “To.”(This order can be reversedwith the same results.)

The Link Editor appears,showing the exposed inputsin the GxPage and theexposed outputs of theBundle.

Because exposed propertiesof the GxPage and theBundle were named carefully,a single “Match” commandarranges for 7 links to bemade. Selecting OK results inall 7 external links to be madefrom the Bundle to the

GxPage.

Note: In this specific app, theinput “ZoneTempText” shouldalso be linked to the output“ZoneTemp”.

At right, the externalpublications are shown in theBundle outputs, and theexternal subscriptions areshown in the compositedGxPage.

The same type of “Match” link

can also be made betweenthe “Logs” Bundle (in the WebSupervisor) and the “Control”Bundle in the JACE station.






Composite

7–19

CompositeQuick reference for all properties: Table A-17

abbrev: (none); Composite

The Composite object is mostly for legacy

support—it is largely replaced by the Bundle object . The Composite object provides the

identical method to encapsulate child objects,

however (unlike the Bundle object), it does

not provide command or view access to

exposed child objects. Composites are used

mostly for simple logic applications.

Note: The Composite has the same link

and performance issues as the Bundle.

As with Bundle and GxPages objects, a

“Match” (by-name) feature is available when

linking exposed inputs and outputs.


container).



Caution As with Bundles, Composites have known problems associated with some link

types. In addition, performance can degrade if control logic passes through

Composite links. See the “Bundle Issues” section on page 7-16.

Commands None from the Workspace containing the Composite object.

For a JDE user with Admin-level write privileges, the WorkspaceEditor for a

Composite provides these right-click menu commands:


used for a Bundle, as numbered layer settings apply only to Gx objects.




• Reorder —Produces the Reorder editor. Allows you to change the order thatchild objects are listed under the Bundle when expanded in the Tree View. It

does not affect placement of child objects on the Workspace.


Inputs


Outputs

(none) (none)

Inputs


Outputs



Input / Output Property Reference for Bundle Object(only input and output types, see Table 7-4 for all properties)


input (as exposed in Composite Editor) (as in the exposed chi ld object)output (as exposed in Composite Editor) (as in the exposed child object)






Composite

7–20

PropertiesTable 7-4 Composite object proper ties.


S t a

t u s objectType,




— —

C o n

f i g


normal,processor



typeString Read-Write: (Future Use) Defines the name ofan HTML file used for “on context” Help whenthe object’s property sheet is open in the JDE.


Composite Composite Not currentlyimplemented.


The default is “Composite.”

Examples: “8-AND” or “RTU Logic.”



Composite Short text stringsare recommended,to keep the objectshape from undulyexpanding.

A l a r m

S e

t u p




- For either, if left atdefault hyphen (-),the alarmText oralertText of thenext (up) parentcontainer is used.See “Alarm andAlert Text,” page7-5.


-

V i s u a

l


decimalFormat Read-Write: Sets decimal precision for floatvalues of exposed inputs and output as seen onthe object’s shape in the JDE Workspace.

0 to 6,(+) sign,

no (+) sign

2,no (+) sign Has little practicaluse—does notaffect links tooutputs.


The default is the standard “jigsaw” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/composite.gif




Seedescrip.


x: 10 to 1500

y: 10 to 1500

x:800 y:550



Color Editor

(white)r255, g255

b255



E n g


maxExecuteTime,averageExecuteTimeuserData


— —






Composite

7–21

Composite NotesComposite objects offer less features than Bundles, but have the same types of link

and performance issues. For this reason, they are seldom used. Exceptions include

legacy support (older Niagara stations) or only the simplest logic applications.

Note In general, control logic that requires fast processing should not be engineered with

links passing through Composite objects. Instead, these types of links should be

made directly between the primitive control objects.

Example The Composite shown in Figure 7-10 is used to simplify an 8-input AND logicoperation. This example Composite contains only cascaded Logic objects. Likely,

this Composite application will be reused in the station.

Figure 7-10 Example Composite object representing 8-input logic gate.



General,

7 others

General

Table 7-4 Composite object propert ies. (continued)


The IOBar view in the WorkspaceEditorfor a Composite’s child objects liststhe exposed inputs and outputs.

How the Compositeappears on itsWorkspace.






Container

7–22

Container Quick reference for all properties: Table A-18

abbrev: (none); Container

Container objects are simple holders of other

objects—both primitive types and/or othercontainers. They are the most frequently used

container type in a station database.

You can nest multiple levels of Containers in

a station database, as needed. Like the

PollAlways and PollOnDemand containers,

Containers are not executed by the station’s

control engine.

Note: Use a LonContainer in place of a

Container when engineering a

Honeywell XL15C application. A

LonContainer appears identical to aContainer, however, it provides

additional validation routines. The

LonContainer is in the Local Library,

tridiumx/lonworks/containers folder.


container).


sum of all resource counts of all child objects.

Commands None from the Workspace containing the Container container.

However, for a JDE user with Admin-level write privileges, the WorkspaceEditor for

a Container provides these right-click menu commands:


used for a Container, as numbered layer settings apply only to Gx objects.





child objects are listed under the Container, when expanded in the Tree View.It does not affect placement of child objects on the Workspace.

Inputs


Outputs

(none) (none)

Inputs


Outputs

(none (none)

Input / Output Property Reference for Container Object(only input and output types, see Table 7-5 for all properties)


input — — —

output — — —






Container

7–23

Properties

Container NotesContainers are often the most commonly used container type in a station database.

Functionally, the Container is identical to the PollAlways object—the difference is in

name (objectType) and the Tree View appearance (icon) only. You can use the two

container types interchangeably, as needed. However, under a device integration, use

of PollAlways container is recommended, especially if also using PollOnDemand

containers.

Table 7-5 Container ob ject proper ties.


S t a

t u s objectType,

statusFlags


these properties common to all containers.

— —

C o n

f i g description (For each)



container

A l a r m

S e

t u p


- For either, if left atdefault hyphen (-), thealarmText or alertTextof the next (up) parentcontainer is used.See “Alarm and AlertText,” page 7-5.


-

V i s u a

l



The default is the standard “folder” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/folder.gif




Seedescrip.


x: 10 to 1500

y: 10 to 1500

x:800y:550



Color Editor

(white)r255, g255

b255



S e c u r i t y securityGroups Read-Write: Shows the security groups to which

the object is assigned. For more details, see“Security Groups and Containers,” page 7-5.

General,

7 others

General






GxPage

7–24

GxPageQuick reference for all properties: Table A-36

abbrev: (none); GxPage

The GxPage object provides a graphical

window into the system. It can contain only Gx objects, the components for making a

graphical user interface. Gx objects have

inputs for linkage to outputs of control and

apps objects in stations. Real-time updates

are displayed while the graphic is being

viewed in the JDE, and command and view

access is provided for commandable objects.

If the station is running the WebUIService,

GxPages can be accessed in an identical

manner using a Web browser. A GxPage

maintains an open connection back to the

station serving the information. This allows

the display to continue updating in real-time

as values change.

A GxPage can be used as a simple container

or have inputs exposed in a composite form.

Typically, a composite is made only if also

engineering composited Bundles. When

composited, a “Match” (by-name) feature is

available when linking exposed inputs.

Parent Dependencies: None (any container).

Child Dependencies: Only Gx objects.

Resource CountRange

54 to 77, plus the sum of all resource counts of child Gx objects.

Commands None from the Workspace containing the GxPage container.

For a JDE user with Admin-level write privileges, the WorkspaceEditor for a GxPage

provides these right-click menu commands:

• Layers —Produces the Layer Options editor for the GxPage’s Workspace. This

is a useful command, as numbered-layer settings apply only to Gx objects.• Arrange —Produces the Arrange Glyphs editor, which allows you to globally


name, or type. Typically not used in a GxPage Workspace.


child objects are listed under the GxPage, when expanded in the Tree View. It

does not affect placement of child objects on the Workspace.


Inputs


Outputs

(none) (none)

Inputs


Outputs


(none possible)

Input / Output Property Reference for GxPage Object(only input and output types, see Table 7-6 for all properties)


input (as exposed in Composite Editor) (as in the exposed child object)

output (none possible) —






GxPage

7–25

PropertiesTab le 7-6 GxPage proper ti es .


S t a

t u s objectType,




— —

C o n

f i g


normal,processor



typeString Read-Write: (Future Use) Defines the name ofan HTML file used for “on context” Help whenthe object’s property sheet is open in the JDE.


GxPage GxPage Not currentlyimplemented.


The default is “GxPage.”

Examples: “GxP1” or “AHU1 Gx.”



GxPage Short text stringsare recommended,to keep the objectshape from undulyexpanding.

A l a r m

S e

t u p alarmText Read-Write: Does not apply to this object. — - Child objects (Gx

types) are notalarmable.

alertText Read-Write: Does not apply to this object. -

V i s u a

l


decimalFormat Read-Write: Sets decimal precision for floatvalues displayed at exposed inputs (as seen onthe object’s shape in the JDE).

0 to 6,


2,no (+) sign

No real use—doesnot affect GxPagedisplay of analogs.

icon Read-Write: Defines the “icon” used to

represent the object in the JDE Tree View.The default is the standard “3 Blocks” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/gxPage.gif

Any .gif file that

can beaccessed bythe station,


See

descrip.


x: 10 to 1500

y: 10 to 1500

x:800 y:550



Color Editor

(white)r255, g255

b255

Often set to acolor, especially ifbackground layerimage is not used.

alarmPageUrl Read-Write: (Future Use) Specifies the URL to

display on alarm.

— — Not currently

implemented.templateUrl Read-Write: Specifies the swid to an HTML

template used to frame the GxPage graphic (bythe Gx servlet). If left blank, the global HTMLtemplate referenced in the WebUIService(config property gxPageTemplateUrl) is used.


HTMLtemplate.

—






GxPage

7–26

GxPage NotesGxPage objects provide the graphical user interface for a Niagara system. They can

depict everything from site maps, floor plans, mechanical equipment, or virtually any

needed graphic. For some examples, refer to the Niagara demo and demoR2

databases that are distributed on the Niagara installation CD.

Typically, you engineer GxPages only on stations running the WebUIService, so that

its GxServlet can make their graphics available to ordinary Web browsers. For largersystems, GxPages are typically the primary function of the Web Supervisor station.

Refer to GxPages, Gx objects, and related topics are explained in detail in the document

Niagara Web Solutions Guide. Please refer to it for specific examples.

Layer Control Unlike with other containers, use of layers is typical in a a GxPage, and corresponds

to layer assignments given child (Gx) objects. Layer control for a GxPage is available

using the Layers command, listed in the right-click menu of its WorkspaceEditor.

E n

g i n e e r i n g minExecuteTime,

maxExecuteTime,averageExecuteTime

userData


— —


which the GxPage is assigned. See “SecurityGroups and Containers,” page 7-5.

General,

7 others

General

Table 7-6 GxPage propert ies. (continued)







GxPage

7–27

Figure 7-11 Layer Options dialog to set GxPage layer control.

There are 8 layers of primary importance in a GxPage, namely:

• top

• layer_1

• layer_2• layer_3

• layer_4

• layer_5

• layer_6

• background

Layer assignments of contained Gx objects determines “overlap behavior” of the

objects when viewed in the GxPage. Layers above are listed from highest to lowest

overlap priority (layer “top” overlaps “layer_1,” which overlaps “layer_2,” and so

on). The lowest layer is background.

By default, newly-added Gx objects are assigned to layer_3. Overlap control is

initially determined by the order of creation (newer objects appear on top).

Note You should assign overlapping Gx objects to separate layers, and not rely on creation

order. Otherwise, problems may develop when the station database is exported and

imported, for example, during a Niagara release upgrade.

These are thedefault layersettings for aGxPage.






GxPage

7–28

By default, all 8 of these layers in a GxPage are visible and enabled, except the lowest

(background) layer, which is visible but not enabled (Figure 7-11). In general, you

should keep all layers visible. If a layer is not enabled, you cannot select (more

importantly, move) objects assigned to it. This is particularly useful after adding and

sizing a GxImage, say, and then assigning it to the background layer.

Notes • Layers assigned as not visible disappear only when using the JDE. If a GxPage

is viewed in a browser, all 8 layers are visible (regardless of layer settings).

• Layer settings are independent for WorkspaceEditor and Workspace views.

Usually, however, only WorkspaceEditor layer settings are used in GxPages.

GxPagecomposites

Using the composite editor, any GxPage can be “composited,” meaning selected

inputs can be exposed at the container-level. This is typically done only when also

engineering control logic in Bundles, for use in widely-replicated applications. Using

this scheme can save considerable linking time, particularly if a GxPage and the

source control and apps objects reside in different stations.

Notes • Composited GxPages are used in the collection of standard Niagara

applications (tridiumx/lib JAR, applications folder), along with Bundle objects

for control logic and logs. In general, the lib applications demonstrate good

techniques for using composited container objects.

• See the “To Composite” section on page 7-9 for more information.






PollAlways

7–29

PollAlwaysQuick reference for all properties: Table A-64

abbrev: (none); PollAlways

PollAlways objects are actually the same as

Container objects, merely simple holders ofother objects—both primitive types and/or

other containers. Like the Container and

PollOnDemand containers, PollAlways

objects are not executed by the station’s

control engine.

PollAlways containers are recommended in

place of Containers whenever engineering

under a specific device integration (BACnet,

Modbus, DMS, GCM, etc.), and the

continuous polling of contained shadow

objects is needed. Their use makes it clearer

in the Tree View, especially when

PollOnDemand containers are also used.


container).


sum of all resource counts of all child objects.

CommandsIn its JDE Workspace, a PollAlways object has no commands.

However, for a JDE user with Admin-level write privileges, the WorkspaceEditor fora Container provides these right-click menu commands:


used for a Container, as numbered-layer settings apply only to Gx objects.





child objects are listed under the PollAlways container in the Tree View.

Inputs


Outputs

(none) (none)

Inputs


Outputs

(none (none)

Input / Output Property Reference for PollAlways Object(only input and output types, see Table 7-7 for all properties)


input — — —

output — — —






PollAlways

7–30

Properties

PollAlways NotesPollAlways containers are functionally the same as Container containers.

Note that icons for the two types of “poll” containers appear slightly different in JDE

Tree View.

• The PollOnDemand container shows a diagonal line through it:

• The PollAlways container shows no diagonal line:

Table 7-7 PollAlways object proper ties.


S t a

t u s objectType,

statusFlags



— —

C o n




PollAlways

A l a r m

S e

t u p




-

V i s u a

l



The default is the “double handset” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/pollAlways.gif




Seedescrip.


x: 10 to 1500

y: 10 to 1500

x:800y:550



Color Editor

(white)r255, g255

b255





General,

7 others

General






PollOnDemand

7–31

PollOnDemandQuick reference for all properties: Table A-66

abbrev: (none); PollOnDemand

PollOnDemand objects are simple containers

like Container and PollAlways objects, butwith one important difference: the polling of

child integration (shadow) objects occurs

only when linked Gx objects (graphics) are

being viewed. This “on-demand” polling

scheme helps overall polling efficiency for

many Niagara integrations.

This feature (and object) is supported for

most Niagara integrations using a polling

method, including BACnet, DMS, GCM,

Johnson N2, and others. It does not apply,

however, to LonWorks shadow objects.

Note: PollOnDemand containers are

recommended to hold shadow objects

used only for system monitoring and

user interface. However, you should use

PollAlways containers to hold shadow

objects used in control logic or for data

logging. See the Caution on page 7-33.


container).

Resource Count Range: 30 to 42, plus thesum of all resource counts of all child objects.

CommandsIn its JDE Workspace, a PollAlways object has no commands. However, for a JDE

user with Admin-level write privileges, the WorkspaceEditor for a Container

provides these right-click menu commands:


used for a Container, as numbered-layer settings apply only to Gx objects.



name, or type. Typically used before links between objects are made.• Reorder —Produces the Reorder editor. Allows you to change the order that

child objects are listed under the PollAlways container in the Tree View.

Inputs


Outputs

(none) (none)

Inputs


Outputs

(none (none)

Input / Output Property Reference for PollOnDemand Object(only input and output types, see Table 7-8 for all properties)


input — — —

output — — —






PollOnDemand

7–32

Properties

PollOnDemand NotesA shadow object in a PollOnDemand container polls only while a linked Gx object

is viewed (typically in a GxPage graphic). This dynamic polling is “automatic”, and

applies whether the Gx object is being viewed in the JDE or in a Web browser

connection.

Icons for the two types of containers appear slightly different in JDE Tree View.

• The PollOnDemand container shows a diagonal line through it:• The PollAlways container shows no diagonal line:

Figure 7-12 shows a PollOnDemand object used in a BACnet integration.

Table 7-8 Pol lOnDemand object propert ies.


S t a

t u s objectType,

statusFlags



— —

C o n




Poll OnDemandContainer

A l a r m

S e

t u p




-

V i s u a

l



The default is a “double handset, lined” graphiccontained in the coreUI module JAR file:

/tridium/images/icons/pollOnDemand.gif

Any .gif file thatcan beaccessed bythe station,


Seedescrip.


x: 10 to 1500

y: 10 to 1500

x:800y:550



Color Editor

(white)r255, g255

b255





General,

7 others

General




Niagara Standard Programming Reference Revised: September 30, 2006 (Notes this page only)


PollOnDemand

7–33

Figure 7-12 PollOnDemand containers for BACnet shadow objects linked to Gx objects.

Caution Shadow objects in PollOnDemand containers should only be linked to Gx objects,

and not to other control objects (or log-type objects). If the linked Gx objects are in

a GxPage container, this provides dynamic system monitoring for a user, including

right-click command access. However, when not being polled, shadow object’s

output(s) typically go to an outOfService status. Also, following a station restart,outputs of unpolled objects may initialize as “0” if analog, or “inactive” if binary.

Notes • After viewing linked Gx objects in JDE, polling will continue for the

associated shadow objects in PollOnDemand containers until that view is

removed from the view cache. Typically, this means 4 view changes before

polling stops.

• Polling can continue for up to 45 seconds after the linked shadow object is no

longer being viewed, or after the JDE view cache is overwritten.

• Shadow objects must be directly contained in a PollOnDemand container forthe poll on demand effect. Being in another container type under a

PollOnDemand container is not a valid poll-on-demand configuration.

• Linkage to any of the single-input type Gx objects is supported when using

shadow objects in a PollOnDemand container. This includes types GxText,

GxBoolean, GxDamper, GxFan, GxFloat, and GxInteger.

• Linkages to multi-input Gx types, such as GxSpectrum and GxTimePlot, are

not supported from shadow objects in a PollOnDemand container.

BACnetDevice objectoperates like aPollAlways container forany directly contained

shadow objects.

You can create otherPollOnDemand and/orPollAlways containersunder the BACnetDeviceand move (or cut and paste)shadow objects to them.






ServiceContainer

7–34

ServiceContainer Quick reference for all properties: Table A-71

abbrev: services

A station has a single ServiceContainer

object, which is automatically created by the New Station wizard. The ServiceContainer

resides in the station root.

The ServiceContainer holds all standard and

optional Niagara services used by the station.

The object itself has few configuration

properties, and no inputs or outputs. It is

unique in that it also has no Workspace view.

The default view for the ServiceContainer is

the ServiceManager view, available only for

JDE users with Admin privileges. The

ServiceManager provides a table listing allstation services, with quick access to

available commands for each service.

Parent Dependencies: Station root.

Only one ServiceContainer per station.

Child Dependencies: Only service objects.

Resource Count Range: 600 and upwards,

depending on number of optional services.

Commands The ServiceContainer offers a single (but significant) right-click command from its

JDE Workspace: Restart Station. “Command, Admin” privileges are required.

Properties

Inputs


Outputs

(none) (none)

Inputs


Outputs

(none (none)

Input / Output Property Reference for ServiceContainer Object(only input and output types, see Table 7-9 for all properties)


input — — —

output — — —

Table 7-9 ServiceContainer object propert ies.



statusFlags,See Table 7-1 on page 7-6 for informationon these common container properties.

ServiceContainer

ok

—

C o n

f i g description Any desired textstring

StationServices

V i s u a


S e c u r i t y securityGroups Read-Write: The security groups to which

the container is assigned. See “SecurityGroups and Containers,” page 7-5.

General,

7 others

General “Admin” commandrights are needed forthe Restart Stationcommand.






ServiceContainer

7–35

ServiceContainer NotesDouble-click on the ServiceContainer in the JDE Tree View to open its

ServiceManager view (Figure 7-13). This view shows all currently installed Niagara

services in the station, and has two main areas:

• Services —lists each service by the object’s name, type, and description.Click on the row of any service to select it.

• Commands —provides a list of commands available for the selected service.

To issue a command, click it and then the Invoke button at the bottom.

Figure 7-13 ServiceManager is the default view for the station’s single ServiceContainer.

Go menu commands are also available for any selected service, by using the

right-click popup menu.

Figure 7-14 ServiceManager provides right-click access to properties and views of different services.

Services Commands

Invoke Command

ServiceContainer






ServiceContainer

7–36

Linking to ChildServices

The ServiceContainer can contain only Niagara service objects, a few of which have

triggerType inputs and outputs. These include the LogService, AuditLogService, and

ErrorLogService.

Although their parent ServiceContainer has no Workspace, you can still link to these

particular objects using the Tree View and the right-click “Link From” or “Link To”

menu commands.

Figure 7-15 Link to service objects using Tree View commands.





CHAPTER

8–1

8

Gx Objects

This chapter describes each of the standard Niagara Gx objects, that is, those

provided in the gx folder of the tridium JAR file. General information on Gx objects

is provided first, as follows:

• About Gx Objects

– Execution of Gx Objects

– Gx Object Categories

• Common Gx Object Things

– Common Gx Object Properties

– General Gx Object Notes

Individual Gx object descriptions follow, arranged alphabetically as follows:

Refer to For more information on building GxPage graphics, including other examples of

using Gx objects, refer to the Niagara Web Solutions Guide.

• GxBarGraph

• GxBoolean

• GxDamper

• GxFan

• GxFloat

• GxImage

• GxInteger

• GxPipe

• GxSpectrum

• GxText

• GxTimePlot





Chapter 8 Gx Objects

About Gx Objects

8–2

About Gx ObjectsGx objects are the building blocks for the graphical user interface to a station. When

placed in a GxPage container, they are the individual graphical elements of a graphic

seen in the JDE. If the station has the WebUiService, the same GxPage graphics are

viewable using a Web browser (aka the BUI, or browser user interface).

Worth mentioning is that you can use Gx objects in other containers, that is, besides

just GxPages. For example, Gx objects can be used in containers with control logic

to observe output actions or just for general annotation while using the JDE.

However, only Gx objects in GxPage containers can be viewed using the BUI.

Execution of Gx Objects

Gx objects are executed by the UiEngineService, a core service of any station. All

other types of executable objects are executed by the ControlEngineService.

Typically, the default cycleTime (500 ms) of the UiEngineService provides optimum performance. The Status tab of the UiEngineService provides statistical data,

including the total number of Gx objects in the station (objectCount property).

Usually, even Niagara stations without the WebUiService will have some Gx

objects—just few (if any) GxPages. Stations with the WebUiService typically have

GxPages, and therefore, many Gx objects. The largest holder of GxPages and Gx

objects is typically a Web Supervisor station, as this station is usually engineered to

be the “interface provider” of a multi-JACE job.

Gx Object Categories

There are several ways to categorize the 11 types of Gx objects. The basic twocategories are by shape appearance, and are:

• Pre-Designed Shapes

• Graphic File / Color-Based Shapes

Pre-DesignedShapes

Gx objects in this category have a “known form,” meaning that they do not reference

a graphics (.gif) file. However, you can change the object’s shape, including color,

size, aspect ratio, and sometimes direction.

Gx objects that fit this category are:

• GxBarGraph

• GxDamper

• GxFan

• GxPipe

• GxSpectrum

• GxText

• GxTimePlot




Common Gx Object Things



Note that when linked, most of these objects change appearance in real-time. For

example, the GxFan provides animation of a running fan, the GxDamper changes

blade positions, and so on. The GxText object, by far, is the most commonly used.

Graphic File /Color-BasedShapes

Gx objects in this category have one or more properties that reference an image, that

is, a graphics (.gif) file. Graphics include those standard images in the Local Library(tridiumx/images JAR), as well as custom-made graphics.

Alternately, most of these objects can be set to display simply as a color-filled

rectangle or ellipse, and not reference a .gif file. However, .gif usage is more typical.

Gx objects that fit this category are:

• GxBoolean

• GxFloat

• GxImage

• GxInteger

In general, use of the objects above provides a method for highly customized

GxPages.

Common Gx Object ThingsLike other objects, Gx objects have common properties and characteristics. Rather

than cover these things in detail for each object, they are explained in this section.

The following main topics apply to most, if not all, Gx objects:

• Common Gx Object Properties

• General Gx Object Notes

Notes • In this chapter (vs. other object chapters), the description for each Gx object

has no “Trigger Properties” section. Gx objects have no trigger properties.

• Likewise, the “Commands” section is absent for each Gx object description.

Gx objects have no direct runtime commands. However, if a Gx object is

linked, and the linked object is commandable (has right-click commands),

those commands may be available through the Gx object. This is determined

by the user’s security privileges and the securityGroups setting for the Gx

object. See “Providing Command Access,” page 8-6.







8–4

Common Gx Object Properties

Table 8-1 lists common Gx object properties, organized under appropriate property

sheet tabs. In the case where some property variation exists for a particular type of

object, that difference is noted in the property table for that object type.

Table 8-1 Common propert ies for Gx objects.


S t a t u s

objectType Read Only: The Gx object type. By default,a newly added Gx object uses this string inits name (until renamed).

The full string for the object type is shown,for example, GxBoolean or GxFan.


It is recommended thatyou rename any Gxobject that is to be linked,and not use defaultnames (GxText_2, etc.).

statusFlags Read Only: Current state of the object’sstatus flags. A “normal” state (no flags set)is where the status flags value is “ok”, andthe object appears normally.

The only status flag that can be set is:• down—The station is down or offline.

In the JDE, the text “Down” appearswherever real-time values would be. NoBUI access to a down station is possible.

either:

ok (no flags)

or

down

ok Unlike other someobjects, Gx objects donot directly have alarmstates. However, someGx objects are capable

of indicating the“offnormal” condition of alinked (source) object.

isVisible Read Only: Reflects the boolean statecurrently at the object input isVisible. If thisinput not linked, the default state is true.

Linking to the isVisible input offers a methodto toggle the visibility of the object. If thisinput is linked, the object is visible only whilea true (active) is present. Likewise, theobject becomes invisible while a false(inactive) is present.


true: ok The input isVisible usesa BooleanStatusTypedata species.

See “Input “isVisible”” onpage 8-7.

C o n

f i g

font

name

size

style

Read-Write: Specifies the font used for textelements within selected Gx objects. Hasthree separate elements, as follows:

• name —Selections list with font types:

– Courier

– TimesRoman

– Helvetica

– MonoSpaces

– SansSerif

– Dialog

– DialogInput

– ZapfDingbats

• size —Selection list with (from smallest tolargest): 8, 10, 12, 14, 16, 18, 20, 24, 32

• style —Selection list with:

– Plain

– Italic

– Bold

– Italic-Bold

Anycombination

Helvetica,10,

Plain

The font property appliesonly to these Gx objecttypes:

• GxBarGraph (labels)

• GxSpectrum (inputvalue)

• GxText (text)







V i s u a

l


Coordinate values are in pixels, and are

relative to the upper-left corner of theWorkspace and the upper-left corner of theobject shape.





when theobject isfirst

created.

Typically, you don’tmanually enter positionvalues, but use the

mouse to drag the objectas needed on the JDEWorkspace.

You can also use the“nudge” key shortcuts (ALT-<arrow>) to make1-pixel position changes.See “KeyboardShortcuts,” page 8-9.

size Read-Write: Defines (in pixels) the overallsize of the object: x (width) and y (height).

When working in the WorkspaceEditor, youtypically use the mouse to drag shapehandles, as needed, to resize Gx objects.Also see “Keyboard Shortcuts,” page 8-9.

x:, y:as needed forappropriate

display

varies byGx object

For Gx objects thatreference image file(s),the right-click optionGx > Size to Image, isthe best method.

layer Read-Write: The layer of the parentcontainer to which the object is assigned.

Although layers apply to most containerobjects, it is the GxPage where most layerusage is typically used.

See the “Layer Control” section onpage 7-26 for more information.

top,layer_1,layer_2,layer_3,layer_4,layer_5,layer_6,

background

layer_3 Be aware that if youoverlap Gx objects, youshould assign them to

different layers.

Otherwise, things maylook OK based on orderof creation (last on top),but after a station export(upgrade) and reinstall,Gx objects will notoverlap as intended.

hyperlinkOnClick Read-Write: Specifies if the cursor changes

to a “pointing hand” when a user mousesover, providing a hyperlink on mouse click.Choices are one of the following:

• disabled —no hyperlink (or “pointinghand”).

• binding —provides a hyperlink to thesource object’s default view (typically itsproperties).

If linked to a Schedule, Calendar, orlog-type object, this selection is oftenused. The default view for these objectstypes are not “properties,” but specialpurpose views like ScheduleEditor,CalendarEditor, and ChartLog.

• url —provides a hyperlink to the URLspecified in the hyperlinkUrl property.

disabled,

binding,url

disabled The hyperlinkOnClick

and hyperlinkUrlproperties apply to all Gxobject types except GxPipe and GxTimePlot.

If selection is url, a validURL is required in thehyperlinkUrl property.

hyperlinkUrl Read-Write: URL of the target to displayupon a mouse click, providing thathyperlinkOnClick is set to “url.”

Typically, this is a station URL (swid), butcan be any URL accessible by a user. Forexample, http://www.tridium.com.

valid URL — The hyperlinkOnClick property must be set to“url” to use this entry.

Applies to all Gx objecttypes except GxPipe andGxTimePlot.

Table 8-1 Common propert ies for Gx objects. (continued)








8–6

General Gx Object Notes

The following general topics apply to all Gx object types:

• Providing Command Access

• Input “isVisible”

• Gx Object Shortcuts

ProvidingCommand

Access

A Gx object linked to a commandable object can provide command access to a

station user, offering a right-click command menu. However, command access

requires security group command-rights to the Gx object (Figure 8-1).

Note The importance and use of Gx objects’ securityGroup properties was incorrectly

described in older (r2.1 and r2.2) versions of this document.

V i s u a l ,

c o n

t .

highlightCommandable

Read-Write: Specifies if the object’s outlinebecomes highlighted in a “mouse over” toindicate right-click commands are available.

Works only if the linked object iscommandable. If set to True, when a usermouses over the Gx object, a thin redoutline appears around the object’s border.

False, True True If False, this does notprevent any availableright-click commands.

It just doesn’t “advertise”that any are available.

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the Gx object is assigned. A usermust have the appropriate privileges in atleast one security group to view and modifyproperties.

Note: securityGroup properties are

important for any Gx object linked to anothercommandable object. It is the Gx object

securityGroup settings that are checked

against the user’s privileges, and determinewhat (if any) right-click command menu ismade available. This is the only check oncommands through a Gx object. See“Providing Command Access.”


•General

•HVAC

•Security

•Life Safety

•Group 4

•Group 5

•Group 6

•Group 7

General If the user has rights tothe parent GxPage, allGx objects will beaccessible.

If a Gx object is linked toa commandable object,the securityGroupssettings of thecommandable object arenot checked (at least forany commands through

the Gx object).

Table 8-1 Common propert ies for Gx objects. (continued)








Figure 8-1 Command access depends on Gx object securityGroup settings.

Input “ isVisible” Each Gx object has an “isVisible” input. This is in addition to the more typically-used

“binding” input that most Gx objects have.

The isVisible input uses a “BooleanStatusType” data species. This means it is

compatible with the statusOutput properties of a number of Niagara object types,

including object types BI, BO, BinaryOverride, Calendar, Logic, and Schedule (for

example). In addition, Program objects can be made with outputs using this data

species.

Input Operation

• If a Gx object’s isVisible input is not linked , it is always evaluated as True.By default, this means a Gx object is always visible.

• If a Gx object’s isVisible input is linked:

– An active (true) must be present at isVisible for the object to display.

– Whenever inactive (false), the Gx object disappears from display.

This occurs dynamically, meaning that Gx objects (shapes) may disappear

and appear while a GxPage is being viewed, for example.

Note Whenever a Gx object is not visible (isVisible = false), it disappears

completely, and right-click commands to a linked object, if any, are not

available. However, if the Gx object’s property highlightCommandable

is True, a user still sees the object’s outline when “mousing” over it.

Applications for isVisible

Applications for linking to isVisible inputs of Gx objects are up to the imagination of

the engineer designing a user interface.

This Gx object has itssecurityGroups propertyset to “HVAC” only.

Right-clickcommandmenu of thelinked object.

This user has command access because thesecurity mask provides “Std” and “Emer”Command access to the HVAC group.

Note: The securityGroup settings for the commandable object make nodifference (at least for command access through any Gx object).

If this Gx object’s securityGroups propertywas left at default (General only), this userwould not have command access throughthis object, as Command rights for theGeneral group are cleared.







8–8

Gx ObjectShortcuts

Working with Gx objects in the WorkspaceEditor (Edit mode), you should be familiar

with the following time-saving features:

• Tree View Image Reference

• Gx Submenu

• Current Selected Color • Keyboard Shortcuts

Tree View Image Reference

For Gx objects that reference one or more image (.gif) files, config properties require

a valid file path entry. Rather than typing a long file path for each image, you can use

the JDE Tree View to open the Local or Remote Library and locate the image.

To copy its file path in the Tree View, right-click on the .gif file and select Copy. You

can then use CNTRL-V to paste this file path in the appropriate property field of the

Gx object (with its property sheet opened).

Gx Submenu

Every Gx object has a right-click “Gx” submenu. The Gx submenu provides quick

access to certain properties without having to open the object’s property sheet.

Available commands (Gx > <command>) for any selected Gx object are:

• Layer —Applies to all Gx objects. It allows you to quickly to review (and if

needed), change the layer in which the object resides.

• Set String —Only for GxText (text) and GxTimePlot (displayNameA to D).

• Set Color —Applies to all Gx objects, for any color-based property. Works

with the “Current Selected Color” feature (see next section). Every Gx object

has at least one such property (borderColor or color).

• Size to Image —Applies to any graphic file-based Gx object. Automatically

sizes the object to the pixel dimensions of the referenced .gif file.

Current Selected Color

In the lower right corner of the JDE window while in Edit mode, are two small

rectangles. These show the current “selected color” and the current “active color,”

respectively.

• The active color continuously reflects the color under your mouse cursor.

• The selected color is locked, until you reset it to match the active color.

The selected color is used for any Gx > Set Color command.

By learning how to reset the current “selected color,” you can save time by using theGx > Set Color command for setting the value of color-based property (avoiding the

property sheet access). It is particularly useful for “matching” colors, as you can

capture the underlying color of whatever the cursor is resting over.







Procedure 8-1 Changing “current selected color.”

Step 1 In the WorkspaceEditor of the GxPage, click on the background (no object selected).

Step 2 Move your mouse pointer over the desired color.

Step 3 Press C on the keyboard.

The current selected color is set to match the current active color.

You can now use the Gx > Set Color command to change any color-based property

to match this color.

Keyboard Shortcuts

Positioning or resizing Gx objects occasionally requires precision that is hard to

achieve by just “dragging” with the mouse. Table 8-2 lists keyboard shortcuts that are

available for any selected Gx object.

Table 8-2 Keyboard combinations for moving and resizing Gx objects.

“Name” Keyboard

Combinations

Action performed on the Gx Object

(each is 1-pixel per arrow key press)

Nudge Keys ALT + → Nudges object towards the right, size is unchanged.

ALT + ← Nudges object towards the left, size is unchanged.

ALT + ↑ Nudges object towards the top, size is unchanged.

ALT + ↓ Nudges object towards the bottom, size is unchanged.

Shrink Keys CTRL + → Decreases horizontal size, keeps left edge anchored.

CTRL + ← Decreases horizontal size, keeps right edge anchored.

CTRL + ↑ Decreases vertical size, keeps bottom edge anchored.

CTRL + ↓ Decreases vertical size, keeps top edge anchored.

Grow Keys SHIFT + → Increases horizontal size, keeps left edge anchored.

SHIFT + ←

Increases horizontal size, keeps right edge anchored.SHIFT + ↑ Increases vertical size, keeps bottom edge anchored.

SHIFT + ↓ Increase vertical size, keeps top edge anchored.






GxBarGraph

8–10

GxBarGraphQuick reference for all properties: Table A-28

abbrev: (none); GxBarGraph

The GxBarGraph is a rectangular (bar)

shaped object for linking to a single analogvalue. It displays as a proportionally

expanding bar, moving in real-time to show

magnitude changes. In the WorkspaceEditor,

the object can be resized and rescaled by

dragging, and its orientation can be set as

either horizontal or vertical.

Object configuration properties include an

upper and lower value range, whether these

values should display as labels, and the

different colors for the value (bar), bar

background, and label text.

Visual properties allow color changes upon

“offnormal” conditions, also for the display

of the source object’s engineering units.

Additional properties specify hyperlink

related actions.


container).


PropertiesTable 8-3 GxBarGraph object propert ies.



statusFlags,isVisible

See Table 8-1 on page 8-4 for information onthese properties common to all Gx objects.

— —

C o n

f i g

foregroundColor Read-Write: Color of the value (bar) thatexpands and contracts in real-time.

Any color, set inthe Color Editor

(green)r0, g255, b0

backgroundColor Read-Write: Color of the background behind

the value (bar).

Any color, set in

the Color Editor

(gray)

r127, g127,b127

labelsColor Read-Write: Color of the text labels, includinglower and upper range (outside of bar area)and current real-time value (inside bar area).


(black)r0, g0, b0

Also, the color ofthe outline aroundthe bar area.

font

name, size, style

Read-Write: See Table 8-1 on page 8-4 formore information on font settings.

Anycombination

Helvetica,12, Plain

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxBarGraph Object(only input and output types, see Table 8-3 for all properties)


input — isVisible BooleanStatusType — binding FloatFlexBindingType

output — — —






GxBarGraph

8–11

C o n

f i g ,

c o n

t .

orientation Read-Write: Specifies how the bar moveswithin the object’s shape.

If auto (default), the bar moves in the direction

of the longest side.• horizontal causes the value bar to always

move sideways ( left-to-right).

• vertical causes the value bar to alwaysmove up and down.

auto,horizontal,

vertical

auto

minValue Read-Write: Minimum value range for the bararea. This value shows (in text) at the lowerend of the bar area, if showLabels = True.

Values received that are less than minValuedisplay as minValue (no bar).

<valid float> 0.0 maxValue must begreater thanminValue.

Otherwise, thedisplay is alwaysminValue (no bar).maxValue Read-Write: Maximum value range for the bar

area. This value shows (in text) at the upperend of the bar area, if showLabels = True.

Values received that are greater thanmaxValue display as maxValue (full bar).

<valid float> 100.0

showLabels Read-Write: Specifies whether the minValueand maxValue values display near the ends ofthe bar area, and if the current real-time valuedisplays inside the bar area.

False, True True

V i s u a

l


size Read-Write: See “size,” page 8-5.

If showLabels = True, this includes the“min/max” label area outside of the bar area.

— x:100 y:120

layer Read-Write: See “layer,” page 8-5. — layer_3

hyperlinkOnClick Read-Write: See “hyperlinkOnClick,” page 8-5. — disabled

hyperlinkUrl Read-Write: See “hyperlinkUrl,” page 8-5. — —

statusColorEnabled Read-Write: Specifies if bar and backgroundcolors change during “offnormal” status of thesource (linked) object.

• If False, object colors are always the same.

• If True, colors change by status, where:

– red and white indicate ans alarm condition.

– orange and black indicate fault condition.

False, True True Must be linked to astatusOutput forcolor changes.

flashingEnabled Read-Write: Specifies if a statusOutputflashing of the source object (unacknowledgedalarm) should be reflected by periodicallyflashing the entire GxBarGraph shape.

The entire shape flashes between visible (red)and invisible at a 1 Hz frequency, during analarm (until alarm acknowledgment).

False, True False If used, the object

must be set for

statusColorEnabled

displayUnits Read-Write: Specifies if (and how) engineeringunits of the source object display in the innerbar label (current real-time value).

none,abbreviated,

full

abbreviated Refer also to“About Units,” page 5-6.


Read-Write: See “highlightCommandable,” page 8-6.

False, True True

Table 8-3 GxBarGraph object properties. (continued)







GxBarGraph

8–12

GxBarGraph NotesThe GxBarGraph object has no “built-in” provision for a graduated scale. However,

you can create an graphic file for a properly-sized scale, and use it in a GxImage file

that you align next to the GxBarGraph.

This technique is used in the demoR2 station, for example, as shown in Figure 8-2.

Figure 8-2 “ Graduated scale” GxImage object aligned next to GxBarGraph object.

E n g

i n e e r i n g

binding Read Only: Shows the analog value receivedon the binding link.

<float value> —

boundHandle Read Only: The handle of the “linked to” object. valid ID —

boundUrl Read Only: Shows the complete station URL ofthe linked “object.property”.

valid swid Unbound

debugOn Read-Write: Allows debug on processing. False, True False



General,

7 others

General

Table 8-3 GxBarGraph object properties. (continued)


GxImage object that references a .gif graphicshowing a graduated scale. This object isusually assigned to a lower layer.

Typically (as done here), the background

color of the .gif is designated as transparent.

The GxBarGraph object shown selected here.It is typically assigned to a higher layer thanthe “graduated scale” GxImage object, andthen sized and aligned as needed.






GxBoolean

8–13

GxBooleanQuick reference for all properties: Table A-29

abbrev: (none); GxBoolean

The GxBoolean object displays one of two

images (or colors) for the boolean state of alinked object. It is commonly used with two

varying image (.gif) files of the same size.

Alternately, it can be configured to display

different colors for the two states, and set to

either a square or elliptical shape.

Note: GxBooleans can be used with an

“animated .gif” for one or both states.

However, be aware that display issues

may result when accessed by a browser

running in an older/slower client PC.

See “Animated .gif Notes,” page 8-15,for more details.

Change is typically keyed by a state (value)

change of the linked object’s output,

however, configuration permits keying from

“in_alarm”, “fault,” “unacked_alarm” and

other status flags of a statusOutput.

Visual properties permit indication of alarm

conditions and define user-access behavior.


container).


PropertiesTable 8-4 GxBoolean ob ject proper ties.





— —

C o n

f i g

activeImage Read-Write: Swid of the image to display duringan active state of the linked boolean output. An“animated .gif” is sometimes used.

valid stationswid to .gif file

— See preceding Note about limiting use ofanimated .gif files.

inactiveImage Read-Write: Swid of the image to display duringan inactive state of the linked boolean output.

valid stationswid to .gif file

—

activeColor Read-Write: Color to represent the active stateof the linked boolean output.

(for each)


(transparent)

inactiveColor Read-Write: Color to represent the inactivestate of the linked boolean output.

(transparent)

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxBoolean Object(only input and output types, see Table 8-4 for all properties)


input — isVisible BooleanStatusType

— binding BooleanFlexBindingType

output — — —

Both objects shown selectedhere are GxBooleans.

Each uses two differentimage (.gif) files to showdifferent states. The fan’sactive state is an “animated.gif”, showing spinning fanblades. See related Note.

The active state for theheating coil GxBoolean is a.gif with brighter red color(to indicate that it is On).

This “status lamp” is made withoverlapping Gx objects—a GxTexton top, and a GxBoolean (definedwith colors) on a lower layer. Anactive cycle is indicated by green.






GxBoolean

8–14

GxBoolean NotesThe GxBoolean object is widely-used with whatever desired .gif files are needed to

represent the two boolean states. If using with animated .gif files, see the next section

“Animated .gif Notes.”

C o n

f i g ,

c o n

t .

shape Read-Write: Specifies whether the shapeboundaries (inside the border area) arerectangular or elliptical. This is the area

occupied by the active and inactive colors, andbound by the border color.

rectangle,ellipse

rectangle If set to ellipse, theobject’s “footprint” isstill rectangular

(does not crop anyassigned image file).

booleanKey Read-Write: Specif ies what type of booleanstatus causes the object to change state. Thedefault, value, is typically used to show theactive or inactive status of the linked output.

Other selections show the active image/coloronly upon (one) the following conditions:in_alarm, fault, overridden, out_of_service,unacked_alarm, down.

valuein_alarm

faultoverridden

out_of_serviceunacked_alarm

down

value The value selectionworks with a bindingto any boolean typeproperty, includingstatusOutput.

Other selectionsrequire statusOutputbinding, exclusively.

borderColor Read-Write: Color of the outline around theshape (rectangle or ellipse).


(transparent)

borderWidth Read-Write: Width, in pixels, of the outline

around the shape (rectangle or ellipse).

0 to 100 2

(pixels)

V i s u a

l



If referencing image files, use “Size to Image.”

— x:32 y:32




statusColorEnabled Read-Write: Does not apply to this object. False, True True

flashingEnabled Read-Write: Specifies if the statusOutputflashing of the source object (unacknowledgedalarm) should be reflected by periodically

flashing the entire GxBoolean shape.The entire shape flashes between visible andinvisible at a 1 Hz frequency, during an alarm(until alarm acknowledgment).

False, True False If True, the Gx objectmust be linked to astatusOutput for

flashing.



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the boolean value receivedon the binding link.

Inactive, Active —


boundUrl Read Only: Shows the complete station swid ofthe linked “object.property”.

valid swid Unbound

debugOn Read-Write: Allows debug on processing. False, True False Internal use only.

S e c u r i

t y

securityGroups Read-Write: Shows the security groups towhich the object is assigned. For more details,see “securityGroups,” page 8-6

General,7 others

General

Table 8-4 GxBoolean object propert ies. (continued)







GxBoolean

8–15

Animated .gifNotes

GxBoolean objects are commonly used with animated .gif files, for example, to show

an “On” state as a running fan, pump, and so on. Animated .gif files are also

commonly used with GxFloat and GxInteger objects in a similar manner.

Prior to Niagara Release 2.3, it was recommended to limit the use of animated .gifs

to no more than two (2) Gx objects per GxPage. This was based upon a “lowest

common denominator” approach to allow client (browser user) access from a variety

of platforms. In particular, some client PCs (typically slower/older PCs) were found

to have problems displaying a GxPage.

What happened was only a few Gx objects would get “painted” on the screen

(including a few with animated .gifs), and then the processor in the client PC would

get tied up in showing the animation effect—the remainder of Gx objects on the

GxPage would not get downloaded (displayed). Typically, the faster the client PC, the

less likely this problem would occur. A user with a 120 MHz Pentium PC would be

more likely to encounter this problem than one, say, with a 1 GHz Pentium III PC.

gx.properties File

Using a “gx.properties” file on a Niagara host, you can specify a delay between the

station’s WebUIService serving of Gx objects. The delay is typically not perceptable

to a user—a GxPage will display in about the same time. However, a delay does

allow GxPages with more than two animated .gifs to display correctly across a wide

range of client PCs, including those with slower/older processors.

In r2.3.4 and later, the Admin Tool includes a menu command to access and/or create

this file on an Niagara host. Refer to “Host > Edit File,” page 1-28.

The “gx.properties” file typically has a single line in this that reads:

gi f Del ay=n

where n is the time in milliseconds. It is recommended to use 50 as a starting point, and then adjust upwards if some client PCs still encounter problems.

(Note this need will be determined by the slowest browser client.)

For example:

(nre/lib/gx.properties)

gi f Del ay=50

Note In r2.3.4 (r2.301.428), a fix was added to stop flickering of Gx objects in GxPages,

particularly objects referencing animated .gif files. Internally, this fix tracked a list of

images used during viewing, then upon Gx applet shutdown, disposed of the images.

It is possible that the original (pre-fix) behavior may work better in some cases.Starting in 2.301.429, you can disable this fix with the following additional line in

the Niagara host's gx.properties file:

di sposeI mages=f al se

If not in the host’s gx.properties file, this equates as if the value were “true.”

Note that a station restart is needed after any changes to the gx.properties file.






GxDamper

8–16

GxDamper Quick reference for all properties: Table A-30

abbrev: (none); GxDamper

The GxDamper object provides a scalable

“side-view” graphic of a parallel-blade typedamper, for linking to a single analog value.

Blades inside the damper appear, in real-time,

angled in proportion to the received value

(90º movement from full closed to full open).

In the WorkspaceEditor, the object can be

resized by dragging, and be oriented either

horizontally or vertically. Configuration

properties specify close and open values, and

the different colors for the damper blades

(foreground) and background.

Visual properties allow color changes upon“offnormal” conditions. Additional

properties specify hyperlink-related actions.


container).


PropertiesTable 8-5 GxDamper ob ject proper ties.





— —

C o n

f i g

foregroundColor Read-Write: Color of damper blades (interiorlines) that can change angle in real-time.


(green)r0, g255,

b0

backgroundColor Read-Write: Color of the background color inthe rectangular damper shape.


(gray)r127, g127,

b127

orientation Read-Write: Specifies how the interior blades(lines) are oriented within the object’s shape.If auto (default), when full open, blades areperpendicular to the longest side.

• vertical shows blade(s) as vertical when fullopen (regardless of shape aspect).

• horizontal shows blade(s) as horizontalwhen full open (regardless of shape aspect).

auto,horizontal,

vertical

auto Typically, auto isrecommended. Thisprovides a typicalschematic for aparallel-bladedamper.

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxDamper Object(only input and output types, see Table 8-5 for all properties)



— binding FloatFlexBindingType

output — — —






GxDamper

8–17

GxDamper NotesThe GxDamper object provides a continuously proportional graphic with built-in

alarm/fault status indication. It is useful whenever a side-view schematic of a

parallel-blade type damper is needed.

C o n

f i g ,

c o n t

.

closeValue Read-Write: The minimum value range, wheredamper vanes are shown fully closed.

Values received that are less than closeValue

display as closeValue (fully closed).

valid float 0.0 If the received valueis between thesetwo values, the

angle of the vanesproportionallyadjusts.

If you set closeValueto be greater thanopenValue, themin/max operationis reversed.

openValue Read-Write: The maximum value range, wheredamper vanes are shown fully opened.

Values received that are greater thanopenValue display as openValue (fully open).

valid float 100.0

V i s u a

l


size Read-Write: See “size,” page 8-5. — x:25 y:100



hyperlinkUrl Read-Write: See “hyperlinkUrl,” page 8-5. — — statusColorEnabled Read-Write: Specifies if foreground and

background colors change during “offnormal”status of the source ( linked) object.



– red and white indicate ans alarm condition.


False, True True If True, the Gx objectmust be linked to astatusOutput forcolor changes.

flashingEnabled Read-Write: Specifies if a statusOutput flashingof the source object (unacknowledged alarm)will be reflected by periodically flashing theentire GxDamper shape.

The entire shape flashes between visible (red)

and invisible at a 1 Hz frequency, during analarm (until alarm acknowledgment).

False, True False If used,statusColorEnabledmust be set to True.



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the analog value receivedon the binding link.

<float value> —



valid swid Unbound



which the object is assigned. For more details,

see “securityGroups,” page 8-6

General,

7 others

General

Table 8-5 GxDamper object propert ies. (continued)







GxFan

8–18

GxFanQuick reference for all properties: Table A-31

abbrev: (none); GxFan

The GxFan provides an animated fan graphic

for linking to a single boolean output. Bladesinside the fan rotate during an active (On)

state, and stop during an inactive (Off) state.

In the WorkspaceEditor, the object is scaled

and resized by dragging. Configuration

properties specify the fan direction (left,

right, up, down), and the different colors used

for the fan blades, fan body, and center area.


“offnormal” conditions. Additional



container).


PropertiesTable 8-6 GxFan ob ject proper ties.





— —

C o n

f i g

foregroundColor Read-Write: Color of the rotating fan blades(spokes), including the center axle.


(black),r:0, g:0, b:0

backgroundColor Read-Write: Color of the outer fan housing(which has an assigned direction).


(med. gray)r:127, g:127,

b:127

centerColor Read-Write: Color of the center area (betweenthe fan spokes).


(lt. gray)r:189, g:189,

b:189

direction Read-Write: Orientation of the outer fan shapeand output direction which affects fan bladerotation. Selections include:

• north (up)—Blades rotate counterclockwise.

• south (down)—Blades rotate clockwise.

• east (right)—Blades rotate clockwise.

• west (left)—Blades rotate counterclockwise.

east,west,north,south

east

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxFan Object(only input and output types, see Table 8-6 for all properties)



— binding BooleanFlexBindingType

output — — —

This GxFan has beenaligned over a GxImage

that provides a 3D illusion.






GxFan

8–19

GxFan NotesThe GxFan object provides an resizable graphic with built-in animation and

alarm/fault status indication. It is useful whenever a side-view schematic of a rotating

fan is needed.

V i s u a

l






statusColorEnabled Read-Write: Specifies if the fan colors changeduring “offnormal” status of the source object.



– red and white indicate an alarm condition.


False, True True If True, the Gx objectmust be linked to astatusOutput forcolor changes.

flashingEnabled Read-Write: Specifies if the statusOutputflashing of the source object (unacknowledgedalarm) should be reflected by periodicallyflashing the entire GxFan shape.

The entire shape flashes between visible andinvisible at a 1 Hz frequency, during an alarm(until alarm acknowledgment).

False, True False If used, the objectmust be set forstatusColorEnabled.



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the boolean value receivedon the binding link.

Inactive, Active —

boundHandle Read Only: The handle of the “linked to”object.

valid ID —

boundUrl Read Only: Shows the complete station swidof the linked “object.property”.

valid swid Unbound




General,

7 others

General

Table 8-6 GxFan object propert ies. (continued)







GxFloat

8–20

GxFloatQuick reference for all properties: Table A-32

abbrev: (none); GxFloat

A GxFloat object is similar to a GxBoolean

object, but is for linkage to an analog (float)value. It displays one of multiple images (or

colors) depending on the received value.

Each different image (or color) is assigned to

a specific analog range. In this manner,

display change is “incremental” (discrete).

Like the GxBoolean, a GxFloat can be

configured to displays as either a square or

elliptical shape.

Note: If used with referenced .gif files,

the right-click Gx > Size to Image

option from the WorkspaceEditor will

size the object to the size of the image.

Visual properties allow for various hyperlink

related actions.


container).


Properties

Table 8-7 GxFloat object proper ties.





— —

C o n

f i g

ranges

Low, High

Color

Image

Read-Write: Specifies the different analogranges (each from low to high), and theassociated shape color or image for each.

Ranges cannot overlap. For example rangesof 0.0 to 5.5, and 5.5 to 12.2 are OK, butranges 0.0 to 5.5, and 5.2 to 12.2 are not.

Low, High:<valid float>


valid stationswid to gif file

Low:NaN,High:NaN,

transparent,

(no image)

If using animated .giffiles, please see“Animated .gifNotes,” page 8-15.

shape Read-Write: Specifies whether the shape

boundaries (inside the border area) arerectangular or elliptical. This is the areaoccupied by the assigned range colors, andbound by the border color.

rectangle,

ellipse

rectangle If set to ellipse, the

object’s “footprint” isstill rectangular(does not crop anyassigned image file).



(transparent)

borderWidth Read-Write: Width, in pixels, of the outlinearound the shape (rectangle or ellipse).

0 to 100 2

(pixels)

Inputs


Outputs

isVisible

binding

(none)

Display Example

Input / Output Property Reference for GxFloat Object(only input and output types, see Table 8-7 for all properties)



— binding FloatFlexBindingType

output — — —

The object shown selected is aGxFloat, linked to an AO object.The GxFloat has 5 separateanalog ranges,—each

references an image (.gif) fileshowing a damper in someposition of open.

10 to 30

30 to 50 70 to 100






GxFloat

8–21

GxFloat NotesThe GxFloat object allows you to visually associate images (or colors) with specific

ranges of analog (float) values. In most cases, .gif files are referenced.

If using with animated .gif files, see “Animated .gif Notes,” page 8-15.

V i s u a l




— x:32 y:32



hyperlinkUrl Read-Write: See “hyperlinkUrl,” page 8-5. — — —



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the float value received onthe binding link.

<valid float> —


valid ID —


valid swid Unbound




General,

7 others

General

Table 8-7 GxFloat object propert ies. (continued)







GxImage

8–22

GxImageQuick reference for all properties: Table A-29

abbrev: (none); GxImage

The GxImage object can display a single

image, as referenced by its image property. Itis commonly used as a background image in

a graphic (in this case, it is typically assigned

to the background layer).




size the object to the size of the image

Visual properties provide various hyperlink

related actions. Using these functions,

GxImage objects are sometimes used as

navigational “buttons,” such as to objectviews (for example, Schedule or log objects),

or other GxPages.

A popular variation is to use “transparent”

GxImage objects (no referenced image file),

sized as needed to provide appropriate

“hotspot” hyperlinks to other views. When

used as a button or hotspot, a GxImage is

typically linked to the target object.


container).


PropertiesTable 8-8 GxImage ob ject proper ties.





— —

C o n f i g

image Read-Write: Swid of the image to display. valid stationswid to gif file

—

borderColor Read-Write: Color of the outline around therectangular image.


(transparent)

borderWidth Read-Write: Width, in pixels, of the outlinearound the image

0 to 100 2

(pixels)

V i s u a

l position Read-Write: See “position,” page 8-5. — —


If referencing image file, use “Size to Image.”

— x:32 y:32

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxImage Object(only input and output types, see Table 8-8 for all properties)



— binding FlexBindingType

output — — —

This entire background is from aGxImage object. It is assigned tothe GxPage’s background layer. Each GxImage

object shownselected is“transparent”(no referencedimage file).






GxImage

8–23

GxImage NotesA GxImage object, complete with referenced “image” property, is automatically

created whenever you use the Tree View to copy a .gif file from the Local or Remote

Library and paste it into your GxPage Workspace.

However, you will still need to use the Gx > Size to Image option for this (or

typically any other) GxImage object.

V i s u a

l , c o n

t .layer Read-Write: See “layer,” page 8-5. — layer_3





False, True True

E n g

i n e e r i n g

binding Read Only: Shows the value received on thebinding link (if any).

value of linkedproperty

—


boundUrl Read Only: Shows the complete station swid ofthe linked “object.property”.

valid swid Unbound




General,

7 others

General

Table 8-8 GxImage object propert ies. (continued)







GxInteger

8–24

GxInteger Quick reference for all properties: Table A-34

abbrev: (none); GxInteger

A GxInteger object is very similar to a

GxFloat, but is for linkage to an integervalue. It displays one of multiple images (or

colors) depending on the received value.

Each different image (or color) is assigned to

a specific integer. In this manner, display

change is “incremental” (discrete).




size the object to the size of the image

Like the GxBoolean and GxFloat, a

GxInteger can be configured to display aseither a square or elliptical shape.


“offnormal” conditions, as well as various

hyperlink related actions.


container).


PropertiesTable 8-9 GxInteger ob ject proper ties.





— —

C o n

f i g

mapping

Value

Color

Image

Read-Write: Specifies the different possibleinteger values, and the associated shape coloror image for each.

Value:<valid integer>


valid stationswid to gif file

0,

transparent,

(no image)

If using animated .giffiles, please see“Animated .gifNotes,” page 8-15.

shape Read-Write: Specifies whether the shapeboundaries (inside the border area) arerectangular or elliptical. This is the areaoccupied by the assigned value colors, andbound by the border color.

rectangle,ellipse

rectangle If set to ellipse, theobject’s “footprint” isstill rectangular(does not crop anyassigned image file).



(transparent)

borderWidth Read-Write: Width, in pixels, of the outlinearound the shape (rectangle or ellipse).

0 to 100 2

(pixels)

Inputs


Outputs

isVisible

binding

(none)

Display Example

Input / Output Property Reference for GxInteger Object(only input and output types, see Table 8-9 for all properties)



— binding IntegerFlexBindingType

output — — —

The selected object is aGxInteger that receives aLonWorks occupancy valueas an integer (from 0 to 3).A different image (.gif) ismapped to each possibleinteger state, as shown here.






GxInteger

8–25

GxInteger NotesThe GxInteger object is similar to the GxFloat, but is binding-compatible with

integer (vs. float) properties. Also, unlike the GxFloat (where different ranges are

associated with each .gif or color), the GxInteger associates individual integers with

each .gif or color.

If using with animated .gif files, see “Animated .gif Notes,” page 8-15.

V i s u a

l




— x:32 y:32




flashingEnabled Read-Write: Does not apply to this object. False, True False



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the float value received onthe binding link.

<valid float> —


valid ID —

boundUrl Read Only: Shows the complete station swid

of the linked “object.property”.

valid swid Unbound




General,

7 others

General

Table 8-9 GxInteger object propert ies. (continued)







GxPipe

8–26

GxPipeQuick reference for all properties: Table A-36

abbrev: (none); GxPipe

GxPipe objects are simple graphics elements

for showing piping. Each GxPipe depicts asingle pipe section, using 3D-type shading.

In the WorkspaceEditor, the object can be

resized and rescaled by dragging, and can be

oriented either horizontally or vertically.

Configuration properties specify pipe color

and various options for the two endpoints.

Note: It may be easier to specify the

width and height of a GxPipe directly in

its property sheet (size property, Visual

tab) rather than by dragging.

GxPipe objects are unique among Gx object

because they are “drawing-only” objects,

without a binding input or hyperlink-related

properties. They are typically assigned to a

lower layer, for example, layer 6.


container).


PropertiesTable 8-10 GxPipe object propert ies.





— —

C o n

f i g

orientation Read-Write: Specifies how 3D-effect shadingappears on the pipe section. Selections are:

• auto—darker shading along longer sides.

• horizontal—darker shading top and bottom.

• vertical—darker shading left and right sides.

auto,horizontal,

vertical

auto Typically, auto isrecommended. Thisprovides “logical”shading control.

color Read-Write: Color of the pipe section. Any color, set inthe Color Editor (blue)r0, g0,b255

Inputs


Outputs

isVisible (none)

Display Examples

Input / Output Property Reference for GxPipe Object(only input and output types, see Table 8-10 for all properties)



output — — —

Fittings and pump shown here areGxImage objects, using imagescopied from Local Library.

Each section of pipe isone GxPipe object.






GxPipe

8–27

GxPipe NotesThe default “diameter” of GxPipe object is 8 pixels. This dimension works well with

the various .gif image files that depict pipe-flange fittings (elbows and tees). These

image files can be found in the Local Library, tridiumx folder, “images” JAR:

tridiumx/images/piping

Included are a number of fittings in colors blue, light blue, orange, and red.

C o n

f i g ,

c o n t

.

endpoint1 Read-Write: Sets the graphical look of the left

end (horizontal pipe) or top end (vertical pipe).The default is “open.”

A selection list provides a variety of elbows,tees, and a cross. Affects mostly shading.

(for each)

openl_north_east

l_north_westl_south_eastl_south_west

t_northt_southt_eastt_westcross

open

endpoint2 Read-Write: Sets the graphical look of the right

end (horizontal pipe) or bottom end (verticalpipe). The default is “open.”

A selection list provides a variety of elbows,tees, and a cross. Affects mostly shading.

open

V i s u a

l



GxPipe size is often best controlled by enteringx and y values directly in the property sheet.

— x:100 y:8




General,

7 others

General

Table 8-10 GxPipe object properties. (continued)







GxSpectrum

8–28

GxSpectrumQuick reference for all properties: Table A-37

abbrev: (none); GxSpectrum

A GxSpectrum provides a rectangular-shaped

color gradient. Change in the gradient occursin proportion to a “delta magnitude” between

two analog values. These analog (float)

values are usually sourced on separate inputs.

The value of the primary input can be set to

display, in text, in the center of the shape. The

secondary (midpoint) input value can be

sourced from another link, or simply stored as

a configuration property. Additional

properties define the high, low, and mid-delta

colors, as well as analog values for the

midpoint default and gradient range.

A popular use for a GxSpectrum object is to

visually show the temperature setpoint

deviation for a specific area on a floor plan.


container).


PropertiesTable 8-11 GxSpectrum object properties.





— —

C o n

f i g

lowDeltaColor Read-Write: Gradient “low endpoint” color,which occurs when the primary value is lower than the current midpoint by the “valueDelta.”


(blue),r:0, g:0,b:255

midDeltaColor Read-Write: Gradient “midpoint” color, which

occurs when the primary value equals thecurrent midpoint (the delta between them is 0).

Any color, set in

the Color Editor

(gray),

r:127, g:127,b:127

highDeltaColor Read-Write: Gradient “high endpoint” color,which occurs when the primary value is higher than the current midpoint by the “valueDelta.”


(red),r:255, g:0,

b:0

sample Read Only: Shows an example gradient,low-to-high (from left-to-right), using thecurrently configured low, mid, and high colors.

— —

Inputs


Outputs

isVisible

binding

midPointInput

(none)

Display Examples

Input / Output Property Reference for GxSpectrum Object(only input and output types, see Table 8-11 for all properties)



— binding FloatFlexBindingType — midPointInput FloatFlexBindingType

output — — —

Each room in this floor plan isoverlaid with a GxSpectrumobject. These objects areconfigured to show roomtemp deviation from setpoint.They also provide the room

temperature value (in center).






GxSpectrum

8–29

GxSpectrum NotesThe GxSpectrum object is typically configured to show temperature setpoint

deviation. Often, the midpoint value is defined as white.

If displayText is set to True (default), the binding value automatically displays in the

center of the object shape. In this case, the source object’s engineering units are

available, depending on the setting of the displayUnits property of the GxSpectrum.

C o n

f i g ,

c o n

t .

midPointDefault Read-Write: Specifies a midpoint value used ifthe midPointInput is not linked, or if it is linkedbut has a current status of “fault” or “down.”

<valid float> 50.0

valueDelta Read-Write: Specifies the gradient value rangeused, from the midpoint to a gradient endpoint.

The total value range, from one gradientendpoint to another, is twice this amount.

<valid float> 25.0

font

name, size, style

Read-Write: Applies to the displayed text forthe binding value (if displayText = True).See Table 8-1 on page 8-4 for moreinformation on font settings.

Anycombination

Helvetica,12, Plain

displayText Read-Write: Specifies if the primary value(binding input) displays in the center of thegradient rectangle, using the selected font.

False, True True

V i s u a

l


size Read-Write: See “size,” page 8-5. — x:110 y:80layer Read-Write: See “layer,” page 8-5. — layer_3



displayUnits Read-Write: Specif ies if (and how) engineeringunits of the source object display in the innerbar label (current real-time value).

none,abbreviated,

full

abbreviated Refer also to “AboutUnits,” page 5-6.



False, True True

E n g

i n e e r i n g

binding Read Only: Shows the analog (float) valuereceived on the binding link.

<valid float> —

boundHandle Read Only: The handle of the “linked to”

object.

valid ID —


valid swid Unbound


midPointInput Read Only: Shows the analog (float) valuereceived on the midPointInput link.

<valid float> — If midPointInput isnot linked, themidPointDefaultvalue is seen.



General,

7 others

General

Table 8-11 GxSpectrum object properties. (continued)







GxText

8–30

GxTextQuick reference for all properties: Table A-38

abbrev: (none); GxText

The GxText object provides a single line of

text, with configuration properties for fonttype, size, color, and background color. It is

widely- used in these two basic applications:

• To display a real-time value or status,

when linked to a control or apps object.

Engineering units of the source output

are automatically available. Additional

static text can be added before and/or

after the real-time value, if needed.

• To display just static text (annotation),

from a single word to an entire line of

text. Typically, in this scenario, theGxText object is not linked. However,

hyperlink property settings allow it to

be used as a “button,” for example.

When displaying a real-time “statusOutput”

type value, properties allow color changes

upon “offnormal” conditions. Additional


Almost all text that appears in a GxPage

graphic must be done using GxText objects.

For this reason, it is among the most

commonly used type of Gx objects.


PropertiesTable 8-12 GxText object properties.





— —

C o n

f i g

foregroundColor Read-Write: Color of the text itself, whichappears in the selected font.


(black)r0, g0, b0

backgroundColor Read-Write: Color of the rectangularbackground behind the text.


(transparent)

font

name, size, style

Read-Write: See Table 8-1 on page 8-4 formore information on font settings.

Anycombination of

name, size,style

Helvetica,12, Plain

Inputs


Outputs

isVisible

binding

(none)

Display Examples

Input / Output Property Reference for GxText Object

(only input and output types, see Table 8-12 for all properties)



— binding FlexBindingType

output — — —

This GxPage (from the demoR2 database) includesvarious GxText objects, shown here selected. Theyare used mainly for button labels and text annotation.

Four GxText objects are shownselected here. Three of them arelinked to control objects todisplay current values. One isused only as a static label.






GxText

8–31

C o n

f i g ,

c o n

t .

text Read-Write: Static text to display, if any.

This is optional if l inking to another object forreal-time value display. In this case, the value of

that object’s property will automatically be usedas the text, providing that thedisplayBindingText property is True (default).

If needed, additional text can be entered beforeand/or after the “property value text,” using thisentry method:

optional text <value> optional textwhere “<value>” is the literal string.

For example, a text property value of:Room temperature is <value>.

would display like:Room temperature is 71.8 ºF.

(if the displayUnits property is abbreviated.)

any charactersfrom keyboard

—

displayBindingText Read-Write: If the GxText object is linked toanother object’s property, this determines if thatproperty’s value is used as the text.

False, True True True (default) istypical. If False, onlythe text (property)value is seen.

justification Read-Write: Specifies how the displayed text isaligned (left/right), within the GxText rectangle.

center, left,right

left

borderColor Read-Write: Color of the outline around therectangular GxText shape.


(transparent)

borderWidth Read-Write: Width, in pixels, of the outlinearound the rectangular GxText shape.

0 to 100 2

(pixels)

V i s u a

l






statusColorEnabled Read-Write: Specifies if text and backgroundcolors change during “offnormal” status of thesource (linked) object.



– red and white indicate an alarm condition.


False, True True If used, the objectmust be linked to astatusOutput.

flashingEnabled Read-Write: Specifies if a statusOutput flashing

of the source object (unacknowledged alarm)should be reflected by periodically flashing theentire GxText shape.

The entire shape flashes between visible (red)and invisible at a 1 Hz frequency, during analarm (until alarm acknowledgment).

False, True False If used, the object

must be set forstatusColorEnabled.

displayUnits Read-Write: Specifies if (and how) engineeringunits of the source object display with the value.

none,abbreviated,

full

abbreviated Refer also to “AboutUnits,” page 5-6.

Table 8-12 GxText object properties. (continued)







GxText

8–32

GxText Notes GxText objects are the backbone of many GxPage solutions, providing real-time

updates, descriptive hyperlink “buttons,” and general text annotations.

Linking Flexibility The “binding” input of a GxText uses a “FlexBindingType” data species. This means

that you can link a GxText object to:

• Almost any output of another object (except a trigger type), or

• An internal property of another object. Typical examples include status

properties, such as “description” or “timeOfActiveReset.” The value of the

linked property automatically becomes the displayed text.

This type of link flexibility is unique to the GxText object.

V i s

u a

l , c o n

t . highlightCommandable


False, True True

E n g

i n e e r i n g

binding Read Only: Shows the property value receivedon the binding link.

<value> —



valid swid Unbound




General,

7 others

General

Table 8-12 GxText object properties. (continued)







GxTimePlot

8–33

GxTimePlotQuick reference for all properties: Table A-39

abbrev: (none); GxTimePlot

The GxTimePlot object provides a resizeable

“x-y” type time plot, showing a real-time linegraph of up to four possible analog (float)

values. Configuration properties include

color settings for the different plotted values,

the background, and the grid lines. Additional

properties set the plot-time window (x-axis),

minimum and maximum values (y-axis), and

a unit descriptor for the y-axis.

A legend area is available, which (if enabled)

occupies an area below the time plot graph.

The legend lists an assigned label for each of

the plot values, beside its assigned color.

A GxTimePlot “starts” graphing when its

container is being viewed, with current

real-time values appearing on its right side.

Graphing continues while the connection to

the graphic remains open, with a right-to-left

scroll of the time plot as it progresses.


container).


PropertiesTable 8-13 GxTimePlot object properties.





— —

C o n

f i g

colorA Read-Write: Color of the first plotted value(received on bindingA input).

(for each)

Any color, set in

the Color Editor

(blue)r0, g0, b255

In the legend area(if enabled), the

displayed legendnames and colors isarranged asfollows:

input A input B

input C input D

colorB Read-Write: Color of the second plottedvalue (received on bindingB input).

(magenta)r255, g0, b255

colorC Read-Write: Color of the third plotted value(received on bindingC input).

(green)r0, g255, b0

colorD Read-Write: Color of the fourth plotted value(received on bindingD input).

(red)r255, g0, b0

colorBackground Read-Write: Color of the plot area’sbackground.


(white)r255, g255,

b255

Inputs


Outputs

isVisible

bindingA

bindingB

bindingC

bindingD

(none)

Display Example

Input / Output Property Reference for GxTimePlot Object(only input and output types, see Table 8-13 for all properties)



— bindingA FloatFlexBindingType

— bindingB FloatFlexBindingType — bindingC FloatFlexBindingType

— bindingD FloatFlexBindingType

output — — —






GxTimePlot

8–34

GxTimePlot NotesBesides use in GxPages, GxTimePlots are often used in other containers holding

control objects as well , so as to directly monitor outputs. An example of the latter

might include a time plot showing Loop-related values, such as its output, setpoint,

process variable, and so on.

C o n

f i g ,

c o n

t .

colorGrid Read-Write: Color of grid lines in the plotarea.


(gray)r191, g191,

b191

minValue Read-Write: Specifies the lowest value thatcan be plotted (y-axis bottom, or origin).

Appears at the bottom of the y-axis.

<valid float> 0.0 Values outside themin and maxValuerange plot as minand maxValue.

maxValue Read-Write: Specifies the largest value thatcan be plotted (y-axis top, or upper limit).

Appears at the top of the y-axis.

<valid float> 100.0

visibleDuration Read-Write: Specifies, in minutes, the timewindow that can be shown (x-axis length).

Used as the delta between the two x-axislabels (current time - visibleDuration, andcurrent time).

1 to n,(integer)

2(minutes)

A viewedGxTimePlotcontinues to scroll,and x-axis timelabels increment.

displayLegend Read-Write: Specifies whether the legend

area should appear.

False, True True

displayNameA Read-Write: Legend text for bindingA value. (for each)

any desired textstring

— If blank but input islinked, the linkedobject’s nameshows. If blank andunlinked, shows“Unbound.”

displayNameB Read-Write: Legend text for bindingB value. —

displayNameC Read-Write: Legend text for bindingC value. —

displayNameD Read-Write: Legend text for bindingD value. —

units Read-Write: Specifies the y-axis unit labelsthat display next to the minValue andmaxValue.

For selections, see “About Units,” page 5-6.

any unitsselectable fromdrop-down list

no_units(none show)

Best left at “nounits” if inputs usedifferent unit types.

V i s u

a l



If displayLegend = True, size includes thelegend area at the bottom of the shape.

— x:100 y:120


E n g

i n e e r i n g boundNameA Read Only: (for each) Shows the name of the

object linked to input bindingA, B, C, or D.(for each)

valid objectname, or

“Unbound” ifnot linked.

Unbound

boundNameB Unbound

boundNameC Unbound

boundNameD Unbound



General,

7 others

General

Table 8-13 GxTimePlot object properties. (continued)






CHAPTER

9–1

9

Notification Objects

This chapter describes the standard Niagara Notification objects, including those

provided in the tridium JAR file of the local library.

• About Notification Objects

– Classes

– Recipients

• Notification Schemes

– Linking Notes

– Common Notification Object Properties

Individual notification object descriptions follow, arranged as follows:

• NotificationClass

• ApiRecipient

• MailRecipient1



• SnmpRecipient2

• VasRecipient3

Note A BACnetRecipient object also exists, in the tridiumx, “bacnet” JAR. Its use

requires the BACnetService to be installed and configured in the station.

Refer to For detailed information on the BACnetRecipient, see the “Generating BACnet

Alarms” section of the Niagara BACnet Integration Reference. For details on the

SnmpRecipient, see the Getting Started with the Niagara SNMP Service document.

For more details on the Vykon Alarm Service (including VasRecipient), see the

Vykon Alarm Service Installation and Configuration Instructions.

1. Prior to r2.2, equivalent was the ExtMailRecipient object (tridiumx, recipients JAR).

2. Requires optional “snmp” feature with SnmpService (tridiumx, snmp JAR).

3. Requires “vas” feature (Vykon Alarm Service), applies to Web Supervisor station only.





Chapter 9 Notification Objects

About Notification Objects

9–2

About Notification Objects Notification objects are used for event routing within the Niagara alarming

subsystem. They can reside only in (or under) the NotificationService container, one

of the core Niagara services.

There are two main categories of notification objects:

• Classes

• Recipients

Classes

The NotificationClass object is used to define different classes of notification. It is

modeled closely after the BACnet “Notification_Class” object. Largely, classes

differentiate priority levels. Classes can also delineate needs for acknowledgment.

Each NotificationClass object requires a unique notificationClass number , which is

an integer from 0 to 8388607. Classes from 0 to 255 are often used. Alternately, largernumbers can be used, for example, 1000, 12877, 56010 and so forth.

Each alarmable object can be assigned to any (one) notification class. Such objects

include the “event-type” control objects (AI, AO, BI, BO, Loop, MSI, MSO), the

Station object, and the protocol-type service objects (LonWorksService,

BACnetService, JohnsonN2CommService, plus many others).

The Niagara alarming subsystem (featuring the alarm console) requires at least one

NotificationClass defined in the NotificationService.

Master/Slave

Operation

Each NotificationClass object has a masterOut output and slaveIn input. The

application of master/slave operation is for multi-station jobs, where a configurationchange can be made in the NotificationClass in one station (usually Web Supervisor).

The change is then replicated in linked NotificationClass objects in JACE controllers.

Recipients

Several types of notification recipient objects exist, for linkage to one or more

NotificationClass objects. Recipient objects define where, how, and when a classes’

notifications are sent (in addition to the alarm console) , with the following types

available:

• ApiRecipient

• MailRecipient



• SnmpRecipient1

• VasRecipient (applies only if a Web Supervisor station)

1. Requires optional “snmp” feature with SnmpService (tridiumx, snmp JAR).




Notification Schemes



Notification SchemesA station’s notification objects can define alarm/alert distribution schemes that range

from simple to complex.

• The simplest scheme uses only a single NotificationClass object, for example,the “class_0” object created by default by the New Station wizard. By default,

priorities for the three event transition types are all assigned to 255 (lowest).

Without additional NotficationClass objects (or any recipient objects), event

notifications can occur to the alarm console for any alarmable object assigned

to notificationClass 0 (also the default). For any event-type control object (AI,

AO, BI, BO, Loop, MSI, MSO) one provision is that the object must also have

flags set in its eventEnable property. These flags specify the event

transition-types upon which to send notifications.

• More complex schemes use multiple NotificationClass objects to provide

different priority levels for the same type of event transition (“to-offnormal”,

for example). Alarmable objects could then be assigned to the appropriatenotification class, as needed.

Also, recipient objects are often added and linked to NotificationClass objects.

This provides additional alarm/event routing options (in addition to the

automatic routing to the alarm console). Each recipient object has

configuration properties that define valid days and times of operation.

Linking Notes

When linking NotificationClass objects to notification recipient objects, note that

“many-to-one” links are supported, in addition to the more typical “one-to-many.”

This means that a MailRecipient object, for example, can send event notificationsreceived from multiple notification classes (Figure 9-1).

Figure 9-1 Notification links to a recipient object support multiple notification classes.






Notification Schemes

9–4

Common Notification Object Properties

Notification objects each have a small group of properties standard to most Niagara

objects. They are explained in detail here, rather than in the section on each

notification type object.




Table 9-1 Common propert ies for al l noti ficat ion objects.


S

t a t u s

objectType Read Only: The notification object type. Bydefault, a newly added object uses thisstring in its name (unless renamed).

The full string for the object type is shown,for example, RemotePrinterRecipient.


statusFlags Read Only: Current state of the object’sstatus flags. A “normal” state (no flags set)is where the status flags value is “ok”.



either:ok (no flags)

or

down

ok Unlike some other objecttypes, notificationobjects do not havealarm states.

V i s u a

l position Read-Write: Specifies the x-y coordinates(in pixels) for the object’s position in theNotificationService container (JDEWorkspace).

— —

S e c u r i

t y



•General

•HVAC

•Security•Life Safety

•Group 4

•Group 5

•Group 6

•Group 7

General More notes onsecurityGroup settingswill go here.






NotificationClass

9–5

NotificationClassQuick reference for all properties: Table A-61

abbrev: Notif Class n (where n = class number)

NotificationClass objects provide alarm and

event-routing to the Niagara alarmsubsystem, as well as to linked recipients

(also in the NotificationService container).

Station-wide, a NotificationClass associates

with various alarm/event-generating objects

via its notificationClass number . This is a

property of the NotificationClass object

itself, plus a property of all objects capable of

generating an alarm or event.

A station may have as many notification

classes as needed (full range is from 0 to

8388607). By default, the New Station

wizard creates a single NotificationClass (0).

Apart from notification class number, there

are two important configuration properties

for each NotificationClass object:

• eventPriorities —How notifications in

that class are prioritized , according to

event types “to-offnormal” (alarm),

“to-fault,” and (return) “to-normal.”

Priorities range from 0 to 255; a lower

number indicates a higher priority.

Priorities are individually specified.• ackRequired —Which event types (as

above) require an acknowledgment .

These are separately flagged.

NotificationClass objects have “slave sync”

inputs and outputs, used to link multiple

NotificationClass objects in different

stations. This provides global editing control.

Parent Dependencies NotificationService. NotificationClass objects and recipient objects can be placed in

containers under the NotificationService, not just directly in the NotificationService.


Trigger Properties The primary “notificationOutput” output uses data species NotificationTriggerType.

It can be linked to one or more notification recipient objects.

Commands(none)

Inputs


Outputs

(none shown) (none shown)

Inputs


Outputs

slaveInnotificationOutput

masterOut

Input / Output Property Reference for NotificationClass Object(only input and output types, see Table 9-2 for all properties)


input slaveIn slaveIn SlaveSyncType

output notifica notificationOutput NotificationTriggerType







NotificationClass

9–6

PropertiesTable 9-2 Notif icationClass object propert ies.


S t a t u s

objectType,

statusFlags


these common properties.

— —

description Read-Write: Permits a user-defined textdescriptor for describing the notification class.Any printable characters, including spaces andmixed case characters, are allowed.

Seedescription

nodescription

C o n

f i g

notificationClass Read-Write: The assigned notification classnumber, reflected inside the object’s shape.

Must be a unique number among allNotificationClass objects in the station.

0 to 8388607

0 to 255typical

-1(not

functional)

Numbers can beskipped, e.g. 100,200, 300, ... 900,1000 and so on area valid collection.

ackRequired Read-Write: (BACnet application) Flags thatspecify the types of event transitions, as theyoccur, that require acknowledgment.

Events still appear in the alarm console evenfor objects using a notification class whereackRequired is cleared (not set). Also, they arestored in the EVENT.UNACKEDALARMS table(SQL db) until acknowledgment, regardless ofthis setting. In their alarm record, however, the“ackRequired” field will always show “false.”

In addition, objects that are assigned to a classwhere ackRequired is cleared (for one or moretransitions), have associated flags permanentlyset in their ackedTransitions property.

On the other hand, an event transaction typerequiring acknowledgment causes thealarmable object to send receipt of an

acknowledgment back to the supervisor’sNotificationService (upon receipt). Thisconfirms acknowledgment. The alarm/event isnot removed from the alarm console until thisreceipt of acknowledgment is received.


to-offnormal

to-faultto-normal

(allselected)

Selection”to-offnormal”applies to any

alarm state, e.g.“high-limit” or”low-limit” for anAI, AO, or Loopobject, or“offnormal” for aBI, BO, MSI, orMSO object.

eventPriorities

toOffnormal

toFault

toNormal

Read-Write: The priority assigned to each typeof event transition, namely:

• to-offnormal

• to-fault

• to-normal

Lower numbers indicate higher priority, where 0is the highest priority and 255 the lowest.

Often, higher priorities (lower numbers) are

assigned to “to-offnormal” or “to-fault” types.

(for each)

0 to 255

(for each)

255

In the alarmconsole (or alarmURL from abrowser), higherpriority alarms andevents are listedfirst (above) lowerpriority ones, evenif they are older.

V i s u a


E n g

i n e e r i n g masterOut Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync No real-time status

(or indication of amaster/slave link)is provided on theproperty sheet.

slaveIn Read Only: Always shows “SlaveSync.” SlaveSync SlaveSync






NotificationClass

9–7

NotificationClass Notes NotificationClass objects provide the necessary associations from alarmable Niagara

objects to the Niagara alarming subsystem.

The typical Niagara alarming subsystem includes these main components:

• NotificationService, including NotificationClass child objects, plus any of the

various recipient objects. Each station requires its own NotificationService.

• DatabaseService (of the Web Supervisor), which archives all received alarms

and alerts in an SQL database (Cloudscape, MS SQL, or MSDE).

• Alarm Console (from the Web Supervisor), which displays unacknowledged

alarms and alerts, referencing the SQL database. Users acknowledge alarmsand alerts, which are removed from display in the alarm console.

• Vykon Alarm Service (and Clients), where the service runs on the Web

Supervisor, and client applications can run on remote PCs to allow browser

access to monitor and acknowledge alarms and alerts. Extensive features

include pop-up notifications, links to graphics, and audible signals.

Also, an ordinary web browser user can display/acknowledge unacknowledged

alarms and alerts, again referencing the SQL database on the Web Supervisor.

This is done through the alarm servlet (URL htt p: \ \ <WebSupHost >\ al arm).

Standalone

JACE-4/5Operation

A standalone JACE-4/5 with WebUiService offers a reduced alarming subsystem,

which requires only the NotificationService (set to “archive_local_no_sql”) andwhatever required NotificationClass and recipient objects. In this case, alarms and

events are stored in a rotating buffer. Storage capacity is limited to about 250 records

for each (250 alarms and 250 alerts). Access and acknowledgment of alarms and

events is done using the alarm servlet running in the JACE-4/5 (URL

ht t p: \ \ <J ACE- 4/ 5host >\ al ar m).

Master/SlaveUsage

In a multi-station job, a “master/slave” scheme can be used among NotificationClass

objects. Typically, “master” NotificationClass objects reside in the Web Supervisor

station, and “slave” NotificationClass objects reside in JACE stations. You link them

using the masterOut (output) and slaveIn (input) properties.

A change made to any of the following properties of the “master” NotificationClassobject are replicated to the corresponding properties in linked “slave” objects:

• description

• notificationClass

• ackRequired

• eventPriorities

These properties appear as read-only slaved in the slave NotificationClass objects.



General,

7 others

General

Table 9-2 NotificationClass object properties. (continued)







ApiRecipient

9–8

ApiRecipientQuick reference for all properties: Table A-6

abbrev: (none); ApiRecipient

The ApiRecipient object provides event

registration for alarms and alerts via the NodeApi. In general terms, this allows

servlets written in Java to get a “callback”

when an alarm is generated.

Application of the NodeApi and the

ApiRecipient requires Java and Javadoc

programming knowledge. For more details

on the Niagara NodeApi, refer to the online

documentation in the tridiumx subfolder,

manuals, api.

Parent Dependencies: NotificationService.


Trigger Properties Like other recipient objects, this object has a single input using data species

NotificationTriggerType. It can be linked to one or more NotificationClass objects.

Commands(none)

Properties

Inputs


Outputs

(none shown) (none)

Inputs


Outputs

notificationInput (none)

Input / Output Property Reference for ApiRecipient Object(only input and output types, see Table 9-3 for all properties)


input — notificationInput NotificationTriggerType

output — — —

Table 9-3 ApiRecipient object propert ies.



statusFlagsSee Table 9-1 on page 9-4 for information onthese common properties.

— —

C o n

f i g

validDays Read-Write: Defines the days of the week inwhich event notifications can be sent to thenode API. Can be set in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichevent notifications can be sent to the node API(on valid days of week), using a start time andend time.

If you check exclusive, event notifications aresent only outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

notexclusive

V i s u a




General,

7 others

General






MailRecipient

9–9

MailRecipientQuick reference for all properties: Table A-45

abbrev: (none); MailRecipient

The MailRecipient object is used to route

alarms and alerts as e-mail messages. Note: The MailService must be

installed and properly configured

(referencing a working SMTP host).

Configuration properties specify the

destination addresses (To: CC: BCC:), the

“subject” header, valid days and times of

operation, and whether acknowledgments

should also be routed. Additional properties

specify which fields in the notification record

are to be included in an e-mail for an alarm,

alert, and acknowledgment.





Commands(none)

Properties

Inputs


Outputs

(none shown) (none)

Inputs


Outputs


Input / Output Property Reference for ApiRecipient Object(only input and output types, see Table 9-4 for all properties)



output — — —

Table 9-4 Mai lRecipient object propert ies.




— —

C o n f i g

validDays Read-Write: Defines the days of the week inwhich routed event notifications can be sent ase-mails. Can be set in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichrouted event notifications can be sent ase-mails (on valid days of week), using a starttime and end time.

If you check exclusive, event notifications aresent only outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

notexclusive

addressToCcBcc

Read-Write: (For each) specifies the e-mailaddress(es) to which the notification is sent.A primary (To) address is required; otheraddresses are optional.

If multiple addresses are needed in an entry,use a semicolon (;) between addresses, e.g:

[email protected];[email protected]

Valid e-mailaddress,includingdomain

—

http://-/?-

http://-/?-






MailRecipient

9–10

C o n

f i g ,

c o n

t .

subject Read-Write: Specifies the subject line of thee-mail sent for any routed notification.

For example:

“Notification from Central Plant”

Used in all alarms, alerts, and (if enabled)acknowledgments.

Any desiredsubject line.

NiagaraAlarm

Typically, a subjectline under 40characters is used.

routeAcks Read-Write: Specifies if each acknowledgmentof a routed alarm or alert also generates ane-mail notification.

False, True False

alarmFields Read-Write: Defines the alarm record fields tobe included in an e-mailed notification. Anyentries checked are selected.

Each selected field appears as a separate linein the e-mail’s body text. Selections include:

• eventSwid —Object’s station swid.

• name —Object’s name.• tstamp —Timestamp when alarm occurred.

• notificationClass —Object’s class number.

• priority —Priority of the alarm (0 to 255).

• eventType —Alarm type, such as “Out ofrange” or “Change of state.”

• messageText —Object’s alarmText.

• ackRequired —Shows if acknowledgment isrequired.

• fromState —Object’s previous state condition(normal, offnormal, etc.).

• toState —Object’s state condition at the timeof the notification (offnormal, normal, etc.).

• status —Object’s current statusFlags.• newValue —Object’s value (if analog) or state

(if binary).

• setpointValue —Object’s setpoint (Looponly).

• errorLimit —Object’s high or lowLimit(analog objects only).

• deadband —Object’s alarm deadband(analog objects only).

See descrip. (Allselected)

For an alarm notification, thefirst body line in thee-mail sent is:

“Alarm receivedfrom <station>.”

Following this,each field is anadditional line.

Note that linedescriptors varyfrom propertysheet selections.For example,instead of“tstamp”, that linein the e-mailbegins with “Time:”

Table 9-4 MailRecipient object properties. (continued)







MailRecipient

9–11

MailRecipient NotesUse of MailRecipient objects requires the MailService to be installed and correctly

configured, that is, referencing a working SMTP host. If the SMTP host is incorrectly

identified, notifications routed to MailRecipient objects are stored as e-mails in the

MailService’s “outbox.” See “Outbox Notes” on page 4-37.

C o n

f i g ,

c o n

t .

ackFields Read-Write: Defines the acknowledgment (ack)record fields to be included in an e-mailed acknotification. Any checked are selected.


• eventSwid —Object’s station swid.

• name —Object’s name.

• tstamp —Timestamp when alarm occurred.


• priority —Priority of the alarm (0 to 255).

• eventType —Alarm type, such as “Out ofrange” or “Change of state.”

• toState —Object’s state condition at the timeof the notification (offnormal, normal, etc.).

• status —Object’s current statusFlags.

• ackSource —User name that acknowledged.

• timeOfAck —Acknowledgment timestamp.


For anacknowledgment notification, the

first body line in thee-mail sent is:

“Alarmacknowledged.”


Note that linedescriptors varyfrom propertysheet selections.For example,instead of“ackSource”, that

line in the e-mailbegins with“Acked by:”

alertFields Read-Write: Defines the alert record fields to beincluded in an e-mailed notification. Anychecked are selected.


• alertSwid —Object’s station swid.

• name —Object’s name.

• tstamp —Timestamp when alert occurred.


• priority —Priority of the alert (0 to 255).• alertType —Alert type, either “Runtime limit”

or “Change of state count.”

• messageText —Object’s alertText.

• alertLimit —Either elapsed active time(runtime) limit or change of state count limit.


For an alert notification, thefirst body line in thee-mail sent is:

“Alert receivedfrom <station>.”


Note that line

descriptors varyfrom propertysheet selections.For example,instead of“alertType”, thatline in the e-mailbegins with“Type:”

V i s u a



which the object is assigned. For more details,

see “securityGroups,” page 9-4

General,

7 others

General

Table 9-4 MailRecipient object properties. (continued)







MailRecipient

9–12

Example E-mails The following examples show how the “body text” for e-mail notifications appear

when default field selections (all) are selected.

• Alarm Example

• Acknowledgment Example

• Alert Example

Alarm Example

Al ar m r ecei ved f r om MySt at i on.

Ti me: 10: 28 3- Oct - 2001 EDTSwi d: / MyStat i on/ Temp/ VAV_Type_1/ Cont r ol / ZoneTempName: ZoneTempMessage: Zone Temp i s out of r angeSt atus: i nAl ar m Type: Out of r angeOl d st ate: nor malNew st ate: l ow_l i mi t

Exceedi ng Val ue: 65. 5Deadband: 5. 0Exceeded Li mi t : 66. 0Cl ass I D: 0Pr i or i ty: 5Ack r equi r ed: f al se

Acknowledgment Example

Al arm acknowl edged.

Swi d: / MyStat i on/ Temp/ VAV_Type_1/ Cont r ol / ZoneTempName: ZoneTempAl arm Ti me: 10: 38 3- Oct - 2001 EDT

Type: Out of r angeAcked st at e: l ow_l i mi tSt atus: okCl ass I D: 0Pr i or i ty: 5Acked by: Admi ni st r ator ( admi n)Ack Ti me: 10: 39 3- Oct - 2001 EDT

Alert Example

Al er t r ecei ved f r om MySt at i on.

Ti me: 10: 47 3- Oct - 2001 EDTSwi d: / MySt at i on/ AHU_Type_1/ Cont r ol / SFan

Name: SFanMessage: Mai nt enance check on AHU_1 r ecommendedCl ass I D: 0Pr i or i t y: 255 Type: Change of st at e countLi mi t : 100






PrinterRecipient

9–13

PrinterRecipientQuick reference for all properties: Table A-67

abbrev: (none); PrinterRecipient

The PrinterRecipient object is used to route

alarms and alerts to a local printer. It applies primarily to a Web Supervisor station, but can

be used in a JACE-NP station as well. It has

no application in a JACE-4/5 station.

The printer used must be working as the host

operating system’s (Windows NT or 2000)

“default” printer, and is recommended to be a

“continuous feed” type printer (typically, a

dot-matrix). Otherwise, if a “form” type

printer is used (most laser-type or ink-jet

printers), each notification printed will

consume a separate piece of paper.


Resource Count Range: 22 to 34.



Commands(none)

Properties

Inputs


Outputs

(none shown) (none)

Inputs


Outputs


Input / Output Property Reference for PrinterRecipient Object(only input and output types, see Table 9-5 for all properties)



output — — —

Table 9-5 PrinterRecipient object propert ies.




— —

C o n

f i g

validDays Read-Write: Defines the days of the week inwhich routed notifications can be printed. Canbe set in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichrouted notifications can be printed (on validdays of week), using a start time and end time.

If you check exclusive, notifications are printedonly outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

notexclusive

routeAcks Read-Write: Specifies if each acknowledgmentof a routed alarm or alert also generates aprinted notification.

False, True False

printerName Read-Write: Defines the local printer. Currently,the only valid selection is DEFAULT printer.

DEFAULT DEFAULT

V i s u a


http://-/?-

http://-/?-






PrinterRecipient

9–14

PrinterRecipient NotesThe PrinterRecipient can be used if:

• A local printer exists (attached directly to the host, that is, the Web Supervisor

PC or JACE-NP).

• This printer is installed and configured as the Windows “default” printer.

The recommended printer type is a dot-matrix style, using continuous feed paper.

The Niagara notification record for each alarm and alert routed is printed in full.

Acknowledgments are also printed, providing that routeAcks property is set to True.

In the case of a printer failure (out-of-paper, offline, powered off, etc.), the

PrinterRecipient sends an alert to the named alertNotificationClass. For such an alert,

the alertType is “equipmentFailure” and the messageText is “Printer failure.”

A l a r m

S e

t u p alertNotificationClass Read-Write: The notification class number used

in routing an alert when a problem occurs withthis PrinterRecipient.

Likely scenarios would include “out of paper”conditions, printer offline, or printer turned off.

0 to 8388607

(for BACnetcompatibility)

0



General,

7 others

General

Table 9-5 PrinterRecipient object properties. (continued)







RemotePrinterRecipient

9–15

RemotePrinterRecipientQuick reference for all properties: Table A-69

abbrev: (none); RemotePrinterRecipient

The RemotePrinterRecipient object is used to

route alarms and alerts to a networked printer.It applies primarily to a Web Supervisor

station, but can be used in a JACE-NP station

as well. It has no application in a JACE-4/5.

The printer used must be known to the host’s

operating system (Windows NT or 2000) as

an available networked printer. This means

the printer can be found on the local LAN

using the Windows “browse” feature (for

example, within the “Add Printer” function).

In addition, the printer is recommended to be

a “continuous feed” type printer (typically, a

dot-matrix). Otherwise, if a “form” type

printer is used (most laser-type or ink-jet

printers), each notification printed will

consume a separate piece of paper.





Commands(none)

Properties

Inputs


Outputs

(none shown) (none)

Inputs


Outputs


Input / Output Property Reference for RemotePrinterRecipient(only input and output types, see Table 9-6 for all properties)



output — — —

Table 9-6 RemotePrinterRecipient object properties.




— —

C o n

f i g

validDays Read-Write: Defines the days of the week inwhich routed notifications can be printed. Canbe set in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichrouted notifications can be printed (on validdays of week), using a start time and end time.

If you check exclusive, notifications are printedonly outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

notexclusive

routeAcks Read-Write: Specifies if each acknowledgmentof a routed alarm or alert also generates aprinted notification.

False, True False

http://-/?-

http://-/?-







9–16

RemotePrinterRecipient NotesThe RemotePrinterRecipient can be used to route alarms and alerts to any networked

(LAN) printer available to the host’s Windows operating system.

The recommended printer type is a dot-matrix style, using continuous feed paper.

Other printer type typically results in a separate piece of paper for each notification.

The Niagara notification record for each alarm and alert routed is printed in full.Acknowledgments are also printed, providing that routeAcks property is set to True.

In the case of a printer failure (network down, out-of-paper, offline, powered off,

etc.), the RemotePrinterRecipient sends an alert to the named alertNotificationClass.

For such an alert, the alertType is “equipmentFailure” and the messageText is

“Printer failure.”

C o n

f i g ,

c o n

t .

printerName Read-Write: Defines the networked printer, byname known to the Windows operating system.

A list of available networked printers

automatically appears in a drop-down selectionlist. Printers typically appear listed as:

• \\<printerHost>\DIRECT

or

• \\<PChost>\<PrinterName>(if a “shared” printer).

Any printerthat appears inthe drop-down

selection list.

noselection

Recommendedprinters aredot-matrix types.

A l a r m

S e

t u p

alertNotificationClass Read-Write: The notification class number usedin routing an alert when a problem occurs withthis RemotePrinterRecipient.

Likely scenarios would include network offlineconditions, “out of paper” printer conditions,printer offline, or printer turned off.

0 to 8388607 0

V i s u

a l




General,

7 others

General

Table 9-6 RemotePrinterRecipient object properties. (continued)







SnmpRecipient

9–17

SnmpRecipientabbrev: (none); SnmpRecipient

The SnmpRecipient object is used to route

Niagara alarms and alerts to an SNMP

(Simple Network Management Protocol)manager. It requires the SnmpService to be

installed and configured in the station

(tridiumx, “snmp” JAR).

Note: The SNMP module is an

optional, separately-licensed feature.

Notifications are sent to the SNMP manager

defined in the SnmpService. The

SnmpRecipient object has few properties,

specifying valid days and times of operation.





Commands(none)

Properties

SnmpRecipient NotesFor more details on the SnmpService, see the Getting Started with the Niagara SNMP

Driver document.

Inputs


Outputs

(none shown) (none)

Inputs


Outputs





output — — —

Table 9-7 SnmpRecipient object propert ies.




— —

C o n

f i g validDays Read-Write: Defines the days of the week inwhich routed notifications can be sent. Can beset in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichrouted notifications can be sent (on valid daysof week), using a start time and end time.

If you check exclusive, notifications are sentonly outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

notexclusive

V i s u a




General,

7 others

General






VasRecipient

9–18

VasRecipientabbrev: (none); VasRecipient

The VasRecipient object applies to a Web

Supervisor station licensed for (and running)

the VykonAlarmService. This recipient andservice are found in the tridiumx, “vas” JAR.

Note: Currently, VAS can only be

licensed for a Web Supervisor.

Notifications linked to the VasRecipient are

sent to remote Vykon Alarm Client

workstations (PCs running the VAS Client

software). Currently, only one VasRecipient

is supported under the Web Supervisor’s

NotificationService container.

The VasRecipient only has a few properties,

specifying valid days and times of operation.

Parent Dependencies: NotificationService. (Only for a Web Supervisor station with VykonAlarmService).




Commands(none)

Properties

Inputs


Outputs

(none shown) (none)

InputsAll Inputs / Outputs

Outputs





output — — —

Table 9-8 VasRecipient object propert ies.




— —

C o n

f i g

validDays Read-Write: Defines the days of the week inwhich routed notifications can be sent. Can beset in any combination.

Sun, Mon,Tue, Wed,

Thu, Fri, Sat

(all daysselected)

timeRange Read-Write: Defines the time period in whichrouted notifications can be sent (on valid daysof week), using a start time and end time.

If you check exclusive, notifications are sentonly outside of the defined period.

12:00 AMto

12:00 AM

(entirerange),

not

exclusive

V i s u a




General,

7 others

General






VasRecipient

9–19

VasRecipient NotesFor more details on VAS (Vykon Alarm Service), see the following related

documents:

• Vykon Alarm Service Installation and Configuration Instructions

• Vykon Alarm Client User’s Guide• Release Notes for VAS






VasRecipient

9–20





CHAPTER

10–1

10

Ndio Objects

This chapter describes components of the Ndio (Niagara direct input/output) module,

the station interface to the physical I/O points on certain JACE controllers and/or

JACE I/O expansion boards. This module is available as the ndio JAR under the

tridiumx folder.

Currently, Ndio applies only to a station engineered for a JACE-4

1

(with or withouta JACE-IO- XX expansion module), and not to any other Niagara host platform.

General information on the Ndio module is provided first, as follows:

• About Ndio Objects

• Ndio Containers

• Ndio Primitives

• Common Ndio Object Things

Individual Ndio object descriptions follow, arranged alphabetically as follows:

• Containers:

– NdioContainer

– NdioProcessor

• Primitives:

– Ndio0to10VInput

– Ndio0to10VOutput2

– NdioBinaryInput

– NdioBinaryOutput

– NdioHighSpeedCounterInput

– NdioResistiveInput

– NdioThermistorType3Input

Note At the time of this document, the ndio JAR contains an primitive object of

type Ndio0to20MAOutput, for future use. It is not covered in this document.

1. Some JACE-4 XX models have no integral I/O, but can accept an I/O expansion module.

2. Currently applies only to the JACE-IO- XX expansion modules.





Chapter 10 Ndio Objects

About Ndio Objects

10–2

About Ndio Objects Ndio objects represent the onboard I/O points on certain JACE controllers (some of

the JACE-4 series) and on JACE I/O expansion modules. Ndio objects are executed

in the station by the “control engine” managed by the ControlEngineService, along

with all “control” and “apps” objects—there is no special “Ndio service.”

An ndio JAR resides in tridiumx. Currently, this module has two containers and eight

different primitive objects (Figure 10-1). When engineering, you copy these objects

from the Local Library (or Remote Library of the JACE-4) into the station database.

Figure 10-1 The ndio JAR is in the tridiumx folder and contains all Ndio objects.

Ndio ContainersIn a JACE-4 station, all Ndio objects must be hierarchically organized as follows:

NdioContainer : The parent container for all other Ndio objects—it must reside in

the root of the station. Only one per station.

NdioProcessor : Resides in the workspace of the NdioContainer, it is the parent of

primitive (control) Ndio objects. Depending on the configuration of the JACE, there

may be one or more NdioProcessors.

• JACE-401 or JACE-403 (with onboard I/O) has only one NdioProcessor,

configured to be “onboard_proc_A”

Currently, a JACE-401 or 403 cannot accept an I/O expansion module.

• Any other JACE-4 series with an installed expansion module will have either

one or two NdioProcessors, as follows:

– If a JACE-IO-20 (20 point) module, only one NdioProcessor, configured

as “slot_1_proc_A”.

– If a JACE-IO-32 (32 point) module, two NdioProcessors, configured as

“slot_1_proc_A” and “slot_1_proc_B,” respectively. Each is a container

for certain inputs and outputs. See “Processor Responsibilities,” page 10-4.




Ndio Primitives



Figure 10-2 Ndio object hierarchy in a JACE-4 station database.

Note This “two-tier” container scheme is used to support JACE controller and expansion

board models that have multiple I/O processors (each with an indexed set of I/O

points). For example, the current JACE-IO-32 expansion module has two (2) I/O

processors. At some future point, additional JACE controller models may also havemultiple onboard I/O processors.

Ndio PrimitivesEach Ndio primitive represents a physical I/O point on the JACE controller. You can

copy them directly in the second-tier NdioProcessor container, or in some other child

container under it. Ndio primitives show a fault status (Figure 10-3) until you assign

them a valid ioIndex number—by default this ioIndex number is 0 (unconfigured).

Figure 10-3 Ndio objects show fault status until an unused ioIndex number is assigned.

The following subtopics apply to Ndio primitives:

• Processor Responsibilities

• Ndio UI objects

• Ndio outputs






Ndio Primitives

10–4

Processor Responsibilities

Responsibilities of the I/O processors on the various JACE-4 controllers and I/O

expansion modules are shown in Table 10-1, including numbers and types of Ndio

objects you will need in the JACE-4 station database.

• For the single I/O processor JACE-401 and 403, you copy and paste all Ndio

primitives in (or under) the only NdioProcessor container, configured as

procNum “onboard_proc_A ”.• For a JACE-4 with the JACE-IO-20 (20 point) expansion module, you copy

and paste all Ndio primitives in (or under) the NdioProcessor container

configured as procNum “slot_1_proc_A ”.

• For a JACE-4 with the JACE-IO-32 (32 point) expansion module, you copy

and paste two NdioProcessor containers under the NdioContainer, and

configure one as procNum “slot_1_proc_A ” and the other as procNum

“slot_1_proc_B”.

– Physical DOs 1—4, AOs 1—4, and UIs 1—8 are configured with Ndio

primitive objects in the “slot_1_proc_A” NdioProcessor container.

– Physical DOs 5—8, AOs 5—8, and UIs 9—16 are configured with Ndio

primitive objects in the “slot_1_proc_B” NdioProcessor container. Note that Ndio primitives in this second “B” NdioProcessor use ioIndex

assignments starting at 1 (do not match hardware terminal assignments).

Table 10-1 I/O processor responsibilities and Ndio objects for JACE-4 controllers, I/O expansion modules.

JACE-401, 403

(4 DOs, 8 UIs)

Ndio Object TypesNdioProcessor (onboard_proc_A)

— No. Physical Point ioIndex

NdioBinaryOutput 4 Digital Outputs 1—4 1—4

Ndio UI objects (various types)

8 Universal Inputs 1—8 1—8

JACE-IO-20 I/O

Expansion Module

(8 DOs, 8 UIs, 4 AOs)

Ndio Object TypesNdioProcessor (slot_1_proc_A)

—

No. Physical Point ioIndex

NdioBinaryOutput 8 Digital Outputs 1—8 1—8

Ndio0to10VOutput 4 Analog Outputs 1—4 1—4


8 Universal Inputs 1—8 1—8

JACE-IO-32 I/O

Expansion Module

(2 I/O Processors)

Total of 8 DOs, 16 UIs,and 8 AOs

Ndio Object TypesNdioProcessor A (slot_1_proc_A) NdioProcessor B (slot_1_proc_B)

No. Physical Point ioIndex No. Physical Point ioIndex

NdioBinaryOutput 4 Digital Outputs 1—4 1—4 4 Digital Outputs 5—8 1—4

Ndio0to10VOutput 4 Analog Outputs 1—4 1—4 4 Analog Outputs 5—8 1—4


8 Universal Inputs 1—8 1—8 8 Universal Inputs 9—16 1—8




Ndio Primitives



Ndio UI objects

Among the seven different types of Ndio objects, all but two represents a JACE

universal input (UI). Collectively, these objects are called Ndio UI objects.

The five types of Ndio UI objects are:

• Ndio0to10VInput

• NdioBinaryInput

• NdioHighSpeedCounterInput

• NdioResistiveInput

• NdioThermistorType3Input

When engineering a JACE station, you can select any combination of these objects

for as many physical UI points that exist on the hardware. Unlike other controllers

where universal inputs are physically configured using hardware jumpers or DIP

switches, all configuration is done “one-to-one” with Ndio UI objects in the station.

For example, for a JACE-403 having six (6) UIs, two possible station setups are:

• (6) HighSpeedCounterInput objects or

• (2) 0to10VInputs, (1) BinaryInput, (1) HighSpeedCounterInput, and

(2) ResistiveInputs

When the station is starting or running, the collection of objects configures the I/O

processor according to the ioIndex numbers you assigned them. For a JACE-401 or

403 with integral (onboard) I/O, these numbers correspond directly to the UI terminal

numbers on the JACE controller (Figure 10-4).

Figu re 10-4 The ioIndex property (Config tab) in Ndio UI objects determines how the I/O processor is configured.

For a JACE-4 with a JACE-IO-20 (20 point) expansion module, the ioIndex numbers

in the Ndio UI objects also correspond directly to hardware UI terminals 1—8.

JACE-403 UI terminalsUI1 through UI6.

This NdioThermistorType3object has been assignedto ioIndex 5 (UI terminal 5).

UI5

GWired to a Type 3 Thermistor

Temperature Sensor

I/O End of JACE-403 Board






Ndio Primitives

10–6

For a JACE-4 with a JACE-IO-32 (32 point) expansion module, you need to assign

ioIndex numbers to the 16 Ndio UI objects according to the parent NdioProcessor

container. See “Processor Responsibilities,” page 10-4.

Notes • If engineering a running JACE-4 station and you attempt to assign a duplicate(already assigned) ioIndex number for an Ndio object, you receive an error

message. The ioIndex property value remains unchanged.

• If engineering offline, there is no checking for duplicate ioIndex property

numbers. You must be careful when assigning them.

Ndio outputs

Currently, there are two types of Ndio outputs: Binary Outputs and Analog Outputs.

In addition, the JACE-IO-32 Expansion Module provides output override switches.

Binary Outputs The NdioBinaryOutput controls a digital output (DO) on the JACE controller or I/O

expansion module. Depending on the hardware platform, the DO type will vary:

• Form-C Relay

• Triac

Form-C Relay

A JACE-401 and -403 has four (4) form-C relay, SPDT outputs. The JACE-IO-32

expansion module has eight (8) form-C relay, SPDT outputs.

You can (and typically do) add the same number of NdioBinaryOutput objects for use

in the JACE-4 station database. Assign each object a unique hardware address (1–4)

again using the ioIndex property on the Config tab (Figure 10-5).

In the case of the JACE-IO-32, you must place 4 NdioBinaryOutput objects

addressed 1—4 under each of the two NdioProcessors. See Table 10-1 on page 10-4.

Figu re 10-5 The index property (Config tab) in a NdioBinaryOutput determines the digital output (1 to 4) used.

JACE-403 has four Form-Crelay outputs, 1 through 4.

N04

C4Normally open (N.O.)contacts of output 4 wired tocontrol equipment load.

This NdioBinaryOutput objecthas been assigned to ioIndex 4(digital output 4).

I/O End of JACE-4 Board




Ndio Primitives



Triac

A JACE-IO-20 expansion module has eight (8) solid state Triac outputs for on/off

control only (floating control not supported). You can (and typically do) add the same

number of NdioBinaryOutput objects for use in the JACE-4 station.

All eight NdioBinaryOutput objects are placed under the same NdioProcessor object.Assign each NdioBinaryOutput object a unique hardware address (ioIndex 1—8).

Analog Outputs Currently, only expansion boards (JACE-IO-20 and JACE-IO-32) have proportional

analog outputs, or AOs. These are voltage-only outputs, providing from 0 to 10Vdc.

• The JACE-IO-32 has eight (8) AOs; each of the two I/O processors controls 4.

See “Processor Responsibilities,” page 10-4.

• The JACE-IO-20 has four (4) AOs, controlled by its single I/O processor.

You can (and typically do) add the same number of Ndio0to10VOutput objects in the

JACE-4 station database.

Output OverrideSwitches

Currently, the JACE-IO-32 Expansion Module is the only JACE hardware that

provides on-board manual override switches. Each output (8 DO, 8 AO) has its own

local override capability, as follows:

• Each DO has a 3-position switch: 0—Auto—Hand, where the center “Auto”

position is normal, meaning the DO is under Niagara control.

While the switch is physically moved to 0 (Off) or Hand (On), that DO is

manually overridden and removed from Niagara control. In the JACE station,

the current DO state is unknown—however, there is override indication.

• Each AO has a 3-position switch: 0—Auto—Hand, where the center “Auto”

position is normal, meaning the AO is under Niagara control.In addition, each AO has an adjustable potentiometer (pot).

– If the AO switch is set to 0, the AO output is 0 volts.

– If the AO switch is set to Hand, the AO output can be manually adjusted

by turning the potentiometer.

While the switch is physically moved to either 0 or Hand, that AO is manually

overridden and removed from Niagara control. In the JACE station, the current

value of that AO is unknown—however, there is override indication.

Override Indication

Whenever the manual override switch for a DO or AO on a JACE-IO-32 is moved

away from the center (Auto) position, the corresponding NdioBinaryOutput or

Ndio0to10VOutput object in the JACE-4 station changes color to magenta (purple),

as does its statusOutput (Figure 10-6).

This results from a statusFlags property change to “overridden.”






Common Ndio Object Things

10–8

Note While the output is locally overridden, the Ndio object will continue to respond input

changes “as if” it was still under Niagara control, output changes included. However,

please understand that the output value is actually unknown the entire duration the

output is physically overridden.

Figure 10-6 Overridden output on JACE-IO-32 is indicated by object color (status) change.

Also, please be aware that for any DO that is overridden on a JACE-IO-32, the

associated NdioBinaryOutput object will continue to update historical properties

such as elapsedActiveTime (runtime) and changeOfStateCount in response to

priorityArray input changes —however, again there is no connection to “reality.”

• In the case of DO-controlled equipment, if current state, elapsed active time

and/or changes of state are critical though manual overrides, use of a UI input

(and a NdioBinaryInput object) is recommended. The UI should be wired tostatus contacts on the controlled equipment.

• In the case of an AO, if output value monitoring is critical during manual

overrides, use of a UI input (and a Ndio0to10VInput object) may be used. The

UI must be wired to the AO output to be monitored.

Common Ndio Object Things Ndio primitive objects closely resemble standard Niagara control objects in linkable

properties, Config properties, commands, and behavior. Table 10-2 lists the four

control objects (Chapter 5, “Control Objects”) that are most similar.

This 0to10VOut object is for an AOthat is currently overridden on theJACE-IO-32.

The output currently shows “10.00,”but the actual value is unknown.

This NdioBO object is for a DO that iscurrently overridden on the JACE-IO-32.

The output currently shows “Inactive,”but the actual state is unknown.

Table 10-2 Standard control objects most like the various Ndio objects.

Standard Niagara

Control Object

Ndio Object Counterparts

AnalogInput Ndio0to10VInput, NdioHighSpeedCounterInput1, NdioResistiveInput,NdioThermistorType3Input

AnalogOutput Ndio0to10VOutput




Common Ndio Object Things



Please refer to the four control objects above for details on topics such as alarming.

In addition, the following sections provide detailed information about topics

common to both control objects and Ndio objects:

• “Common Control Object Things,” page 5-5

• “Common Control Object Properties,” page 5-8

• “Event-Type Objects,” page 5-11

Note If performing a BACnet integration with a JACE-4, you can directly expose Ndio

objects as BACnet objects (BACnet server operation). They appear as the equivalentstandard objects as shown in Table 10-2 above. See the Niagara BACnet Integration

Reference for more information.

General Ndio Object Differences

Each Ndio primitive differs from a standard control object chiefly by the additional

ioIndex property, as previously shown in Figures 10-4 and 10-5. In addition, a few

other properties may vary, as noted below.

statusFlags An Ndio object has a “fault” status whenever its ioIndex property is the default 0(unconfigured), such as when initially copied from the Local Library. After

configuration, fault status can occur if the object has been assigned min and

maxPresentValue limits, and the scaled statusOutput is outside such a limit.

Fault status also occurs globally for Ndio objects if the parent NdioProcessor has

been disabled ( procEnable property on the General, Config tab set to False).

Manual Override (JACE-IO-32 Only)

As previously explained, the JACE-IO-32 expansion module features onboard

override-switches that allow individual AOs and DOs to be removed from Niagara

control. During such periods, corresponding Ndio objects have statusFlags value of

“overridden.”

statusInput Ndio UI objects differ from standard control objects because the statusInput (sIn) is

absent —the onboard physical input (JACE I/O processor) supplies the raw data.

BinaryInput NdioBinaryInput

BinaryOutput NdioBinaryOutput

1. The HighSpeedCounterInput is the only Ndio object without alarming (Event-type) properties.

Table 10-2 Standard control objects most like the various Ndio objects. (continued)

Standard Niagara

Control Object

Ndio Object Counterparts






NdioContainer

10–10

NdioContainer Quick reference for all properties: Table A-56

abbrev: (none)

A NdioContainer object is the parent object

for all Ndio objects in the station. Immediatechild objects are one or more NdioProcessor .

Only one NdioContainer object is supported.

Apart from a few debug-related properties, it

functions mostly as a simple container.

The example Workspace here shows a

JACE-403, which has a single I/O processor

(supports only a single NdioProcessor).

Resource Count 30 to 53, plus the sum of all child object resource counts.

Commands(none).

PropertiesTable 10-3 lists important properties for the NdioContainer object.

NdioContainer Notes

When adding a NdioContainer object, you must place it in the station’s root. You can

then copy and paste an NdioProcessor object into its Workspace.

If desired, you can enable debug (Engineering tab) to observe Ndio messages when

setting ioIndex properties in Ndio objects. To improve station performance, it is

recommended that you leave debug disabled unless troubleshooting Ndio issues.

Inputs


Outputs

(none) (none)

Example Workspace for NdioContainer

Table 10-3 NdioContainer object, important properties.


E n g

i n e e

r i n g debug Read/Write: Specifies if Ndio-related debug

messages appear in any Standard Outputwindow opened for the station.

False, True False

verbose Read/Write: Specifies if debug messageswritten to Standard Output are verbose.

False, True False






NdioProcessor

10–11

NdioProcessor Quick reference for all properties: Table A-59

abbrev: (none)

The NdioProcessor object is the container for

Ndio primitives (Ndio objects) for a specificI/O processor on either a JACE controller or

JACE I/O expansion board.

For a JACE-401 or 403, (with only one I/O

processor), it is set to “onboard_proc_A”.

Note this is equivalent to the previous

“first_onboard_processor” in Niagara 2.3.

Note: The object’s config property

procNum must be set to the proper

enumerated value, which varies by

platform. See Table 10-1 on page 10-4.

Otherwise, if left at default (undefined) ora different setting, I/O communications

will stop, the NdioProcessor is marked

“down,” and all child Ndio objects will

have a “fault” (orange) status.

Child Ndio objects can be placed directly in

the NdioProcessor’s Workspace or put in

other subordinate containers.

Device status (ping) is included for any

NdioProcessor, which by default generates an

alarm in a “I/O processor fault” scenario.

Resource Count 53 to 84, plus the sum of all child object resource counts.

Commands(none).

PropertiesTable 10-4 lists important properties for the NdioProcessor object.

Inputs


Outputs

(none) (none)

Example Workspace for NdioProcessor

Table 10-4 NdioProcessor object, important properties.


G e n e r a

l , S t a t u s

objectType Read Only: The Ndio object type. NdioProcessor Always NdioProcessor

statusFlags Read Only: Current Niagara state of theJACE I/O processor, as one of these:

• ok—Communications to I/O processor OK.

• fault—Communications to I/O processorcannot be established (and the devicestatus mechanism has been disabled).

• down—The Device status mechanismcannot detect the I/O processor (or thestation is opened offline).

(appears inbraces )

ok,down

seeNotes

The status for a newNdioProcessor object(copied from LocalLibrary) is “down” untilthe procNum propertyis correctly set.






NdioProcessor

10–12

NdioProcessor NotesThe NdioProcessor functions mainly as a container for Ndio (primitive) objects such

as Ndio UI objects, NdioBinaryOutput, and Ndio0to10VOutput objects.

G e n e r a

l , C o n

f i g .

procEnable Read/Write: Enables or disables stationcommunications to the I/O processor.Typically left at the default True (enabled).

While False, disables all related I/O. TheNdioProcessor is marked down and childobjects have a fault status

False, True True If DeviceStatus isenabled (default),False also generates a

“Device Down”change_of_statealarm.

procNum Read/Write: Specifies the I/O processorrepresented by this object.

A JACE-401 or 403 has one valid selection:onboard_proc_A

(previously: first_onboard_processor)

Currently, other selections are:slot_1_proc_A for JACE-IO-20 or “firsthalf” of I/O on a JACE-IO-32.

slot_1_proc_B for “second half” of I/O ona JACE-IO-32.

See Descrip. undefined After copying objectfrom Local Library, setthis to a valid value.

D e v

i c e

S t a t u s ,

C o n

f i g

deviceStatusPingDelay

Read/Write: Specifies the delay period, inmilliseconds, between device status “pings”to the JACE I/O processor.

500 to n 1000 Typically left at default.

deviceStatusDisplayDots

Read/Write: Specifies whether a “|”character is posted in Standard Outputwindow for each device status ping.

Characters appear when any Ndio-relatedmessage is posted to Standard Output.

False, True False Typical ly left at default.

deviceStatusDisabled

Read/Write: Specifies whether the devicestatus (ping) mechanism is disabled.Default is False (device status enabled).

False, True False Typical ly left at default.

D e v

i c e

S t a t u s ,

A l a r m

S

e t u p notificationClass Read/Write: The destination notification

class for “change_of_state” alarms triggered

by I/O processor communications events.

Example events are “Device down” or“Device up.”

Note: Device status must be enabled(deviceStatusDisabled=False) for I/Oprocessor events to be sent to thisnotification class.

0 to 8388607 0

Table 10-4 NdioProcessor object, important properties. (continued)







Ndio0to10VInput

10–13

Ndio0to10VInputQuick reference for all properties: Table A-52

abbrev: 0to10VIn

The Ndio0to10VInput object configures a

JACE universal input (UI) to read a Vdcsignal within a 0–10 V range and produce a

scaled output. Like the NdioResistiveInput

and NdioThermistorType3Input objects, this

object is similar to a standard AnalogInput

(AI) object, including all alarm capabilities.

The output value follows the object’s

configurable voltage-to-value lookup table.

This table can contain up to 20 different

points, or 19 segments. Values are linearly

interpolated between points. The default table

is 2 points (linear response), spanning the full

0–10 V input-range of the JACE’s UI. An

offset property allows sensor-to-system

calibration.

Besides reading a 0–10 Vdc sensor, this

object is also used for a 4–20 mA sensor,

where an external 499 Ω resistor (supplied

with JACE hardware) is wired across the UI.

This object can be exposed directly as a

BACnet Analog_Input object1.

Parent Dependencies: NdioProcessor.


Trigger Properties This object has the standard input property, executeTrigger , (typically not used) and

also two trigger-type outputs:





Commands

A JDE user with “Command, Admin” rights has this available menu bar command:• Commands > resetAckedTransitions —Sets all three flags in the



1. For direct exposure as a BACnet object, the JACE-4 requires both the BACnetService and the BACxNdioService.

Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInhibit

eventTrigger

covTrigger

statusOutput

Input / Output Properties for Ndio0to10VInput Object(only input and output types, see Table 10-5 for all properties)






http://-/?-

http://-/?-






Ndio0to10VInput

10–14

PropertiesTable 10-5 Ndio0to10VInput object properties.


S t a t u s

objectType,



on these properties common to all controland Ndio objects.

— — default description is

Ndio 0 to 10 V Input

eventState,reliability,outOfService,ackedTransitions,toOffnormal,toFault,toNormalpresentValue

See Table 5-4 on page 5-12 for informationon these properties common to allevent-type objects.

— — presentValue can bewritten to directlywhenever the objectis set tooutOfService.

syncFlag Read Only: Shows whether the objectsuccessfully updated the configuration ofthe JACE’s dedicated I/O processor.

False, True False False until ioIndex value is assigned tonon-zero value.

C o n

f i g


normal,input

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet Analog_Input object to otherBACnet devices. See “foreignAddress,” page 5-9, for more information.

0 to 4194302

or -1(not exposed)

-1 If set, must be aunique numberamong all other AIobjects in station.




Other,no_units


covIncrement Read-Write: The minimum required inputchange (since the last output change)before outputs and presentValue update.Affects the outputs statusOutput andcovTrigger (fires at change of value).

valid float 0.0

(no

minimum)

covIncrement valueis expressed insame units asscaled output value(not in voltage).

ioIndex Read-Write: I/O processor-to-terminalnumber for the UI configured by this object.

See Table 10-1 on page 10-4 for moredetails by hardware platform.

0(unconfigured)

1—6 (401, 403)1—8 (IO-XX)

0 Must be uniquenumber among allNdio UI objects forthe I/O processor.

linearization

Points

Voltage Value

Read-Write: The physical input signal(voltage) to output (value) response curve.

A linear response can be achieved with onlytwo (2) points, the default. Up to 20 pointscan be specified. Voltage rules are:

• Voltage value range is 0.0 to 10.0.

• Voltage must increase in each new point(must be greater than preceding point).

If a 4-to-20mA sensor, a linear (2 point)linearization is typically used, where:Voltage is 2.0 (4mA) and 10.0 (20mA), andValues are as defined by the sensor.

Points, 2 to 20

Voltage, 0.0 to10.0 <float>

Value,<valid float>

Points 2

Volts Value0.0 0.0

10.0 10.0

Output values arelinearly interpolatedbetween points.

There is no“extrapolation” ofoutput values whenthe input signal isoutside the definedVoltage range.

offset Read-Write: Value added to the internallycalculated value before it passes to theobject’s statusOutput. Allows for wiring orsensor-to-system compensation.

valid float 0.0 Can be positive ornegative, asneeded.

http://-/?-

http://-/?-






Ndio0to10VInput

10–15

0to10VInput NotesThe 0to10VInput object is used for either a 0–10 Vdc or 4–20 mA sensor.

A l a r m

S e

t u p

timeDelay,notificationClass,eventEnable,

notifyType,eventTriggerEnable,alarmText



inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked.Refer to “AI Alarm Inhibit,” page 5-19, formore information.


Hr:Min:Sec


A minimum of 1second (00:00:01) isrecommendedwhenever thestatusInput is linked.

minPresentValue Read-Write: Valid processing low range forthe received input value. Below this value,the object and its output have a fault status.


maxPresentValue Read-Write: Valid processinghigh range forthe received input value. Above this value,the object and its output have a fault status.


highLimit Read-Write: Value above which the object isevaluated in high-limit alarm. Above thisvalue (if not in fault), the object and outputhave inAlarm status.

valid float 0.0 The limitEnable flag(for high-limit) mustalso be set.

lowLimit Read-Write: Value below which the object isconsidered in low-limit alarm. Below thisvalue (if not in fault), the object and outputhave inAlarm status.

valid float 0.0 The limitEnable flag(for low-limit) mustalso be set.

deadband Read-Write: Differential value applied tohigh and low limits before return-to-normal.Deadband is subtracted from highLimit andadded to lowLimit.


limitEnable Read-Write: Flags that enable low-limit andhigh-limit alarms, as needed. (select)low-limit,high-limit

(none)

V i s u a



0 to 6,


2,

no (+) sign


E n g

i n e e r i n g



— —




false : ok




00.0 ok



General,

7 others

General

Table 10-5 Ndio0to10VInput object properties. (continued)







Ndio0to10VOutput

10–16

Ndio0to10VOutputQuick reference for all properties: Table A-53

abbrev: 0to10VOut

Each Ndio0to10VOutput (0to10VOut) object

provides the interface to one analog output(AO) on a JACE expansion I/O controller.

AOs are used for proportional control of

dampers, valves, and other devices.

Apart from a few additional config properties

(including ioIndex number), this object is

otherwise very similar to a standard

AnalogOutput (AO) object. It includes the

same command prioritization scheme and all

alarm and event capabilities.

You can expose an Ndio0to10VOutput object

directly as a BACnet Analog_Output object1.



Trigger Properties The 0to10VOut object has the standard input property, executeTrigger , (typically not

used) and also two trigger-type outputs:




CommandsA right-click command menu provides these commands (note that default command

names are shown, these are modifiable using the object’s commandTags property):

• Set —To set an output value at the Manual level (8).


• Auto —To clear an output value set at the Manual level (8).Requires “Command, Std” privileges.

• EmergencySet —To set an output value at the Emergency level (1).



Inputs


Outputs

priorityArray

statusInput

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInhibit

priorityArray

statusInput

eventTrigger

covTrigger

statusOutput

prioritizedOutut


Input / Output Property Reference for 0to10VOut Object(only input and output types, see Table 10-6 for all properties)



pIn priorityArray FloatPriorityArrayType





pOut priori tizedOutput FloatPriorityType

sFbOut statusFeedbackOutput FloatStatusType

http://-/?-

http://-/?-






Ndio0to10VOutput

10–17

• EmergencyAuto —To clear an output value set at the Emergency level (1).


For a JDE user with “Command, Admin” privileges, the following object command

is available from the menu bar:

• Commands > resetAckedTransitions —Sets all three flags in theackedTransitions property (to-offnormal, to-fault, to-normal). Rarely required,

refer to the “JDE Command” section on page 5-11 for more information.

PropertiesTable 10-6 Ndio0to10VOutput (0to10VOut) object properties.


S t a t u s



— —

eventState,reliability,

outOfService,ackedTransitionstoOffnormal,toFault,toNormal,presentValue

See Table 5-4 on page 5-12 for informationon these properties common to all

event-type control objects.


P r i o r i t i e s


Read Only: Shows values present on eachof the 16 priority level slots for thepriorityArray (pIn) input.

<valid float> orauto,

levels 1 to 16

auto

1 to 16

relinquishDefault Read-Write: Defines the output value whenall 16 priority level slots have an “auto”.

valid float 0.0

C o n

f i g


normal,output

foreignAddress Read-Write: BACnet usage only. Set to apositive integer for this object to appear as aBACnet Analog_Output object to otherBACnet devices. See “foreignAddress,” page 5-9, for more information.

0 to 4194302

or -1(not exposed)

-1 Must be a uniqueamong allBACnet-exposedAnalogOutput objectsin station.


units Read-Only: Fixed at “volts” (Electrical). Electrical,volts

Electrical,volts

covIncrement Read-Write: The minimum requiredchange-of-value at the priorityArray input (since the last output change) before theoutputs and presentValue update. Affectsthese outputs:


• statusOutput


valid float 0.0

(nominimum)

A small value, say0.1, may be desiredto prevent unduemovement ofcontrolled devicefrom inputfluctuations.

ioIndex Read-Write: I/O processor-to-terminalnumber for the AO configured by this object.

JACE-IO-32 has two I/O processors, eachwith 4 AOs. (Physical AOs 5, 6, 7, 8 also useioIndex 1, 2, 3, and 4 respectively).

0(unconfigured)

1, 2, 3, 4

0 Must be uniquenumber among allAnalog Outputs forthat I/O processor.

See Table 10-1.






Ndio0to10VOutput

10–18

C o n

f i g ,

c o n

t .

offset Read-Write: Value that is internally added tothe currently active value at the priorityArrayinput, before being compared to the

linearization table (Input side).

valid float 0.0 Can be positive ornegative, as needed.

linearization

Input

Volts

Read-Write: Input (priorityArray + offset) tophysical output (volts) response curve.

A linear response can be achieved with onlytwo (2) points. The default (11 points) alsoprovides a linear response. Up to 20 pointscan be specified.

Volts rules are:

• Volts value range is from 0.0 to 10.0.

• Volts must increase in each new point(must be greater than preceding point).

An example linear setup for 0—100% inputfor full range to a 2—10V actuator:

Input Volts0.0 2.0

100.0 10.0

Points, 2 to 20

Input,<valid float>

Volts,0.0 to 10.0

Points 11

Input, Volts

0.0 0.01.0 1.02.0 2.03.0 3.04.0 4.05.0 5.06.0 6.07.0 7.08.0 8.09.0 9.0

10.0 10.0


There is no“extrapolation” ofvolts values when theinput signal is outsidethe defined Inputrange.

A l a r m

S e

t u p




inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked. The

purpose is to prevent nuisance alarms onequipment startup and shutdown.

Note: Alarming is based solely on the valueat the priorityArray input.

The inhibit timer is triggered by a transitionat the statusInhibit input.


• When statusInhibit becomes false, alarmprocessing remains inhibited.


Hr:Min:Sec




minPresentValue Read-Write: Valid processing low range.Below this value, the object and its

statusOutput have a fault status (orange).The minimum value that can be set for theobject using its right-click command menu.

Less than maxsetting (below)

See Notes Defaults are MIN andMAX_VALUE.

A non-default value isrequired for both ofthese properties inorder to provide aslider adjustmentfrom the JDE.

maxPresentValue Read-Write: Valid processing high range.Above this value, the object and itsstatusOutput have a fault status (orange).

The maximum value that can be set for theobject using its right-click command menu.

Greater thanmin setting

(above).

See Notes

Table 10-6 Ndio0to10VOutput (0to10VOut) object properties. (continued)







Ndio0to10VOutput

10–19

Ndio0to10VOutput Notes

The 0to10VOutput object configures an AO on a JACE-IO-32 or JACE-IO-20. In the

case of a JACE-IO-32, each AO can be physically overridden at the I/O expansion

module. For more details, see to “Output Override Switches,” page 10-7.

A l a r m

S e

t u p

, c o n

t .highLimit Read-Write: Value above which the object is

considered in high-limit alarm.valid float 0.0

lowLimit Read-Write: Value below which the object is

considered in low-limit alarm.

valid float 0.0

deadband Read-Write: Differential value applied tooff-normal limits before return-to-normal.

valid float 0.0

limitEnable Read-Write: Flags that enable low-limit andhigh-limit alarms.

valid float 0.0

V i s u a

l


decimalFormat Read-Write: Sets decimal position from 0 to6 places, and optionally force (+) sign forpositive values.

0 to 6,


2,

no (+) sign

commandTags Read-Write: Defines the command labelsthat show on the r ight-click command menufor the object. Default tags are:

• Set (manualSet level)• Auto (manualAuto level)

• Emergency Set (emergencySet level)

• Emergency Auto (emergencyAuto level)

Any desiredtext string,including

spaces andnumerals.

Seedescrip.

If a tag is blank (nocharacters), thecommand is not

available on thecommand menu.

E n g

i n e e r i n g



— —

statusInhibit(input: sInh)



false : ok



Note: This input value is not used in the0to10VOut object’s alarm processing .


00.0 ok If statusInput is notlinked, reflects valueat priorityArray.




00.0 ok



<float value> @<pri. level>

0.00 @ 16


(output: sFbOut)Read Only: Shows the current value andstatus at the statusFeedbackOutput.


00.0 ok Reflects statusInputvalue (if linked),otherwise shows thestatusOutput value.




General,

7 others

General

Table 10-6 Ndio0to10VOutput (0to10VOut) object properties. (continued)







NdioBinaryInput

10–20

NdioBinaryInputQuick reference for all properties: Table A-54

abbrev: ndioBI

The NdioBinaryInput (ndioBI) object

configures a JACE universal input (UI) toread the binary status of dry contacts,

typically used for equipment-status

monitoring. Apart from an “ioIndex”

property for its physical terminal address, it is

nearly identical to standard BinaryInput (BI)

object, including all alarm and event

capabilities.

Note: COS (change-of-state) frequency

must be low (1 Hz or less) for this object.

To configure a JACE UI for high-speed

count (and analog rate) of dry contacts, use

a NdioHighSpeedCounterInput object.

An NdioBinaryInput object can be exposed

directly as a BACnet Binary_Input object1.

Parent Dependencies: NdioProcessor



also 2 other trigger-type inputs:








• changeOfStateTrigger —Fires upon each change-of-state at the statusOutput.• changeOfStateAlertTrigger —Fires each time a change-of-state alert is issued




Inputs


Outputs

(none) statusOutput

Inputs


Outputs

executeTrigger

statusInhibit




eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

statusOutput


Input / Output Property Reference for NdioBinaryInput Object(only input and output types, see Table 10-7 for all properties)


















NdioBinaryInput

10–21


(“activeTimeAlertLimit” value has been reached), or when a “multiple” of this

value occurs (if “periodicAlerts’ is set to True).

As needed, these trigger-type inputs and outputs can be linked to other objects.

Commands For a JDE user with “Command, Admin” privileges, the following object commands






value to zero (0), clearing any COS count.







PropertiesTable 10-7 NdioBinaryInput (NdioBI) object properties.


S t a t u s


See Table 5-3 on page 5-8 for informationon these properties common to all controland Ndio objects.

— — default descriptionis Ndio UniversalBinary Input

eventState,

reliability,outOfService,ackedTransitions,toOffnormal,toFault,toNormalpresentValue


on these properties common to allevent-type objects.

— — presentValue can

be written todirectly wheneverthe object is set tooutOfService.



null


integer value 0



null

elapsedActiveTime Read Only: Shows accumulated runtime(elapsed active time) formatted inHr:Min:Sec.


00:00:00



null

syncFlag Read-Write: Shows whether the objectsuccessfully updated the configuration ofthe JACE’s dedicated I/O processor.

False, True False False until ioIndex value is assignedto non-zero value.

http://-/?-

http://-/?-






NdioBinaryInput

10–22

C o n

f i g


normal,input

foreignAddress Read-Write: BACnet usage only. Set to a

positive integer for this object to appear as aBACnet Binary_Input object to otherBACnet devices. See “foreignAddress,” page 5-9, for more information.

0 to 4194302

or -1(not exposed)

-1 Must be a unique

number among allBI objects instation.




0 (unconfigured)

1—6 (401, 403)1—8 (IO-XX)


polarity Read-Write: Determines whether the outputvalue directly reflects the binary input state(normal) or “reverses” the binary state.

Typically, normally open (N.O.) equipmentcontacts are monitored using normal logic.

normal, reverse normal If normal, UI inputclosure=Active,open=Inactive.

If reverse, UI inputclosure=Inactive,open=Active.

A l a r m

S e

t u p





The purpose is to prevent nuisance alarms

on equipment startup and shutdown.The inhibitTime is triggered by a transition atthe statusInhibit input.


• When statusInhibit becomes false, alarmprocessing is delayed for three times theinhibit time.


Hr:Min:Sec


A minimum valueof 1 second(00:00:01) isrecommended

whenever thestatusInhibit inputis linked.

Alarm processingcompares thestatusInput valueto the definedalarmValue.


Positive integer 0


Value up to99999:59:59(Hr:Min:Sec)

00:00:00



0 to 8388607 0


False, True False

Table 10-7 NdioBinaryInput (NdioBI) object properties. (continued)







NdioBinaryInput

10–23

NdioBinaryInput NotesThe NdioBI object is used to read the binary (digital) state of dry contacts on a JACE

UI (universal input). Typical use is for equipment status monitoring.

Please to the following BinaryInput (BI) object topics for related information on

alarming:

• “BI Alarm Detection,” page 5-37.

• “BI Alarm Notification,” page 5-37.

• “BI Alarm Inhibit,” page 5-38.

• “BI Alarm Delay,” page 5-38.

A l a r m

S e

t u p

, c o n

t .alertText Read-Write: Text descriptor included in

either a COS count alert or runtime alert.




characters.

-(hyphen)


alarmValue Read-Write: Defines the digital state that isevaluated as an alarm.

Active, Inactive Active

alarmValueEnabled Read-Write: Determines if the BI object isconfigured for alarming.

False, True False

V i s u a

l



Read-Write: Defines how states display atthe statusInput, statusOutput, andpresentValue, also how they appear on theobject’s property sheet.


Active,Inactive

State descriptorscan display at alinked GxTextobject.

E n g

i n e e r i n g




page 5-8.

— —

statusInhibit

(input sInh)



false : ok


(output sCnt)

Read Only: Shows the current COS count.Available as a IntegerStatusType output.


0 : ok


(output sElpT)

Read Only: Shows the current runtime(elapsed active time), totaled in seconds.Available as a IntegerStatusType output.


0 : ok

statusOutput

(output sOut)





General,

7 others

General

Table 10-7 NdioBinaryInput (NdioBI) object properties. (continued)







NdioBinaryOutput

10–24

NdioBinaryOutputQuick reference for all properties: Table A-55

abbrev: NdioBO

Each NdioBinaryOutput (NdioBO) object

provides the interface to an onboard digitaloutput (DO) on a JACE-4 controller or I/O

expansion board. Depending on the hardware

platform, the DO may be a form-C SPDT

relay or a triac output. In either case, the DO

(and this object) is used for direct On/Off

control of equipment.

Apart from an “ioIndex” property for its

physical output address, this object is

otherwise identical to a standard

BinaryOutput (BO) object. It includes the

same command prioritization scheme and all

alarm and event capabilities.

You can expose an NdioBinaryOutput object

directly as a BACnet Binary_Output object1.




any link) to a NdioBO object, commands at



cleared. The priorityArray input is nowimmediately rescanned; any input


output . This is an improvement over

previous releases, where a link change

might produce an output cycle until a linked

Schedule output updated.


also 2 other trigger-type inputs:

• resetChangeOfStateCountTrigger —Any received trigger pulse clears theobject’s current count of COS (changes of states), resetting it to zero (0).




1. For direct exposure as a BACnet object, the JACE-4 requires both the bacnet module and the bacnetx ndio module.

Inputs


Outputs

priorityArray

statusInput

statusOutput

prioritizedOutput

Inputs


Outputs

executeTrigger

statusInhibit



priorityArray

statusInput


eventTrigger

statusCOSCount*

statusElpActTime*

COSTrigger*

COSAlertTrigger*

ElpActAlertTrigger*

presentValue

statusOutput

prioritizedOutput



Input / Output Property Reference for NdioBinaryOutput Object(only input and output types, see Table 10-8 for all properties)






pIn priorityArray BooleanPriorityArrayType


output eventTr eventTrigger TriggerTypesCnt statusChangeOfStateCount IntegerStatusType








sFbOut statusFeedbackOutput BooleanStatusType

http://-/?-

http://-/?-






NdioBinaryOutput

10–25








(“activeTimeAlertLimit” value has been reached, or a “multiple” of this value

if “periodicAlerts’ is set to True).

CommandsThe NdioBO object provides a right-click command menu with these commands

(default command names shown—modifiable using the commandTags property):

• Active —To set an active output at the Manual level (8).


• Inactive —To set an inactive value at the Manual level (8).

Requires “Command, Std” privileges.• Auto —To clear any active or inactive output at the Manual level (8).

• EmergencyActive —To set an active output at the Emergency level (1).


• EmergencyInactive —To set an inactive output at the Emergency level (1).


• EmergencyAuto —To clear any active or inactive output at the Emergency

level (1). Requires “Command, Emer” privileges.







value to zero (0), clearing the COS count.


00:00:00 (Hr:Min:Sec), clearing the accumulated runtime.




property value (Alarm Setup property).PropertiesTable 10-8 NdioBinaryOutput (NdioBO) object properties.





— —






NdioBinaryOutput

10–26

S t a t u s ,

c o n

t .


ackedTransitionstoOffnormal,toFault,toNormal,presentValue


<cmd state> orauto,

levels 1 to 16

auto

1 to 16




null Be aware that alocally overriddenDO (JACE-IO-32)does not stop his-torical propertiessuch as elapsedAc-tiveTime andchangeOfState-Count from incre-

menting due tochanges at thepriorityArray input.


integer value 0



null

elapsedActiveTime Read Only: Shows accumulated runtime

(elapsed active time) in Hr:Min:Sec.

Time period up

to 9999:99:99

00:00:00



null

P r i o r i t i e s


Read Only: Shows commands present oneach of the 16 priority level slots for thepriorityArray (pIn) input.

Active, Inactive,or auto,

levels 1 to 16

auto

1 to 16

relinquishDefault Read-Write: Defines the output state whenall 16 priority level slots have an “auto”.

Active, Inactive Inactive


False, True False

C o n

f i g

executeParameters Read-Write: The object’s execution frequency and order. For

more details, see “execution Parameters,” page 5-9.

normal,

outputforeignAddress Read-Write: BACnet usage only. Set to a

positive integer for this object to appear as a

BACnet Binary_Output object. See

“foreignAddress,” page 5-9, for more details.

0 to 4194302

or -1(not exposed)

-1 Must be a uniquenumber among allBO objects instation.


ioIndex Read-Write: I/O processor-to-terminalnumber for DO configured by this object.See Table 10-1 on page 10-4 for moredetails by hardware platform.

0 (unconfigured)

1—4 (401, 403,IO-32)

1—8 (IO-20)

0 Must be uniquenumber among allDO outputs for thatI/O processor.

polarity Read-Write: Determines if the sameboolean state at the statusInput is reflectedat the statusOutput (normal), or if the output

remains opposite from the input (reverse).


minimumOnTime Read-Write: Upon a command frominactive to active, results in an activecommand stored at the Minimum On Offpriority level (6) for this time (Hr:Min:Sec).


00:00:00

minimumOffTime Read-Write: Upon a command from activeto inactive, results in an inactive commandstored at the Minimum On Off priority level(6) for this duration (Hr:Min:Sec).


00:00:00

Table 10-8 NdioBinaryOutput (NdioBO) object properties. (continued)







NdioBinaryOutput

10–27

C o n

f i g ,

c o n

t .

restartDisable Read-Write: Determines whether the outputis automatically restarted following a stationrestart (reboot) or power failure. If set to

True, an inactive at manual level (8) isissued following such an occurrence.

False, True False

interstartDelayTime Read-Write: Defines the time period theoutput is held inactive following an activecommand. Used to prevent multiplesimultaneous starts. Applies to commandsat all priority levels except Emergency (1).


00:00:00 Applied alsofollowing a stationrestart.

A

l a r m

S e

t u p






• When statusInhibit goes false-to-true,alarm processing is delayed for this time.

• When statusInhibit goes true-to-false,alarm processing is delayed for three



Hr:Min:Sec


A minimum value of1 second(00:00:01) isrecommended ifthe statusInhibitinput is linked.

Alarm processingcompares thestatusInput(feedback) value tothe priorityArray(command) value.

changeOfStateAlertLimit Read-Write: Number of COS occurrences

that generate a changeOfStateCount alert.

Positive integer 0



(Hr:Min:Sec)

00:00:00

alertNotificationClass Read-Write: The assigned notification classnumber, used in routing alerts. ANotificationClass object using the samenumber should exist in theNotificationService object’s container.

0 to 8388607 0

periodicAlerts Read-Write: Determines if both COS countalerts and runtime alerts are generatedeach time a respective limit occurs.

False, True False


If left at the default hyphen (-), the parentcontainer object’s alertText is used.


characters.

-(hyphen) 255 charactersmaximum.

V i s u a

l



Read-Write: Defines the displayed states atthe statusInput, statusOutput, andpresentValue, and also how they appear onthe object’s property sheet.


Active,Inactive









NdioBinaryOutput

10–28

NdioBinaryOutput NotesThe Ndio object configures an DO on a JACE-4 series controller or JACE-IO-XX

I/O expansion module. Please refer to the following BinaryOutput (BO) object topics

for more details:• “BO Alarm Inhibit,” page 5-50.

• “BO Alarm Delay,” page 5-50.

• “BO Alarm Notification,” page 5-50.

In the case of a JACE-IO-32, each AO can be physically overridden at the I/O

expansion module. For more details, see to “Output Override Switches,” page 10-7.

V i s u a

l , c o n t .

commandTags Read-Write: Defines the labels used to l istcommands that appear on the right-clickcommand menu. Default text values for

commandTags are:• Active (manualActive)

• Inactive (manualInactive)


• EmergencyActive (emergencyActive)

• EmergencyInactive (emergencyInactive)

• EmergencyAuto (emergencyAuto)


spaces and

numerals.

Seedescrip.

If a tag is blank (nocharacters), thecommand is not

available on thecommand menu.

E n g

i n e e r i n g



— —

statusInhibit

(input sInh)

Read Only: Shows the current booleanstate and status of the statusInhibit input.


false : ok


(output sCnt)

Read Only: Shows the current value andstatus of the COS count.



0 : ok


(output sElpT)

Read Only: Shows the current runtime(elapsed active time), totaled in seconds.



0 : ok

statusInput

(input sIn)



Inactive :ok

statusOutput

(output sOut)



Inactive :ok

prioritizedOutput

(output pOut)

Read Only: Shows the current state and

priority level of the prioritizedOutput.

Inactive, Active

@ <pri. level>

Inactive :

@ def


(output sFbOut)

Read Only: Shows the current state andstatus of the feedback value being suppliedon the statusInput.


Inactive :ok



General,

7 others

General








NdioHighSpeedCounterInput

10–29

NdioHighSpeedCounterInputQuick reference for all properties: Table A-57

abbrev: NdioCounterIn

The NdioHighSpeedCounterInput object

configures a JACE universal input (UI) tomonitor dry contacts for pulses, where a total

count is maintained, plus a calculated rate.

Contact pulses are detected on the “falling

edge” (closed-to-open). When indexed by

this object, a JACE hardware UI input

supports a pulse input frequency up to 20 Hz.

Typical use is for a metering application, such

as an electric demand meter or a fuel meter.

Each recorded input change represents some

quantity of energy or material

(kilowatt-hours, fuel gallon, etc.). Config

properties provide scaling for both total and

rate values, as well as display units and other

rate parameters. Total and rate values are

available as linkable outputs.

The JACE’s I/O processor accumulates the

total independently of the main JACE

processor. In this way, the total is preserved

over a soft restart (reboot) of a JACE-4.





Trigger Properties This object has the standard input property, executeTrigger , (typically not used).

CommandsA user with “Command, Std” rights has this available right-click command:

• resetCounter —Resets the accumulated total at the totalOutput and

countOutput outputs to zero (0.0 and 0, respectively).

Note Be aware that only Std command rights are necessary for this command,especially when assigning securityGroups properties and user privileges.


Inputs


Outputs

statusInput totalOutput

Inputs


Outputs

executeTrigger

rawOutput

countOutput

totalOutput

rateOutput

Input / Output Properties for NdioHighSpeedCounter Object(only input and output types, see Table 10-9 for all properties)


output raw rawOutput String

count countOutput String

total totalOutput FloatStatusType

rate rateOutput FloatStatusType







10–30

PropertiesTable 10-9 NdioHighSpeedCounterInput object properties.


S t a t u s

objectType,




— —

reliability,outOfService

See Table 5-4 on page 5-12 for informationon these two properties.

— —

presentValue Read Only: Shows the current accumulatedtotal value (as on the totalOutput).

presentValue can be written to directlywhenever the object is set to outOfService.

valid float(positive)

0.0

syncFlag Read-Write: Shows whether the objectsuccessfully updated the configuration ofthe JACE’s dedicated I/O processor.

False, True False Remains False untilthe ioIndex value isassigned.

C o n

f i g


normal,input


0 to 4194302

or -1(not exposed)

-1


units Read-Write: Selection of engineering unitsfor display of the total value. Choose from alogical grouping, then a specific unit.

For example, in a typical electric meterapplication, units is set to:

Energy,kilowatt_hours


Other,no_units

units can bedisplayed by alinked GxTextobject.




0(unconfigured)

1—6 (401, 403)1—8 (IO-XX)


countScale Read-Write: The scale (multiplier) for thecount total, where:

totalOutput = count x countScale

valid float 1.0

rateHistory Read-Write: Number of rate intervalsamples stored and used for calculating therateOutput. The higher the number, themore normalized the rate calculation will be.

1 to 100,integer

1 See Figure 10-7 onpage 10-32 for moredetails.

rateInterval Read-Write: Time period (in seconds)

between samples from which each newrateOutput calculation is performed. Thehigher the number, the more normalized therate calculation will be.

1 to n,

integer

10 See Figure 10-7 on

page 10-32 for moredetails.

rateScale Read-Write: The scale (multiplier) for therate value, where:

rateValue = pulses/sec x rateScale

<valid float>(positive)

1.0







10–31

HighSpeedCounterInput NotesThe HighSpeedCounterInput object is used for pulse-metering applications. Outputs

for both a scaled count value and rate value are available.

Limits for the “raw” (physical) count are 232 unsigned (4,294,967,296), above whicha count “rollover” (to zero) would occur. Limits for the scaled count is the Java

“long” implementation of 263 (9,223,372,036,854,775,808) above which a “+Inf”

would appear at the countValue output. In practical usage, neither count limit is

approached.

Figures 10-7 and 10-8 illustrate example usage of rate properties rateInterval and

rateHistory to achieve “normalized” rate values.

C o n

f i g ,

c o n

t .

rateUnits Read-Write: Selection of engineering unitsfor display of the rate value. Choose from alogical grouping, then a specific unit.

For example, in a typical electric meterapplication, rateUnits is set to:

Power,kilowatts


Other,no_units

rateUnits can bedisplayed by alinked GxText

object.

V i s u a



0 to 6,


2,

no (+) sign


E n g

i n e e r i n g



— —

rawOutput(output raw) Read Only: The number of counted pulsesreported by the JACE I/O processor. 0 to n(positiveinteger)

0 Not cleared by theresetCountcommand.

countOutput(output count)

Read Only: The number of counted pulsessince the last resetCount command. Equalsthe rawOutput + bootAdjust.

A resetCount command zeroes this value.

0 to n

(positiveinteger)

0 Stored across astation restart(JACE-4 reboot).

bootAdjust Read Only: A calculated value used toaccount for differences to due to stationrestart, hard reset, counter rollover, etc.

0 to n 0

totalOutput(output total)

Read Only: Shows the current float valueand status of the totalOutput, which equalscount x countScale.


00.0 ok The scaled countvalue.

rateOutput(output rate)

Read Only: Shows the current float valueand status of the rateOutput, which equalspulses/sec. x rateScale.


00.0 ok The scaled ratevalue.

S e c u r i t y

securityGroups Read-Write: Shows the security groups towhich the object is assigned. For moredetails, see “securityGroups,” page 5-10.

General,

7 others

General This object’sresetCountcommand requiresonly Std commandprivleges.

Table 10-9 NdioHighSpeedCounterInput object properties. (continued)








10–32

Figure 10-7 Sample graph of raw rate versus normalized rate.

This graph shows the“smoothing” effect of a ratevalue when “normalized.”

In both cases, therateInterval = 10 (seconds).

When rateHistory = 1,(default), the rate reflectsan instantaneous rate ateach rate interval, shownby the “Raw rate.”

When rateHistory = 5, therate becomes “normalized,”meaning the rateOutputlags, but is noticeablysmoother. See Figure 10-8 for the data used in thisgraph.

Raw rate Normalized rate

4.000

3.500

3.000

2.500

2.000

1.500

1.000

R a t e

50 100 150 200

R a t e

Time seconds

Figure 10-8 Example of time, pulse count and rate - raw and normalized.

Actual Time

sec.

Delta Time

sec.

Raw Count

pulses

Delta Count

pulses

Instant. Rate

pulse/sec.

Normal. Rate

pulse/sec.

This figure shows the datafor the Figure 10-7 graph.

The bolded rectanglesrepresent a sliding“window” that marchesdown the rows, showinghow the normalized rate iscalculated.

Note that for simplicity, thisexample uses defaultrateScale (1), where therate is the same as thepulses per second. Moretypically, the rateScaleproperty is set to anothervalue.

10 100

20 10 120 20 2.000

30 10 140 20 2.000

40 10 165 25 2.500

50 10 190 25 2.500 2.250

60 10 220 30 3.000 2.500

70 10 250 30 3.000 2.750

80 10 285 35 3.500 3.000

90 10 320 35 3.500 3.250

100 10 350 30 3.000 3.250

110 10 380 30 3.000 3.250

120 10 410 30 3.000 3.125

130 10 435 25 2.500 2.875

140 10 460 25 2.500 2.750150 10 480 20 2.000 2.500

160 10 500 20 2.000 2.250

170 10 520 20 2.000 2.125

180 10 540 20 2.000 2.000

190 10 560 20 2.000 2.000

200 10 580 20 2.000 2.000






NdioResistiveInput

10–33

NdioResistiveInputQuick reference for all properties: Table A-58

abbrev: ResIn

An NdioResistiveInput object configures a

JACE universal input (UI) to read a resistivevalue within a 0–100 K Ω range and produce a

scaled output. Like the Ndio0to10VInput and

NdioThermistorType3Input objects, this object

is similar to a standard AnalogInput (AI)

object, including all alarm capabilities.

The output value follows the object’s

configurable resistance-to-value lookup table.

This table can contain up to 20 different points,

or 19 segments. Values are linearly interpolated

between points. The default table is 11 points

or 10 segments, spanning the full 0–100 K Ω

range of the JACE universal input.








to-normal) that has been specified in the property “eventTriggerEnable.”• covTrigger —Fires upon each change of value at the statusOutput.






Properties


Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInhibit

eventTrigger

covTrigger

statusOutput

Input / Output Properties fo r NdioResistiveInput Object(only input and output types, see Table 10-10 for all properties)






Table 10-10 NdioResistiveInput object properties.





— — default description isNdio Resistive Input

http://-/?-

http://-/?-






NdioResistiveInput

10–34

S t a t u s ,

c o n t .







False, True False False until ioIndex value is assigned tonon-zero value.

C o n

f i g


normal,input


0 to 4194302

or -1(not exposed)





Other,no_units


covIncrement Read-Write: The minimum required inputchange (since the last output change)before outputs and presentValue update.Affects the statusOutput and covTrigger(fires at change of value).

valid float 0.0

(nominimum)

covIncrement valueis expressed insame units asscaled output value(not in resistance).



0(unconfigured)

1—6 (401, 403)1—8 (IO-XX)

0 Must be uniquenumber among all

Ndio UI objects forthe I/O processor.

linearization

Points

Resistance Value

Read-Write: Physical input signal(resistance, ohms) to output (value). Up to20 points can be specified. Default setupprovides 11 points (10 segments):

Resistance Value0.0 0.01000.0 1000.02000.0 2000.04000.0 4000.08000.0 8000.020000.0 20000.030000.0 30000.0

50000.0 50000.065000.0 65000.090000.0 90000.0100000.0 100000.0

Rules for Resistance values are:

• Resistance value range is 0.0 to 100000.

• Resistance must increase in each newpoint (be greater than preceding point).

Values may be float, positive or negative.

Points, 2 to 20

Resistance, 0.0to 100000.0

<float>

Value,<valid float>

11 Points

SeeDescrip. for

defaultResistanceand Values


When resistance atthe UI input isoutside the enteredresistance range(lowest resistanceand highestresistance), theoutput value isclamped at the

corresponding endvalue—in otherwords, there is no“extrapolation” ofoutput values.

Table 10-10 NdioResistiveInput object properties. (continued)


http://-/?-

http://-/?-






NdioResistiveInput

10–35

C o n

f i g ,

c o n

t . offset Read-Write: Value added to the internallycalculated value before it passes to theobject’s statusOutput. Allows for wiring or

sensor-to-system compensation.

valid float 0.0 Can be positive ornegative, asneeded.

A l a r m

S e

t u p




inhibitTime Read-Write: Duration (Hr:Min:Sec) of thealarm inhibit timer, which applies only if theobject’s input statusInhibit is linked.Refer to “AI Alarm Inhibit,” page 5-19, formore information.


Hr:Min:Sec


A minimum of 1second (00:00:01) isrecommendedwhenever thestatusInput is linked.







lowLimit Read-Write: Value below which the object isconsidered in low-limit alarm. Below thisvalue (if not in fault), the object and output

have inAlarm status.

valid float 0.0 The limitEnable flag(for low-limit) mustalso be set.




(select)low-limit,high-limit

(none)

V i s u a



0 to 6,(+) sign’

no (+) sign

2,

no (+) sign


E n g

i n e e r i n g



— —




false : ok




00.0 ok








NdioResistiveInput

10–36

ResistiveInput NotesTypically, you enter values in the linearization table from a sensor’s documentation.

If the sensor has more than 20 data points, enter those within the range of expected

measurement. Use the offset property to compensate for (linear) error that may be

introduced by wiring to the sensor.

Example 10-1 shows possible linearization table entries that could be used for a

10K3A1 type thermistor sensor, used to display degrees Celsius.



General,

7 others

General



Example 10-1 NidoResistiveInput setup for 10K3A1 type thermistor sensor to display degrees Celsius.

10K3A1 thermistor temperature curve(from sensor vendor) NdioResistiveInput object(linearization configuration, where points = 20)

Deg. C Ohms Deg. C Ohms Resistance Value

-50 667828 23 10923 3601 50

-40 335671 24 10450 5325 40

-30 176683 25 10000 6530 35

-20 96974 26 9572 8056 30

-15 72895 27 9165 8777 28

-10 55298 28 8777 9165 27

-5 42314 29 8408 9572 26

0 32650 30 8056 10000 25

1 31030 35 6530 10450 24

2 29500 40 5325 10923 23

3 28054 45 4367 11420 22

4 26688 50 3601 12494 20

5 25396 55 2985 13623 18

6 24173 60 2487 15001 16

7 23016 65 2082 17257 13

8 21921 70 1751 19904 10

9 20885 75 1480 25396 5

10 19904 80 1256 32650 0

11 18974 85 1070 55298 -10

12 18092 90 916.1 96974 -20

13 17257 95 787.0

Note that Resistance entries in the points (linearization table) must be enteredin an increasing manner, as shown here.

Also, the UI input is optimized to provide the best resolution around the 10Kohm range. For any sensor with a range far from 10K ohms (such as a 100-ohmor 1000-ohm type), use of this object will not perform well.

If such a sensor must be used, it is recommended that it be outfitted with atransmitter to produce a Vdc or mA output, and used instead with a UI inputconfigured by a Ndio0to10VInput object.

14 16465 100 678.6

15 15714 105 587.3

16 15001 110 510.1

17 14325 115 444.5

18 13623 120 386.6

19 13053 125 340.8

20 12494 130 300.0

21 11943 140 234.1

22 11420 150 184.8






NdioThermistorType3Input

10–37

NdioThermistorType3InputQuick reference for all properties: Table A-60

abbrev: Type3In

The NdioThermistorType3Input object

configures a JACE universal input to read aType 3 Thermistor temperature sensor. Like the

Ndio0to10VInput and NdioResistiveInput

objects, this object is similar to a standard

AnalogInput (AI) object, including all alarm

capabilities.

A selectable tempUnits property specifies the

displayed output value, either in degrees

Celsius, Fahrenheit, or Kelvin. An offset

property allows sensor-to-system calibration.


BACnet Analog_Input object1

.













Properties


Inputs


Outputs


Inputs


Outputs

executeTrigger

statusInhibit

eventTrigger

covTrigger

statusOutput

Input / Output Properties fo r NdioThermistorType3Input Object(only input and output types, see Table 10-11 for all properties)






Table 10-11 NdioThermistorType3Input object properties.


S t a

t u s objectType,




— — default description is

Ndio ThermistorType 3 Input

http://-/?-

http://-/?-

http://-/?-







10–38

S t a t u s ,

c o n

t .







False, True False Remains False untilthe ioIndex value issuccessfullyassigned.

C o n

f i g


normal,input


0 to 4194302

or -1

(not exposed)



covIncrement Read-Write: The minimum required inputchange (since the last output change)before outputs and presentValue update.Affects the outputs statusOutput andcovTrigger (fires at change of value).

valid float 0.0

(nominimum)

covIncrement valueis expressed insame terms asscaled output value(tempUnits).



0(unconfigured)

1—6 (401, 403)1—8 (IO-XX)


offset Read-Write: Value added to the internallycalculated temperature value before itappears at the object’s statusOutput. Allowsfor sensor-to-system compensation forfactors such as sensor wiring, etc.

valid float 0.0 Can be positive ornegative, asneeded. See Note inTable 10-12 onpage 10-40.

tempUnits Read-Write: Specifies the internalcalculation used on the raw input value toformat it in the correct numeric range.

Also specifies the displayed unit descriptor.For example, a linked GxText object candisplay either the “abbreviated” or “full”versions as follows:

°C degrees_Celsius,°F degrees_Fahrenheit,K degrees_Kelvin

degrees_

celsius,fahrenheit,

kelvin

degrees_celsius

A l a r m

S e

t u p




Table 10-11 NdioThermistorType3Input object properties. (continued)


http://-/?-

http://-/?-







10–39

ThermistorType3Input NotesThe ThermistorType3Input object is used for any Type 3 thermistor temperature

sensor. The offset property allows for calibration/compensation, typically for wiring

resistance.

A l a r m

S e

t u p ,

c o n

t .


Refer to “AI Alarm Inhibit,” page 5-19, formore information.


Hr:Min:Sec



whenever thestatusInput is linked.







lowLimit Read-Write: Value below which the object is

considered in low-limit alarm. Below thisvalue (if not in fault), the object and outputhave inAlarm status.

valid float 0.0 The limitEnable flag

(for low-limit) mustalso be set.




(select)

low-limit,high-limit

(none)

V

i s u a


decimalFormat Read-Write: Sets decimal posit ion from 0 to

6 places, and optionally force (+) sign forpositive values.

0 to 6,


2,

no (+) sign

Effects display value

only (no effect onprecision).

E n g

i n e e r i n g



— —




false : ok




00.0 ok



General,

7 others

General

Table 10-11 NdioThermistorType3Input object properties. (continued)








10–40

The temperature-to-resistance response curve for a Type 3 thermistor sensor is shown

in Table 10-12.

Table 10-12 Type 3 Thermistor Temperature Sensor Response Curve.

Deg. F Ohms Deg. C Ohms Notes

-22 135200.0 -30 125233.0 Outside the NDIO software upper-limit of 100K ohms. Any input above100K (for example, open circuit) displays a set value. See note below.-13 102863.0 -25 102890.0

5 61012.0 -15 61030.0

JACE input circuitry is optimized to provide best resolution around theroom temperature range (10K ohms, 25 C, 77 F).

Issue #2652 NdioThermistorType3Input accuracy

Starting in r2.301.429, a fix/extension was made to the NDIO's internalresponse curve for a ThermistorType3 input object such thattemperature accuracy above 55C (131F) was greatly improved. Boilerapplications up to 120C (248F) can now be handled with little error.

Note that in r2.3.5, an NdioThermistorType3Input object with 0 (no)offset, when reading an open-circuit UI, should read exactly -13.00F or-25.00C. This varies from any object using the pre-428f curve, whichwhen reading an open-circuit UI, displays -11.92F.

Note: If upgrading a JACE with NDIO that is currently runningr2.301.428e (or earlier) to r2.3.5, please note that existingNdioThermistorType3 objects will likely need sensor calibration (offsetchange), as the old curve had about 3.5 degF error at 77F/10K ohms.In some cases, simple elimination of offset may work..If upgrading a JACE with NDIO that is currently running r2.301.429f orlater to r2.3.5, existing NdioThermistorType3 objects used in roomtemperature applications should not require any change to offset.

14 47554.0 -10 47549.0

23 37304.0 -5 37316.0

32 29481.0 0 29490.0

41 23456.0 5 23462.0

50 18782.0 10 18787.0

59 15134.0 15 15136.0

68 12267.0 20 12268.0

77 10000.0 25 10000.0

86 8197.0 30 8197.0

95 6755.0 35 6754.0

104 5595.0 40 5594.0

113 4657.0 45 4656.0

122 3895.0 50 3893.0

131 3272.0 55 3271.0

140 2761.0 60 2760.0

149 2340.0 65 2339.0

158 1991.0 70 1990.0

167 1700.0 75 1700.0

176 1458.0 80 1458.0185 1255.0 85 1255.0

194 1084.0 90 1084.0

203 939.0 95 939.6

212 817.0 100 817.2

221 712.0 105 713.0

230 623.0 110 624.1

239 548.0 115 547.9

248 483.0 120 482.5

250 469

125 426.0

130 377.2

135 334.9

140 298.1

145 266.0

150 238.0



APPENDIX


Niagara Standard Programming Reference Revised: April 20, 2004 A–1

A

Object Property Quick Reference

This appendix provides a complete listing of all properties for all standard Niagara

objects found in the tridium JAR. The following main sections are included:

• Attributes

• Property Quick References

• Variable Types• Enumerations

• Resource Count Ranges

AttributesAttributes for each object property describe its usage. This includes how the property

is accessed, how its value is stored, and what user (access) level is required.

• Attribute Notation

• Attribute Notation Examples

Attribute Notation

In the quick reference table for each object type, the various attributes for each

property are listed inside brackets , using a format similar to:

<access><storage><input/output>:<access level> for example, rwP:Ad

where the following attribute notations are used:

r readable Can be viewed (by user with proper level).

w writeable Can be modified (by user with proper level).

P persistent Property value is persistently stored (disk or flash).

T transient Property value is stored only in RAM.

-dem on demand transient Value from RAM in a foreign device (fetched vs. polled).

i input linkable Linkable input of the object.

o output linkable Linkable output of the object.

~ always display Linkable and always shown on object shape.

Op operator level Requires operator-level access for read or write.

Ad administrator level Requires administrator-level access for read or write.





Appendix A Object Property Quick Reference

Attributes

A–2

Note The attribute of “-dem” (on demand transient) applies to many properties of Niagara

“shadow objects,” used in integrations (BACnet, LonWorks, others). However, for

standard Niagara objects, the “-dem” property attribute does not apply.

Attr ibute Notation Examples

Some common attribute combinations found among object properties:

Attribute Definition Description, Example Property

rT:Op readable, transient, operator level Typical for many status properties, whichare read-only.

Common example: statusFlags

rwP:Ad readable, writeable, persistent,administrator level

Typical for most config properties, which areread-write (for administrator level users

only).

Common example: executionParameters

rTi~:Op readable, transient, input, alwaysshown, operator level

Typical for many object inputs (that areshown on the object shape by default).

Common example: statusInput

rTo~:Op readable, transient, output,always shown, operator level

Typical for many object outputs (that areshown on the object shape by default).

Common example: statusOutput

rwP:Op readable, writeable, persistent,operator level

Used for property description.

Ti:Ad transient, input, administratorlevel

Used for input property executeTrigger .




Property Quick References



Property Quick ReferencesA quick reference table is provided for each object type, listing all properties grouped

by type. Included are property names, data species used, and property attributes.

Object types are listed alphabetically as follows:

• AdminTool • IntegerLog

• AnalogInput • IntToFloat

• AnalogLog • LogService

• AnalogOutput • Logic

• AnalogOverride • Loop

• ApiRecipient • MailRecipient

• AuditLogService • MailService

• BackupService • Math

• BinaryInput • MultistateInput

• BinaryLog • MultistateLog

• BinaryOutput • MultistateOutput

• BinaryOverride • MultistateOverride

• Bundle • Ndio0to10VInput

• Calendar • Ndio0to10VOutput

• Command • NdioBinaryInput

• Comparison • NdioBinaryOutput

• Composite • NdioContainer

• Container • NdioHighSpeedCounterInput

• ControlEngineService • NdioResistiveInput

• CpAnalogNode • NdioProcessor

• CpBinaryNode • NdioThermistorType3Input

• CpIntegerNode • NotificationClass

• CpStringNode • NotificationService

• DatabaseService • PeriodicTrigger

• DateTimeTrigger • PollAlways

• ErrorLogService • PollArchiveService

• FunctionGenerator • PollOnDemand

• GxBarGraph • PrinterRecipient

• GxBoolean • Program

• GxDamper • RemotePrinterRecipient

• GxFan • Schedule

• GxFloat • ServiceContainer • GxImage • Station

• GxInteger • StringLog

• GxPage • TimeSyncService

• GxPipe • Totalizer

• GxSpectrum • UiEngineService

• GxText • VasRecipient

• GxTimePlot • WebUiService






AdminTool

A–4

AdminTool

AnalogInput

Table A-1 AdminTool object properties, quick reference.

Tab Name Data Species At tr ibutes

Status objectType String rT:Op

statusFlags StatusFlagsType rT:Op

Config rootNode UrlType rwP:AdpropertyName String rwP:Ad

elementName String rwP:Ad

newValue String rwP:Ad

recurseChildren boolean rwP:Ad

objectTypeFilter String rwP:Ad

nodeNameFilter String rwP:Ad

propertyValueFilter String rwP:Ad

Visual position PointType rwP:Ad

Security securityGroups SecurityGroupBitsType rwP:Ad

Table A-2 AnalogInput object properties, quick reference.

Tab Name Data Species At tr ibutesStatus objectType String rT:Op


description String rwP:Op

eventState EventStateEnum rT:Op

reliability ReliabilityEnum rwT:Op

outOfService boolean rwP:Op

ackedTransitions EventTransitionBitsType rT:Op

toOffnormal EventTimestampsType rT:Op

toFault EventTimestampsType rT:Op

toNormal EventTimestampsType rT:Op

presentValue float rwT:Op

Config executionParameters ExecutionParametersType rwP:Ad

foreignAddress int rwP:Ad

membershipGroups String rwP:Ad

units EngUnitsEnum rwP:AdcovIncrement float rwP:Ad

defaultInput float rwP:Ad

Alarm Setup timeDelay DurationType rwP:Ad

notificationClass int rwP:Ad

eventEnable EventTransitionBitsType rwP:Ad

notifyType NotifyTypeEnum rwP:Ad

inhibitTime DurationType rwP:Ad

eventTriggerEnable EventTransitionBitsType rwP:Ad

alarmText String rwP:Ad

minPresentValue float rwP:Ad

maxPresentValue float rwP:Ad

highLimit float rwP:Ad

lowLimit float rwP:Ad

deadband float rwP:Ad

limitEnable LimitEnableBitsType rwP:Ad


decimalFormat DecimalFormatType rwP:Ad






AnalogLog

A–5

AnalogLog

Engineering executeTrigger TriggerType Ti:Ad

minExecuteTime int rT:Ad

maxExecuteTime int rT:Ad

averageExecuteTime float rT:Ad

userData String rwP:AdstatusInhibit BooleanStatusType rTi:Op

eventTrigger TriggerType To:Ad

covTrigger TriggerType To:Ad

statusInput FloatStatusType rTi~:Op

statusOutput FloatStatusType rTo~:Op


Table A-2 AnalogInput object properties, quick reference. (continued)


Table A-3 AnalogLog object properties, quick reference.




description String rwP:OplastArchiveTimestamp TimestampType rP:Op




bufferSize int rwP:Ad

stopWhenFull boolean rwP:Ad

archiveSetup LogArchiveSetupType rwP:Ad

logEnableDefault boolean rwP:Ad

collectionMode LogControlNodeCollectionModeEnum rwP:Ad

daysOfTheWeek DaysOfWeekBitsType rwP:Ad

timeRange TimeRangeType rwP:Ad

interval int rwP:Ad

outputFunction AnalogLogNodeOutputFunctionEnum rwP:Ad

changeTolerance float rwP:Ad

deltaLogging boolean rwP:Ad

units EngUnitsEnum rwP:Ad


chartType LogControlNodeChartTypeEnum rwP:Ad

chartColor ColorType rwP:Ad

chartTemplateUrl UrlType rwP:Ad


holeValue float wP:Ad





userData String rwP:Ad

buffer LogRecordBufferType wP:Ad

doArchiveTrigger TriggerType Ti:Ad

doClearTrigger TriggerType Ti:Ad

recordedTrigger TriggerType To:Ad

archivedTrigger TriggerType To:Ad

logEnable BooleanStatusType rTi:Op


statusOutput FloatStatusType rTo:Op

lastValue float wP:Ad







AnalogOutput

A–6

AnalogOutputTable A-4 AnalogOutput object p roperties quick reference.




description String rwP:OpeventState EventStateEnum rT:Op







presentValue float rTo:Op

Priorities priorityArray FloatPriorityArrayType rTi~:Op

relinquishDefault float rwP:Ad





covIncrement float rwP:AdAlarm Setup timeDelay DurationType rwP:Ad

notificationClas int rwP:Ad














commandTags FloatCommandTagsType rwP:Ad






statusInhibit BooleanStatusType rTi:Op






manualSetpoint FloatPriorityType wP:Ad

emergencylSetpoint FloatPriorityType wP:Ad

prioritizedOutput FloatPriorityType rTo~:Op

statusFeedbackOutput FloatStatusType rTo:Op







AnalogOverride

A–7

AnalogOverride

ApiRecipient

AuditLogService

Table A-5 AnalogOverr ide object pro perties quick reference.




description String rwP:OpinOverride boolean rTo:Op




priorityForWriting ControlPriorityEnum rwP:Ad

overrideTime int rwP:Ad

overrideValue float rwP:Ad



Engineering minExecuteTime int rT:Ad




statusInOverride BooleanStatusType rTo~:Op

prioritizedOutput FloatPriorityType rTo~:OpSecurity securityGroups SecurityGroupBitsType rwP:Ad

Table A-6 ApiRecip ient object pro perties quick reference.




notificationInput NotificationTriggerType Ti:Ad

Config validDays DaysOfWeekBitsType rwP:Ad




Table A-7 Audi tLogServ ice object prop erties quick reference.





lastArchiveTimestamp TimestampType rP:Op

Config bufferSize int rwP:Ad




Engineering buffer LogRecordBufferType wP:Ad

doArchiveTrigger TriggerType Ti:AddoClearTrigger TriggerType Ti:Ad









BackupService

A–8

BackupService

BinaryInput

Table A-8 BackupService object pr operties quick reference.




description String rwP:OplastBackupTime TimestampType rP:Ad

Config backupEnabled boolean rwP:Ad

scheduledBackupTime TimeType rwP:Ad



Table A-9 BinaryInput object pro perties quick reference.





eventState EventStateEnum rT:Opreliability ReliabilityEnum rwT:Op






changeOfStateTime TimestampType rP:Op

changeOfStateCount int rP:Op

timeOfStateCountReset TimestampType rP:Op

elapsedActiveTime DurationType rP:Op

timeOfActiveTimeReset TimestampType rP:Op

changeOfStateAlertFlag boolean wP:Ad

activeTimeAlertFlag boolean wP:Ad

presentValue boolean rwT:Op

Config execut ionParameters ExecutionParametersType rwP:AdforeignAddress int rwP:Ad


polarity PolarityEnum rwP:Ad

defaultInput boolean rwP:Ad








changeOfStateAlertLimit int rwP:Ad

activeTimeAlertLimit DurationType rwP:Ad

lastCosCountAlert int wP:Ad

lastActiveTimeAlert DurationType wP:Ad

alertNotificationClass int rwP:Ad

periodicAlerts boolean rwP:Ad

alertText String rwP:Ad

alarmValue boolean rwP:Ad

alarmValueEnabled boolean rwP:Ad


activeInactiveText BooleanEnumTagsType rwP:Ad






BinaryLog

A–9

BinaryLog







statusChangeOfStateCount IntegerStatusType rTo:Op

statusElapsedActiveTime IntegerStatusType rTo:Op

resetChangeOfStateCountTrigger TriggerType Ti:Ad

resetElapsedActiveTimeTrigger TriggerType Ti:Ad

changeOfStateTrigger TriggerType To:Ad

changeOfStateAlertTrigger TriggerType To:Ad

elapsedActiveTimeAlertTrigger TriggerType To:Ad

statusInput BooleanStatusType rTi~:Op

statusOutput BooleanStatusType rTo~:Op


Table A-9 BinaryInput object properties quick reference. (continued)


Table A-10 BinaryLog object pr operties quick reference.
















interval int rwP:Ad


chartType LogControlNodeChartTypeEnum rP:Ad






















BinaryOutput

A–10

BinaryOutputTable A-11 BinaryOutput object pr operties quick reference.

















Priorities pr iorityArray BooleanPriorityArrayType rTi~:Op

relinquishDefault boolean rwP:AdinInterstartDelay boolean rT:Ad





minimumOnTime DurationType rwP:Ad

minimumOffTime DurationType rwP:Ad

restartDisable boolean rwP:Ad

interstartDelayTime DurationType rwP:Ad















commandTags BooleanCommandTagsType rwP:Ad






BinaryOverride

A–11

BinaryOverride

Bundle
















prioritizedOutput BooleanPriorityType rTo~:Op

statusFeedbackOutput BooleanStatusType rTo:Op


Table A-11 BinaryOutput object properties quick reference. (continued)


Table A-12 BinaryOverride object p roperties quick reference.





inOverride boolean rTo:Op






overrideValue float rwP:Ad


activeInactiveText DecimalFormatType rwP:Ad








Table A-13 Bundle object pro perties quick reference.








typeString String rwP:Ad

displayTypeString String rwP:Ad

AlarmSetup alarmText String rwP:Ad







Calendar

A–12

Calendar

Command



icon UrlType rwP:Ad

size DimensionType rwP:Ad

backgroundColor ColorType rwP:AdalarmPageUrl UrlType rwP:Ad







Table A-13 Bundle object properties quick reference. (continued)


Table A-14 Calendar object prop erties quick reference.



statusFlags StatusFlagsType rT:Opdescription String rwP:Op

presentValue boolean rTo:Op





entryList CalendarEntryListType wP:Ad


templateUrl UrlType rwP:Ad







statusInput BooleanStatusType rTi:Op

statusInputDefault boolean rwP:Ad


onActiveTrigger TriggerType To:Ad

onInactiveTrigger TriggerType To:Ad

masterOut SlaveSyncType rTo:Ad

slaveIn SlaveSyncType rTi:Ad


Table A-15 Command object pr operties quick reference.





outputTriggerTextA String rwP:Ad

outputTriggerTextB String rwP:Ad

outputTriggerTextC String rwP:Ad

outputTriggerTextD String rwP:Ad






Comparison

A–13

Comparison

Composite

Engineering outputTriggerA TriggerType To:Ad

outputTriggerB TriggerType To:Ad

outputTriggerC TriggerType To:Ad

outputTriggerD TriggerType To:Ad


Table A-15 Command object properties quick reference. (continued)


Table A-16 Comparison object p roperties quick reference.





presentValue boolean rTo:Op





membershipGroups String rwP:AddefaultA float rwP:Ad

defaultB float rwP:Ad

function ComparisonNodeFunctionEnum rwP:Ad


trueCommand BooleanCmdEnum rwP:Ad

falseCommand BooleanCmdEnum rwP:Ad









statusInputA FloatStatusType rTi~:Op

statusInputB FloatStatusType rTi~:Op




Table A-17 Composite object p roperties quick reference.

















Container

A–14

Container



icon UrlType rwP:Ad


backgroundColor ColorType rwP:AdalarmPageUrl UrlType rwP:Ad







Table A-17 Composite object properties quick reference. (continued)


Table A-18 Container object pr operties quick r eference.



statusFlags StatusFlagsType rT:OpConfig description String rwP:Op




icon UrlType rwP:Ad


backgroundColor ColorType rwP:Ad

alarmPageUrl UrlType rwP:Ad








A–15


CpAnalogNode

Table A-19 ControlEngineService object pro perties quick reference.




description String rwP:OpstartTime String rT:Ad

totalObjectCount int rT:Ad

fastestObjectCount int rT:Ad

fasterObjectCount int rT:Ad

normalObjectCount int rT:Ad

slowerObjectCount int rT:Ad

onTriggerObjectCount int rT:Ad

minutelyObjectCount int rT:Ad

fastestCycles int rT:Ad

fasterCycles int rT:Ad

normalCycles int rT:Ad

slowerCycles int rT:Ad

minutelyCycles int rT:Ad

totalOverruns int rT:Ad

fastestOverruns int rT:AdfasterOverruns int rT:Ad

normalOverruns int rT:Ad

slowerOverruns int rT:Ad

fastestAverageExecuteTime float rT:Ad

fasterAverageExecuteTime float rT:Ad

normalAverageExecuteTime float rT:Ad

slowerAverageExecuteTime float rT:Ad

minutelyAverageExecuteTime float rT:Ad

lateStarts int rT:Ad

Config executionFrequencies ExecutionFrequenciesType rwP:Ad

profileNodes boolean rwP:Ad

displayDots boolean rwP:Ad



Table A-20 CpAnalogNode object pr operties quick reference.





cmdLink float rTi~:Op

value float rTo~:Op




maxValue float rwP:Ad

minValue float rwP:Ad


commandText String rwP:Ad













CpBinaryNode

A–16

CpBinaryNode

CpIntegerNode

CpStringNode

Table A-21 CpBinaryNode object pr operties quick reference.




description String rwP:OpcmdLink boolean rTi~:Op

value boolean rTo~:Op













Table A-22 CpIntegerNode object pr operties quick r eference.





cmdLink int rTi~:Op

value int rTo~:Op




maxValue int rwP:Ad

minValue int rwP:AdVisual position PointType rwP:Ad









Table A-23 CpStringNode object pr operties quick reference.





cmdLink String rTi~:Op

value String rTo~:Op









DatabaseService

A–17

DatabaseService

DateTimeTrigger





maxExecuteTime int rT:AdaverageExecuteTime float rT:Ad



Table A-23 CpStringNode object properties quick reference. (continued)


Table A-24 DatabaseService object pro perties quick reference.





isConnected boolean rT:Op

databaseProductName String rT:OpdatabaseProductVersion String rT:Op

driverName String rT:Op

driverVersion String rT:Op

Config urlPrefix String rP:Ad

databaseType DatabaseTypeEnum rwP:Ad

orderByTimestampDecsending boolean rwP:Ad



Cloudscape,

Config

jdbcDriverClassName String rwP:Ad

jdbcConnectionUrl String rwP:Ad

databaseUser String rwP:Ad

databasePassword String rwP:Ad

MS SQLServer,

Config

msJdbcDriverClassName String rwP:Ad

msJdbcConnectionUrl String rwP:Ad

msDatabaseUser String rwP:Ad

msDatabasePassword String rwP:Ad

msCreateNewDatabase String rwP:Ad

msDatabaseName String rwP:Ad

msDatabaseDataFilename String rwP:Ad

msDatabaseLogFilename String rwP:Ad

Oracle,

Config

orJdbcDriverClassName String rwP:Ad

orJdbcConnectionUrl String rwP:Ad

orDatabaseUser String rwP:Ad

orDatabasePassword String rwP:Ad

Table A-25 DateTimeTrigger object pr operties quick r eference.





Config executionParameters Execut ionParametersType rwP:Ad



triggerDay ConcreteCalendarEntryType rwP:Ad

triggerTime TimeType rwP:Ad







ErrorLogService

A–18

ErrorLogService

FunctionGenerator





userData String rwP:AdtimeTrigger TriggerType To:Ad

lastTrigger DateType rP:Ad


Table A-25 DateTimeTrigger object properties quick reference. (continued)


Table A-26 ErrorLogService object pro perties quick reference.






Config bufferSize int rwP:Ad

stopWhenFull boolean rwP:AdarchiveSetup LogArchiveSetupType rwP:Ad


Engineering buffer LogRecordBufferType wP:Ad






Table A-27 FunctionGenerator object pr operties quick reference.


Status objectType String rT:OpstatusFlags StatusFlagsType rT:Op



Config executionParameter ExecutionParametersType rwP:Ad





increment float rwP:Ad

mode FunctionGeneratorNodeModeEnum rwP:Ad

offset float rwP:Ad

degreesPerCycle int rwP:Ad


rampDirection int wT:Ad

















GxBarGraph

A–19

GxBarGraph

GxBoolean

Table A-28 GxBarGraph object properties quick reference.




isVisible BooleanStatusType rTi:AdConfig foregroundColor ColorType rwP:Ad


labelsColor ColorType rwP:Ad

font FontType rwP:Ad

orientation GxOrientationEnum rwP:Ad



showLabels boolean rwP:Ad



layer GxLayerEnum rwP:Ad

hyperlinkOnClick GxHyperlinkEnum rwP:Ad

hyperlinkUrl UrlType rwP:Ad

statusColorEnabled boolean rwP:Ad

flashingEnabled boolean rwP:AddisplayUnits GxDisplayUnitsEnum rwP:Ad

highlightCommandable boolean rwP:Ad

Engineering binding FloatFlexBindingType rTi:Ad

boundHandle int rT:Ad

boundUrl UrlType rT:Ad

proxyCommands GxProxyCommandsType wT:Ad

facetValues GxFacetValuesType wT:Ad

debugOn boolean rwT:Ad


Table A-29 GxBoolean object properties quick reference.



isVisible BooleanStatusType rTi:Ad

Config activeImage UrlType rwP:Ad

inactiveImage UrlType rwP:Ad

activeColor ColorType rwP:Ad

inactiveColor ColorType rwP:Ad

shape GxShapeEnum rwP:Ad

booleanKey GxBooleanKeyEnum rwP:Ad

borderColor ColorType rwP:Ad

borderWidth int rwP:Ad







flashingEnabled boolean rwP:Ad

displayUnits GxDisplayUnitsEnum wP:Ad







GxDamper

A–20

GxDamper

GxFan

Engineering binding FlexBindingType rTi:Ad




facetValues GxFacetValuesType wT:AddebugOn boolean rwT:Ad


Table A-29 GxBoolean object properties quick reference. (continued)


Table A-30 GxDamper object properties quick reference.





Config foregroundColor ColorType rwP:Ad


orientation GxOrientationEnum rwP:Ad

closeValue float rwP:AdopenValue float rwP:Ad

















Table A-31 GxFan object properties quick reference.







centerColor ColorType rwP:Ad

direction GxDirectionEnum rwP:Ad















GxFloat

A–21

GxFloat

GxImage

Engineering binding BooleanFlexBindingType rTi:Ad






Table A-31 GxFan object properties quick reference. (continued)


Table A-32 GxFloat object properties quick reference.





Config ranges GxRangeSetType rwP:Ad

shape GxShapeEnum rwP:Ad


borderWidth int rwP:AdVisual position PointType rwP:Ad





statusColorEnabled boolean wP:Ad

flashingEnabled boolean wP:Ad










Table A-33 GxImage object pr operties quick reference.





Config image UrlType rwP:Ad

















GxInteger

A–22

GxInteger

GxPage







Table A-33 GxImage object properties quick reference. (continued)


Table A-34 GxInteger object properties quick reference.








Visual position PointType rwP:Adsize DimensionType rwP:Ad















Table A-35 GxPage object pro perties quick reference.














icon UrlType rwP:Ad










GxPipe

A–23

GxPipe

GxSpectrum





userData String rwP:AdSecurity securityGroups SecurityGroupBitsType rwP:Ad

Table A-35 GxPage object properties quick reference. (continued)


Table A-36 GxPipe object properties quick reference.









size DimensionType rwP:Adlayer GxLayerEnum rwP:Ad














Table A-37 GxSpectrum object properties quick reference.





Config lowDeltaColor ColorType rwP:Ad

midDeltaColor ColorType rwP:Ad

highDeltaColor ColorType rwP:Ad

sample GxSpectrumSampleType rT:Ad

midPointDefault float rwP:Ad

valueDelta float rwP:Ad

font FontType rwP:Ad

displayText boolean rwP:Ad








displayUnits GxDisplayUnitsEnum rwP:Ad







GxText

A–24

GxText

GxTimePlot






midPointInput FloatFlexBindingType rTi:Ad


Table A-37 GxSpectrum object properties quick reference. (continued)


Table A-38 GxText object properties, quick reference.







font FontType rwP:Adtext String rwP:Ad

displayBindingText boolean rwP:Ad

justification GxJustificationEnum rwP:Ad










displayUnits GxDisplayUnitsEnum rwP:Ad









Table A-39 GxTimePlot object properties, quick reference.










IntegerLog

A–25

IntegerLog

Config colorA ColorType rwP:Ad

colorB ColorType rwP:Ad

colorC ColorType rwP:Ad

colorD ColorType rwP:Ad

colorBackground ColorType rwP:AdcolorGrid ColorType rwP:Ad



visibleDuration int rwP:Ad

displayLegend boolean rwP:Ad

displayNameA String rwP:Ad

displayNameB String rwP:Ad

displayNameC String rwP:Ad

displayNameD String rwP:Ad





Engineering bindingA FloatFlexBindingType Ti:Ad

bindingB FloatFlexBindingType Ti:AdbindingC FloatFlexBindingType Ti:Ad

bindingD FloatFlexBindingType Ti:Ad

boundNameA String rT:Ad

boundNameB String rT:Ad

boundNameC String rT:Ad

boundNameD String rT:Ad


Table A-39 GxTimePlot object properties, quick reference. (continued)


Table A-40 IntegerLog object p roperties quick reference.
















interval int rwP:Ad

deltaLogging boolean rwP:Ad



chartType LogControlNodeChartTypeEnum rwP:Ad








IntToFloat

A–26

IntToFloat

LogService





userData String rwP:Adbuffer LogRecordBufferType wP:Ad






statusInput IntegerStatusType rTi~:Op

lastValue int wP:Ad


Table A-40 IntegerLog object properties quick reference. (continued)


Table A-41 IntToFloat object pro perties quick reference.







defaultIntValue int rwP:Ad











Table A-42 LogService object pro perties quick reference.





Config logUrlPrefix String rP:Ad

archiveUrlPrefix String rP:Ad

archiveMode ArchiveModeEnum rwP:Ad

archiveAddress AddressesType rwP:Ad

archiveTime TimeType rwP:Ad

lastDailyArchive TimestampType rwP:Ad

minRetryTime int rwP:Ad

maxRetryTime int rwP:Ad


Engineering doArchiveAllTrigger TriggerType Ti:Ad

doClearLastDailyArchiveTrigger TriggerType Ti:Ad







Logic

A–27

Logic

Loop

Table A-43 Logic object prop erties quick reference.




description String rwP:OppresentValue boolean rTo:Op






defaultA boolean rwP:Ad

defaultB boolean rwP:Ad

function LogicNodeFunctionEnum rwP:Ad






Engineering executeTrigger TriggerType Ti:AdminExecuteTime int rT:Ad




statusInputA BooleanStatusType rTi~:Op

statusInputB BooleanStatusType rTi~:Op




Table A-44 Loop object p roperties quick r eference.

















MailRecipient

A–28

MailRecipient




defaultSetpoint float rwP:Ad

defaultAction ActionEnum rwP:AdoutputUnits EngUnitsEnum rwP:Ad

controlledVariableUnits EngUnitsEnum rwP:Ad

proportionalConstant float rwP:Ad

integralConstant float rwP:Ad

maxIntegralGain float rwP:Ad

derivativeConstant float rwP:Ad

bias float rwP:Ad

maximumOutput float rwP:Ad

minimumOutput float rwP:Ad


covIncrement float rwP:Ad




notifyType NotifyTypeEnum rwP:AdinhibitTime DurationType rwP:Ad



errorLimit float rwP:Ad











controlledVariable FloatStatusType rTi~:Op

setpoint FloatStatusType rTi~:Op



action ActionEnum rTi:Op


resetIntegral TriggerType Ti:Ad


Table A-44 Loop object properties quick reference. (continued)


Table A-45 MailRecipient object prop erties quick reference.







address MailRecipientsType rwP:Ad

subject String rwP:Ad

routeAcks boolean rwP:Ad

alarmFields EventFieldBitsType rwP:Ad

ackFields AckFieldBitsType rwP:Ad

alertFields AlertFieldBitsType rwP:Ad








MailService

A–29

MailService

Math

Table A-46 MailService object pro perties quick reference.




description String rwP:OpConfig enabled boolean rwP:Ad

smtpHost String rwP:Ad

fromAddress String rwP:Ad

outboxRetryTime int rwP:Ad

username String rwP:Ad

password String rwP:Ad


Engineering debugOn boolean rwP:Ad


Table A-47 Math object p roperties quick reference.




presentValue float rT:Op






defaultA float rwP:Ad

defaultB float rwP:Ad

defaultC float rwP:Ad

defaultD float rwP:Ad

function MathNodeFunctionEnum rwP:Ad

units EngUnitsEnum rwP:AdoutputHighLimit float rwP:Ad

outputLowLimit float rwP:Ad



inputHighLimit float rwP:Ad

inputLowLimit float rwP:Ad










statusInputA FloatStatusType rTi~:Op

statusInputB FloatStatusType rTi~:Op

statusInputC FloatStatusType rTi~:Op

statusInputD FloatStatusType rTi~:Op







MultistateInput

A–30

MultistateInputTable A-48 MultistateInput object pro perties quick reference.


















presentValue int rwT:OpConfig executionParameters ExecutionParametersType rwP:Ad



defaultInput int rwP:Ad















alarmValues MultistateBitsType rwP:Ad

faultValues MultistateBitsType rwP:Ad


stateText IntegerEnumTagsType rwP:Ad
















statusOutput IntegerStatusType rTo~:Op







MultistateLog

A–31

MultistateLogTable A-49 MultistateLog object pr operties quick reference.




description String rwP:OplastArchiveTimestamp TimestampType rP:Op











interval int rwP:Ad

deltaLogging boolean wP:Ad

units EngUnitsEnum wP:Ad

Visual position PointType rwP:AdchartType LogControlNodeChartTypeEnum rP:Ad
















lastValue int wP:Ad







MultistateOutput

A–32

MultistateOutputTable A-50 MultistateOutput object pr operties quick reference.


















presentValue int rTo:OpPriorities priorityArray IntegerPriorityArrayType rTi~:Op

relinquishDefault int rwP:Ad

inInterstartDelay boolean rT:Ad







perStateMinimumOnTime boolean rwP:Ad


















commandTags IntegerCommandTagsType rwP:Ad






MultistateOverride

A–33

MultistateOverride















statusOutput IntegerStatusType rTo~:Op

manualCommand IntegerPriorityType wP:Ad

emergencyCommand IntegerPriorityType wP:Ad

prioritizedOutput IntegerPriorityType rTo~:Op

statusFeedbackOutput IntegerStatusType rTo:OpbooleanStatusFeedbackOutput BooleanStatusType rTo:Op


Table A-50 MultistateOutput object properties quick reference. (continued)


Table A-51 MultistateOverride object pr operties quick reference.





inOverride boolean rTo:Op






overrideValue int rwP:Ad








prioritizedOutput IntegerPriorityType rTo~:Op







Ndio0to10VInput

A–34

Ndio0to10VInputTable A-52 Ndio0to10VInput object properties, quick r eference.












syncFlag boolean rT:Ad






ioIndex int rwP:Adlinearization NdioLinearizationTableType rwP:Ad































Ndio0to10VOutput

A–35

Ndio0to10VOutputTable A-53 Ndio0to10VOutput object pro perties quick reference.












Priorities priorityArray FloatPriorityArrayType rTi~:Op

relinquishDefault float rwP:Ad




units EngUnitsEnum rP:Ad

covIncrement float rwP:AdioIndex int rwP:Ad

offset float rwP:Ad

linearization NdioLinearizationTableType rwP:Ad


notificationClas int rwP:Ad














commandTags FloatCommandTagsType rwP:Ad












manualSetpoint FloatPriorityType wP:Ad

emergencylSetpoint FloatPriorityType wP:Ad


statusFeedbackOutput FloatStatusType rTo:Op







NdioBinaryInput

A–36

NdioBinaryInputTable A-54 NdioBinaryInput object pr operties quick reference.


















presentValue boolean rwT:OpsyncFlag boolean rT:Ad

Config execut ionParameters ExecutionParametersType rwP:Ad



ioIndex int rwP:Ad
















alarmValue boolean rwP:Ad

alarmValueEnabled boolean rwP:Ad
























NdioBinaryOutput

A–37

NdioBinaryOutputTable A-55 NdioBinaryOutput object p roperties quick reference.

















Priorities priorityArray BooleanPr ior ityArrayType rTi~:Op

relinquishDefault boolean rwP:AdinInterstartDelay boolean rT:Ad




ioIndex int rwP:Ad




















commandTags BooleanCommandTagsType rwP:Ad






NdioContainer

A–38

NdioContainer


















statusFeedbackOutput BooleanStatusType rTo:Op


Table A-55 NdioBinaryOutput object properties quick reference. (continued)


Table A-56 NdioContainer object pro perties quick reference.




Config description String rwP:Op




icon UrlType rwP:Ad




Engineering debug boolean rwP:Op

verbose boolean rwP:Op


Table A-57 NdioHighSpeedCounterInput object properties, quick reference.














NdioResistiveInput

A–39

NdioResistiveInput





ioIndex int rwP:AdcountScale float rwP:Ad

rateHistory int rwP:Ad

rateInterval int rwP:Ad

rateScale float rwP:Ad

rateUnits EngUnitsEnum rwP:Ad








rawOutput long rPo:Op

countOutput long rPo:Op

bootAdjust long rPo:AdtotalOutput FloatStatusType rTo~:Op

rateOutput FloatStatusType rTo:Op


Table A-57 NdioHighSpeedCounterInput object properties, quick reference.


Table A-58 NdioResistiveInput object properties, quick r eference.



















ioIndex int rwP:Ad




















NdioProcessor

A–40

NdioProcessor






maxExecuteTime int rT:AdaverageExecuteTime float rT:Ad







Table A-58 NdioResistiveInput object properties, quick reference. (continued)


Table A-59 NdioProcessor object prop erties quick reference.

Type Tab Name Data Species At tr ibutes

General Status objectType String rT:OpstatusFlags StatusFlagsType rT:Op


procEnable boolean rwP:Ad

procNum NdioProcessorEnum rwP:Ad




icon UrlType rwP:Ad





DeviceStatus Status deviceStatusAverageExecuteTime PointType rwT:Ad

deviceStatusTotalExecuteTime int rwT:Ad

deviceStatusExecuteCycles int rwT:Ad

deviceStatusObjectCount int rwT:Ad

deviceStatusStartTime String rwT:Ad

Config deviceStatusPingDelay int rwP:Ad

deviceStatusDisplayDots boolean rwP:Ad

deviceStatusDisabled boolean rwP:Ad

AlarmSetup notificationClass int rwP:Ad

Table A-60 NdioThermistorType3Input object properties, quick reference.



















NotificationClass

A–41

NotificationClass

NotificationService





covIncrement float rwP:AdioIndex int rwP:Ad


offset float rwP:Ad

tempUnits NdioTempUnitsEnum rwP:Ad











lowLimit float rwP:Addeadband float rwP:Ad














Table A-60 NdioThermistorType3Input object properties, quick reference.


Table A-61 NotificationClass object pro perties quick reference.





Config notificationClass int rwP:Ad

ackRequired EventTransitionBitsType rwP:Ad

eventPriorities EventPrioritiesType rwP:Ad


Engineering not ificationOutput Not if icationTriggerType To:Ad


slaveIn SlaveSyncType rTi:AdSecurity securityGroups SecurityGroupBitsType rwP:Ad

Table A-62 NotificationService object pr operties quick r eference.










PeriodicTrigger

A–42

PeriodicTrigger

PollAlways

PollArchiveService

Config alarmArchiveAddress AddressesType rwP:Ad

archiveMode NotificationArchiveEnum rwP:Ad


Engineering debug boolean rwP:Ad

unackedEventTable DxSetType wP:AdeventHistoryTable DxSetType wP:Ad

unackedAlertTable DxSetType wP:Ad

alertHistoryTable DxSetType wP:Ad


Table A-62 NotificationService object properties quick reference. (continued)


Table A-63 PeriodicTrigger object pr operties quick r eference.





Config execut ionParameters ExecutionParametersType rwP:Ad

foreignAddress int rwP:AdmembershipGroups String rwP:Ad

triggerPeriod DurationType rwP:Ad







trigger TriggerType To:Ad


Table A-64 PollAlways object pro perties quick reference.








icon UrlType rwP:Ad





Table A-65 PollArchiveService object properties, quick r eference.










PollOnDemand

A–43

PollOnDemand

PrinterRecipient

Config group0 PollArchiveGroupType rwP:Ad

group1 PollArchiveGroupType rwP:Ad



group4 PollArchiveGroupType rwP:Adgroup5 PollArchiveGroupType rwP:Ad




Engineering pollGroup0Trigger TriggerType Ti:Ad

pollGroup1Trigger TriggerType Ti:Ad







debugOn boolean rwP:Ad


Table A-65 PollArchiveService object properties, quick reference. (continued)


Table A-66 PollOnDemand object pro perties quick reference.








icon UrlType rwP:Ad





Table A-67 PrinterRecipient object prop erties quick reference.








printerName PrinterNameType rwP:Ad

AlarmSetup alertNotificationClass int rwP:Ad








Program

A–44

Program


Schedule

Table A-68 Program object quick reference.




description String rwP:OpConfig executionParameters ExecutionParametersType rwP:Ad







icon UrlType rwP:Ad






sourceCode String wP:Ad

classFile byte[ ] wP:AdinDebugSession boolean rT:Ad


Table A-69 RemotePrinterRecipient object pro perties quick reference.








printerName PrinterNameType rwP:AdAlarmSetup alertNotificationClass int rwP:Ad



Table A-70 Schedule object pr operties quick reference.





isActive boolean rTo:Op

overrideIn BooleanPriorityType rTi:Op

holidayOverride BooleanStatusType rTi~:OpnextEventTime DateTimeType rTo:Op

nextEventValue BooleanStatusType rTo:Op

activeSchedule DailyRefType T:Op






ServiceContainer

A–45

ServiceContainer





effectivePeriod DateRangeType rwP:AdactiveInactiveText BooleanEnumTagsType rwP:Ad

sunday DailyScheduleType wP:Ad

monday DailyScheduleType wP:Ad

tuesday DailyScheduleType wP:Ad

wednesday DailyScheduleType wP:Ad

thursday DailyScheduleType wP:Ad

friday DailyScheduleType wP:Ad

saturday DailyScheduleType wP:Ad

specialEvents SpecialEventListType wP:Ad

holidaySchedule SpecialEventType wP:Ad

specialCleanup int rwP:Ad




activeColor ColorType rwP:AdinactiveColor ColorType rwP:Ad







holidayOverrideDefault boolean rwP:Ad




onActiveTrigger TriggerType To:Ad

onInactiveTrigger TriggerType To:Ad


slaveIn SlaveSyncType rTi:Ad


Table A-70 Schedule object properties quick reference. (continued)


Table A-71 ServiceContainer object pr operties quick r eference.




Config description String rwP:Ad








Station

A–46

Station

StringLog

Table A-72 Station object properties quick reference.




description String rwP:OpcurrentTime DateTimeType rwT:Ad

bootTime TimestampType rT:Ad

lastDownTime TimestampType rT:Ad

lastAliveTime TimestampType rP:Ad

activeUserChange boolean T:Ad

isRunning boolean rT:Ad

osArch String rT:Op

osName String rT:Op

osVersion String rT:Op

javaVendor String rT:Op

javaVersion String rT:Op

release String rT:Op

Config addressBook AddressBookType wP:Ad

httpPort int rwP:Ad

httpsPort int rwP:AdenableSSL boolean rwP:Ad

authenticationType StationAuthenticationEnum P:Ad

defaultPage UrlType rwP:Ad

pstoreFlushTime int rwP:Ad

snsBackupTime int rwP:Ad

interstationSendTime int rwP:Ad


announcementTTL int rwP:Ad

enableAnnouncement boolean rwP:Ad

minAnnouncementFreq int rwP:Ad

maxAnnouncementFreq int rwP:Ad






Engineering userList UserListType wP:Ad

nextHandle int rP:Ad


strongPasswords boolean rwP:Ad

Table A-73 StringLog object p roperties quick reference.











TimeSyncService

A–47

TimeSyncService





stopWhenFull boolean rwP:AdarchiveSetup LogArchiveSetupType rwP:Ad





interval int rwP:Ad


chartType LogControlNodeChartTypeEnum wP:Ad

chartColor ColorType wP:Ad

chartTemplateUrl UrlType wP:Ad





userData String rwP:Adbuffer LogRecordBufferType wP:Ad






input FlexBindingType rTi~:Op


Table A-73 StringLog object properties quick reference. (continued)


Table A-74 TimeSyncService object pro perties quick reference.





serverReport1 String rT:Ad



Config serverEnabled boolean rwP:Ad

serverPort int rwP:Ad

clientEnabled boolean rwP:Ad

clientPollFrequency int rwP:Ad

clientResetTolerance int rwP:Ad

timeProtocolServer1 TimeSyncServerType rwP:Ad




Engineering debugOn boolean rwP:Ad







Totalizer

A–48

Totalizer

UiEngineService

VasRecipient

Table A-75 Totalizer object pro perties quick reference.




description String rwP:OppresentValue float rwT:Op

persistentValue float wP:Ad




defaultInput float rwP:Ad


totalizationInterval TotalizerNodeIntervalEnum rwP:Ad

startTime TimestampType rP:Ad






averageExecuteTime float rT:AduserData String rwP:Ad


statusTotal FloatStatusType rTo~:Op

resetTotalTrigger TriggerType Ti:Ad

updateOutputTrigger TriggerType To:Ad


Table A-76 UiEngineService object p roperties quick reference.




description String rwP:OpaverageExecuteTime float rT:Ad

totalExecuteTime int rT:Ad

executionCycles int rT:Ad

overruns int rT:Ad

objectCount int rT:Ad

startTime String rT:Ad

averageInterCycleDelay float rT:Ad

lateStarts int rT:Ad

Config cycleTime int rwP:Ad




Table A-77 VasRecipient object pro perties quick reference.













WebUiService

Variable Types

Variable types used by standard Niagara objects include the following:



Table A-77 VasRecipient object properties quick reference. (continued)


Table A-78 WebUiService object pr operties quick r eference.






totalExecuteTime int rT:Ad

executionCycles int rT:Ad

overruns int rT:Ad

objectCount int rT:Ad

startTime String rT:Ad

averageInterCycleDelay float rT:Ad

lateStarts int rT:AdConfig cycleTime int rwP:Ad




• boolean • int

• BooleanPriorityType • IntegerPriorityType

• BooleanStatusType • IntegerStatusType

• BooleanTriggerType • IntegerTriggerType

• DateRangeType • LimitEnableBitsType

• DateTimeType • MailRecipientsType

• DateType • NotificationTriggerType

• DimensionType • PointType

• DurationType • ScaleOffsetType

• EventPrioritiesType • StatusFlagsType

• EventTimestampsType • String

• EventTransitionBitsType • TimeRangeType

• float • TimestampType

• FloatPriorityType • TimeSyncServerType

• FloatStatusType • TimeType

• FloatTriggerType • TriggerType







A–50

boolean

BooleanPriorityType

BooleanStatusType

BooleanTriggerType

DateRangeType

DateTimeType

DateType

DimensionType

DurationType

primitive

value rw booleanauto rw boolean

priority rw ControlPriorityEnum

status rw StatusFlagsType

value rw boolean

value rw boolean

startDate rw DateType

endDate rw DateType

date rw DateType

time rw TimeType

year rw int

month rw MonthEnum

day rw int

weekday rw WeekdayEnum

hour rw int

minute rw int

second rw intnextDay r DateTimeType

prevDay r DateTimeType

year rw int

month rw MonthEnum

day rw int

weekday rw WeekdayEnum

nextDay r DateType

prevDay r DateType

width rw int

height rw int

duration rw int







EventPrioritiesType

EventTimestampsType

EventTransitionBitsType

float

FloatPriorityType

FloatStatusType

FloatTriggerType

int

IntegerPriorityType

IntegerStatusType

IntegerTriggerType

toOffnormalPriority rw int

toFaultPriority rw int

toNormalPriority rw int

eventTime rw TimestampType

ackTime rw TimestampType

count rw int

toOffnormal rw boolean

toFault rw boolean

toNormal rw boolean

primitive

value rw float

auto rw boolean



value rw float

value rw float

primitive

value rw int

auto rw boolean



value rw int

value rw int







A–52

LimitEnableBitsType

MailRecipientsType

NotificationTriggerType

PointType

ScaleOffsetType

StatusFlagsType

String

TimeRangeType

TimestampType

TimeSyncServerType

TimeType

lowLimitEnabled rw boolean

highLimitEnabled rw boolean

toList rw String

ccList rw String

bccList rw String

—

x r w int

y r w int

scale rw float

offset rw float

inAlarm rw boolean

fault rw boolean

overridden rw boolean

outOfService rw boolean

unackedAlarm rw boolean

down r boolean

primitive

startTime rw TimeType

endTime rw TimeType

exclusive rw boolean

dateTime rw DateTimeType

useSupervisor rw boolean

hostName rw String

hour rw int

minute rw int







TriggerType

Enumerations

Enumeration types used by standard Niagara objects include the following:

ActionEnum

AlertTypeEnum

second rw int

hundredth rw int

—

• ActionEnum • GxEndpointEnum

• AlertTypeEnum • GxHyperlinkEnum

• AnalogLogNodeOutputFunctionEnum • GxJustificationEnum

• ArchiveModeEnum • GxLayerEnum

• BooleanCmdEnum • GxOrientationEnum

• CommDataBitsEnum • GxShapeEnum

• CommFlowControlEnum • LogControlNodeChartTypeEnum

• CommParityEnum • LogControlNodeCollectionModeEnum

• CommStopBitsEnum • LogicNodeFunctionEnum

• ComparisonNodeFunctionEnum • MathNodeFunctionEnum

• ControlPriorityEnum • MonthEnum

• DatabaseTypeEnum • NotificationArchiveEnum

• EngUnitsEnum • NotifyTypeEnum

• EventStateEnum • PolarityEnum• EventTypeEnum • PollArchiveEnum

• ExecutionFrequencyEnum • ReliabilityEnum

• ExecutionOrderEnum • StationAlarmEnum

• FunctionGeneratorNodeModeEnum • StationAuthenticationEnum

• GxBooleanKeyEnum • TotalizerNodeIntervalEnum

• GxDirectionEnum • WeekdayEnum

• GxDisplayUnitsEnum

0 direct

1 reverse

0 changeOfStateCount

1 runtime

2 equipmentFailure









ControlPriorityEnum

DatabaseTypeEnum

EngUnitsEnum

1 level_1

2 level_2

3 level_3

4 level_4

5 level_5

6 level_6

7 level_7

8 level_8

9 level_9

10 level_10

11 level_11

12 level_12

13 level_13

14 level_14

15 level_15

16 level_16

0 Cloudscape1 MSDE

2 MS_SQL_Server

3 Oracle

EngUnitsEnum (also see “About Units,” page 5-6)0 square_meters 57 centimeters_of_water 114 currency10

1 square_feet 58 inches_of_water 122 kilohms

2 milliamperes 59 millimeters_of_mercury 123 megohms

3 amperes 60 centimeters_of_mercury 124 millivolts

4 ohms 61 inches_of_mercury 125 kilojoules_per_kilogram

5 volts 62 degrees_Celsius 126 megajoules

6 kilovolts 63 degrees_Kelvin 127 joules_per_degree_Kelvin

7 megavolts 64 degrees_Fahrenheit 128 joules_per_kilogram_degree_Kelvin

8 volt_amperes 65 degree_days_Celsius 129 kilohertz

9 kilovolt_amperes 66 degree_days_Fahrenheit 130 megahertz

10 megavolt_amperes 67 years 131 per_hour

11 volt_amperes_reactive 68 months 132 milliwatts

12 kilovolt_amperes_reactive 69 weeks 133 hectopascals

13 megavolt_amperes_reactive 70 days 134 millibars

14 degrees_phase 71 hours 135 cubic_meters_per_hour

15 power_factor 72 minutes 136 liters_per_hour

16 joules 73 seconds 137 kilowatt_hours_per_square_meter

17 kilojoules 74 meters_per_second 138 kilowatt_hours_per_square_foot

18 watt_hours 75 kilometers_per_hour 139 megajoules_per_square_meter

19 kilowatt_hours 76 feet_per_second 140 megajoules_per_square_foot

20 btus 77 feet_per_minute 141 watts_per_square_meter_degree_Kelvin

21 therms 78 miles_per_hour 256 milliseconds

22 ton_hours 79 cubic_feet 257 kilograms_per_cubic_meter 23 joules_per_kilogram_dry_air 80 cubic_meters 258 Kbtus

24 btus_per_pound_dry_air 81 imperial_gallons 259 Mbtus

25 cycles_per_hour 82 liters 260 radians_per_sec

26 cycles_per_minute 83 us_gallons 261 decibels

27 hertz 84 cubic_feet_per_minute 262 grams

28 grams_of_water_per_kilogram_dry_air 85 cubic_meters_per_second 263 milligrams

29 percent_relative_humidity 86 imperial_gallons_per_minute 264 metric_tons

30 millimeters 87 liters_per_second 265 milliliters

31 meters 88 liters_per_minute 266 kiloliters

32 inches 89 us_gallons_per_minute 267 micrometers







A–56

EventStateEnum

EventTypeEnum

ExecutionFrequencyEnum

33 feet 90 degrees_angular 268 kilometers

34 watts_per_square_foot 91 degrees_Celsius_per_hour 269 milliliters_per_second

35 watts_per_square_meter 92 degrees_Celsius_per_minute 270 megawatt_hours

36 lumens 93 degrees_Fahrenheit_per_hour 271 gallons_per_hour

37 luxes 94 degrees_Fahrenheit_per_minute 272 killowatts_per_hour

38 foot_candles 95 no_units 273 delta_fahrenheit39 kilograms 96 parts_per_million 274 kiloamperes

40 pounds_mass 97 parts_per_billion 275 kilojoules_per_hour

41 tons 98 percent 276 kg_of_water_per_dry_air

42 kilograms_per_second 99 percent_per_second 277 candles

43 kilograms_per_minute 100 per_minute 278 raw_value

44 kilograms_per_hour 101 per_second 279 kilocalories_per_hour

45 pounds_mass_per_minute 102 psi_per_degree_Fahrenheit 280 ph_value

46 pounds_mass_per_hour 103 radians

47 watts 104 revolutions_per_minute

48 kilowatts 105 currency1

49 megawatts 106 currency2

50 btus_per_hour 107 currency3

51 horsepower 108 currency4

52 tons_refrigeration 109 currency5

53 pascals 110 currency6

54 kilopascals 111 currency7

55 bars 112 currency8

56 pounds_force_per_square_inch 113 currency9

EngUnitsEnum (continued) (also see “About Units,” page 5-6)

0 normal

1 fault

2 offnormal

3 high_limit

4 low_limit

64 unknown

0 change_of_bitstring

1 change_of_state

2 change_of_value

3 command_failure

4 floating_limit

5 out_of_range

0 never

1 slower

2 normal

3 faster

4 fastest5 minutely

6 on_trigger

7 fixed_minutely







ExecutionOrderEnum

FunctionGeneratorNodeModeEnum

GxBooleanKeyEnum

GxDirectionEnum

GxDisplayUnitsEnum

GxEndpointEnum

GxHyperlinkEnum

GxJustificationEnum

0 input

1 processor

2 output

0 sinusoid

1 ramp

0 value

1 in_alarm

2 fault

3 overridden

4 out_of_service

5 unacked_alarm

6 down

0 north

1 south

2 east

3 west

0 none

1 abbreviated

2 full

0 open

1 l_north_east

2 l_north_west

3 l_south_east

4 l_south_west

5 t_north

6 t_south

7 t_east

8 t_west

9 cross

0 disabled1 binding

2 url

0 center

1 left

2 right







A–58

GxLayerEnum

GxOrientationEnum

GxShapeEnum

LogControlNodeChartTypeEnum

LogControlNodeCollectionModeEnum

LogicNodeFunctionEnum

MathNodeFunctionEnum

0 top

1 layer_1

2 layer_2

3 layer_3

4 layer_4

5 layer_5

6 layer_6

7 background

0 auto

1 vertical

2 horizontal

0 rectangle

1 ellipse

0 plot

1 area

2 bar

3 candle

4 bar_3d

5 candle_3d

0 change_of_value

1 interval

0 A_AND_B

1 A_OR_B

2 A_XOR_B

3 A_NOT_B

0 minimum 10 sin

1 maximum 11 cos

2 summation 12 tan

3 average 13 asin

4 difference 14 acos5 abs 15 atan

6 sqrt 16 reset

7 ln 17 multiplication

8 log 18 division

9 exp 19 power







MonthEnum

NdioProcessorEnum

NdioTempUnitsEnum

NotificationArchiveEnum

NotifyTypeEnum

PolarityEnum

0 Jan

1 Feb

2 Mar

3 Apr

4 May

5 Jun

6 Jul

7 Aug

8 Sep

9 Oct

10 Nov

11 Dec

-1 undefined

0 first_onboard_processor

1 second_onboard_processor

2 third_onboard_processor

3 fourth_onboard_processor 4 first_processor_slot_0

5 second_processor_slot_0

6 first_processor_slot_1

7 second_processor_slot_1

0 degrees_celsius

1 degrees_fahrenheit

2 degrees_kelvin

0 archive_disabled1 archive_local

2 archive_remote

3 archive_local_no_SQL

0 alarm

1 event

2 ack_notif ication

3 alert

4 display_ack

0 normal

1 reverse







A–60

PollArchiveEnum

ReliabilityEnum

StationAlarmEnum

StationAuthenticationEnum

TotalizerNodeIntervalEnum

WeekdayEnum

0 archive_disabled

1 archive_group_0

2 archive_group_1

3 archive_group_2

4 archive_group_3

5 archive_group_4

6 archive_group_5

7 archive_group_6

8 archive_group_7

0 no_fault_detected

1 no_sensor

2 over_range

3 under_range

4 open_loop

5 shorted_loop

6 no_output_value

7 unreliable_other 8 process_error

0 stationUp

1 stationDown

2 stationBoot

3 powerLost

4 powerLostShutdown

5 powerRestored

6 batteryTestFailed

7 batteryTestPassed

0 none

1 basic

0 hourly

1 minutely

0 Sun

1 Mon

2 Tue3 Wed

4 Thu

5 Fri

6 Sat




Resource Count Range



Resource Count RangeTable A-79 lists the resource count range for various Niagara objects. Realize that

these values will vary from object to object, depending on the number of properties

(in each) that are set to non-default values. Note also the following:

• Container-type objects do not list collective resource counts for child objects.

• Ranges for log-type objects (AnalogLog, BinaryLog, etc.) assume the default

bufferSize of 60. Add 1 resource count for each 1-increase in bufferSize.

• Links also consume resource counts. Refer to “Link Resources,” page 2-13..

Table A-79 Resource count ranges for various Niagara objects.

AdminTool 31 to 53 GxImage 42 to 64 PollAlways 30 to 42

AnalogInput 63 to 116 GxInteger 43 to 80 PollArchiveService 33 to 47

AnalogLog 115 to 160 GxPage 54 to 77 PollOnDemand 30 to 42

AnalogOutput 72 to 132 GxPipe 18 to 33 PrinterRecipient 22 to 34

AnalogOverride 41 to 57 GxSpectrum 48 to 81 Program 52 and up

ApiRecipient 16 to 21 GxText 49 to 86 RemotePrinterRecipient 27 to 39

AuditLogService 38 to 1043 GxTimePlot 58 to 94 Schedule 72 to 132

BackupService 22 to 28 IntegerLog 115 to 160 ServiceContainer 600 and up

BinaryInput 80 to 136 IntToFloat 35 to 51 Station 89 to 200

BinaryLog 115 to 160 LogService 33 to 47 StringLog 115 to 160

BinaryOutput 91 to 155 Logic 67 to 101 TimeSyncService 41 to 63

BinaryOverride 41 to 55 Loop 75 to 137 Totalizer 42 to 62

Bundle 48 to 74 MailRecipient 24 to 47 UiEngineService 40 to 47

Calendar 72 to 132 MailService 29 to 50 WebUiService 25 to 33

Command 32 to 42 Math 67 to 101 Note: Program objects are typicallylarge consumers of resource counts.Whenever possible, use standardcontrol or apps objects whenengineering a station database.

The resource count for any portion of arunning station (container or primitiveobject) can be checked by clicking theobject in the JDE Tree View, andselecting from the menu bar Search >

Resource Count.

You can also open a host connection

using a browser and use the prismresources page to check a station’sresource count allocations. See“Checking Resource Count,” page1-25.

Comparison 48 to 80 MultistateInput 79 to 141

Composite 48 to 74 MultistateLog 115 to 160

Container 30 to 42 MultistateOutput 93 to 161

ControlEngineService 60 to 70 MultistateOverride 39 to 55

CpAnalogNode,CpBinaryNode,CpIntegerNode,CpStringNode

35 to 51

Ndio0to10VInput 70 to 126

Ndio0to10VOutput 93 to 160

NdioBinaryInput 90 to 146

DatabaseService 55 to 63 NdioBinaryOutput 104 to 168

DateTimeTrigger 38 to 50 NdioContainer 30 to 53

ErrorLogService 38 to 1043 NdioHighSpeedCounterInput 54 to 84

FunctionGenerator 50 to 72 NdioProcessor 53 to 84

GxBarGraph 45 to 82 NdioResistiveInput 70 to 126

GxBoolean 47 to 82 NdioThermistorType3Input 70 to 126

GxDamper 44 to 73 NotificationClass 22 to 34

GxFan 43 to 70 NotificationService 51 to 6

GxFloat 43 to 80 PeriodicTrigger 36 to 46

http://-/?-

http://-/?-






Resource Count Range

A–62




Niagara Standard Programming Reference Revised: April 20, 2004Index-1

Numerics

0to10VInput object (Ndio) 10-13

0to10VOutput object (Ndio) 10-16

4-20mA input, (Ndio) 10-13

A

abbreviations for units 5-6

accessing archives 4-21

account enabled 1-20

ackedTransitions property 5-11, 5-12

resetting flags 5-11

action, Loop object 5-92

active xii, 3-1

ActiveUsers view, Station object 1-22

AddressBook 1-15

host address 1-16

monitor function 1-16

poll archive group 1-16

station access 1-15

station relationship 1-16

Admin Tool xii, 1-10, 1-26, 4-3

adminfiles.txt 1-28

Administrator user 1-17

Admin-level commands 3-2

AdminTool object 6-18 to 6-25

audit log notes 6-25

elementName reference 6-20examples 6-23

changing limitEnable for AIs 6-24

changing log object end times 6-23

stopping FunctionGenerators 6-24

property quick reference A-4

using wildcards 6-25

alarm xii, 1-21, 1-23, 5-8, 5-11, 5-13

alarm console 5-14, 9-7

alarm delay

AnalogInput object 5-21

BinaryInput object 5-39

BinaryOutput object 5-51

MultistateInput object 5-109

MultistateOutput object 5-121

alarm detection






alarm inhibit






alarm notification






standalone JACE-4/5 9-7

alarm setup properties 5-13

Alarms view, Station object 1-23

alarmText property

container objects 7-5

control objects 5-14

pass-up process 7-5

station 1-12

alerts xii, 5-109

BI change-of-state (COS) 5-40

BI runtime (active time) 5-40

MSI alarm setup properties 5-110

I N D E X



Index



MSI change-of-state (COS) 5-110

MSI runtime (active time) 5-110

alertText property



pass-up process 7-5

analog xi i

AnalogInput object 5-15 to 5-22, 10-8

alarm delay 5-21

alarm detection 5-19

alarm inhibit 5-20

alarm notification 5-20

examples 5-22, 10-32

fault conditions 5-21


AnalogLog object 6-26 to 6-31chartType examples 6-31

delta logging 6-29


statusOutput 6-29

AnalogOutput object 5-23 to 5-28

command limits 5-26

command tags 5-28

examples 5-28


AnalogOverride object 5-29 to 5-32

directly available 5-31


remaining override time 5-32

with Command object 5-32

ApiRecipient object 9-8


apps objects 6-1 to 6-62

AdminTool 6-18

AnalogLog 6-26

BinaryLog 6-32

common properties 6-5common things 6-4

IntegerLog 6-41

MultistateLog 6-44

Program 6-47

Schedule 6-52

selecting 6-3

StringLog 6-60

archive (SQL) storage 4-34

archive log data

format 4-20

storage 6-10

troubleshooting 4-34

archiveSetup property 6-17

archiving properties files 1-30

area chartType 6-31

attributes of properties 2-5

notation for A-1

examples A-2

AuditLogService object 4-6 to 4-7


B

BackupService object 4-8 to 4-9


BACnet xii, 1-3, 5-2, 5-3, 5-15, 5-23, 5-42, 5-101, 5-112,

6-2, 6-35, 6-52, 9-1, 9-2, A-2

heritage in apps objects 6-2

heritage in control objects 5-3

Ndio objects 10-8

terminology 5-3

bacnet.properties file 1-31

bar chartType 6-31 bar_3d chartType 6-31

bias, Loop object 5-90, 5-92

binary xi i

BinaryInput object 5-33 to 5-41, 10-8

alarm delay 5-39


alarm inhibit 5-39


alerts 5-40

examples 5-41

Ndio 10-20


routinely configured properties 5-37

BinaryLog object 6-32 to 6-34


BinaryOutput object 5-42 to 5-52, 10-8

alarm delay 5-51





Index

alarm inhibit 5-51


command tags 5-49

control-related properties 5-48

examples 5-52

Ndio 10-24

priority levels 5-47



BinaryOverride object 5-53 to 5-56



remaining override time 5-56

with Command object 5-56

buffer size, log objects 6-10

bufferSize property 6-16Bundle object 7-14 to 7-18

example 7-17

known issues 7-16


when to use 7-16

C

Calendar object 6-35 to 6-40

calendar template 6-40

Calendar view 6-39

master/slave 6-38

outputs 6-38

processing and priorities 6-38


candle chartType 6-31

candle_3d chartType 6-31

chartTemplateUrl property 6-14

chartType property

examples 6-31checking

JACE-4/5 CPU utilization 1-25

JACE-5 Flash space 1-26

object count 1-25

resource count 1-25

child dependencies 1-7

GxPage 7-24

ServiceContainer 7-34

child object xi i

classes, notification 9-2

collectionMode property 6-17

command xiii

Command object 5-57 to 5-58

examples 5-58

AnalogOverride 5-32

BinaryOverride 5-56

MultistateOverride 5-126


command tags

AnalogOutput object 5-28



commands xiii, 3-1 to 3-6Admin-level 3-2

all available, by object 3-3

control 3-1

debug 5-5

resetAckedTransitions 5-11

Comparison object 5-59 to 5-61

example 5-61


composite

adding properties 7-11

editor 7-10

inputs and default values 7-12

property names 7-10

reasons to 7-9

reasons to not 7-13

composite link types 2-10

Composite object 7-19 to 7-21

example 7-21

known issues 7-16


constant value, Math object5-98

Container object 7-22 to 7-23


container objects xiii, 7-1 to 7-36

Bundle 7-14

common properties 7-6

common things 7-4

Composite editor 7-10



Index



Container 7-22

functions 7-3

GxPage 7-24

layer control 7-3

NdioContainer 10-10

NdioProcessor 10-11

PollAlways 7-29

PollOnDemand 7-31

ServiceContainer 7-34

standard views 3-7

that “composite” 7-8

control commands 3-1

control objects xiii, 5-1 to 5-131

AnalogInput 5-15

AnalogOutput 5-23

AnalogOverride 5-29Binary Output 5-42

BinaryInput 5-33

Command 5-57


common things 5-5

Comparison 5-59

CpAnalogNode 5-62

CpBinaryNode 5-65

CpIntegerNode 5-67

CpStringNode 5-69

DateTimeTrigger 5-71

event-types 5-11

FunctionGenerator 5-73

IntToFloat 5-77

like Ndio objects 10-8

Logic 5-79

Loop 5-83

Math 5-95

MultistateInput 5-101

MultistateOutput 5-112

MultistateOverride 5-124notificationClass property 5-13

PeriodicTrigger 5-128

selecting 5-4

Totalizer 5-130

ControlEngineService object 4-10 to 4-15

execution frequencies 4-14

execution order 4-15

object execution 4-14


COV, COS xiii

CpAnalogNode object 5-62 to 5-64

example 5-64


CpBinaryNode object 5-65 to 5-66

example 5-66


CpIntegerNode object 5-67 to 5-68

example 5-68


CpStringNode object 5-69 to 5-70

example 5-70

CPU temperature, JACE-NP and JACE-NX 1-27

CPU utilization, JACE-5 1-25current selected color 8-8

D

data

enumerations 2-2

primitives 2-2

data species xiii, 2-1

DatabaseBrowser view 4-19

List Filters 4-25

Summary Information 4-26

vs. Web browser 4-25

DatabaseService object 4-16 to 4-27

DatabaseBrowser view 4-19


SQL queries 4-24

output types 4-23

running 4-21

summary and useful URLs 4-26

DateTimeTrigger object 5-71 to 5-72


daysOfTheWeek property 6-17

ddns.properties file 1-31

debug command 5-5

debugger, Program object 6-50

default

stateText value 5-118





Index

views, by object 3-8

delta logging 6-29

dependencies xiii, 1-7

derivative gain, Loop object 5-92

dialup section, AddressBook 1-16

drivers.properties file 1-27, 1-31

E

editor

Calendar object 6-39

composite 7-10

link 2-6

Program object 6-49

properties files 1-28Schedule object 6-58

engineering units 5-6

enumerations xiii, 2-2, A-53

ActionEnum A-53

AlertTypeEnum A-54

AnalogLogNodeOutputFunctionEnum A-54

ArchiveModeEnum A-54

BooleanCmdEnum A-54

CommDataBitsEnum A-54

CommFlowControlEnum A-54

CommParityEnum A-54

CommStopBitsEnum A-54

ComparisonNodeFunctionEnum A-55

ControlPriorityEnum A-55

EngUnitsEnum 5-6, A-55

EventStateEnum A-56

EventTypeEnum A-56

ExecutionFrequencyEnum A-56

ExecutionOrderEnum A-57

FunctionGeneratorNodeModeEnum A-57

GxBooleanKeyEnum A-57GxDirectionEnum A-57

GxDisplayUnitsEnum A-57

GxEndPointEnum A-57

GxHyperlinkEnum A-57

GxJustificationEnum A-57

GxLayerEnum A-58

GxOrientationEnum A-58

GxShapeEnum A-58

LogControlNodeChartTypeEnum A-58

LogControlNodeCollectionModeEnum A-58

LogicNodeFunctionEnum A-58

MathNodeFunctionEnum A-58

MonthEnum A-59

NdioProcessorEnum A-59

NdioTempUnitsEnum A-59

NotificationArchiveEnum A-59

NotifyTypeEnum A-59

PolarityEnum A-59

PollArchiveEnum A-60

ReliabilityEnum A-60

StationAlarmEnum A-60

StationAuthenticationEnum A-60

TotalizerNodeIntervalEnum A-60WeekDayEnum A-60

ErrorLogService object 4-28 to 4-30


eventEnable property 5-13

events xiii, 5-11

eventState property 5-12

eventTriggerEnable property 5-14

event-type objects 5-11

alarm setup properties 5-13

status properties 5-12

executeTrigger property 4-15

apps objects 6-4

control objects 5-5

execution of objects 4-13, 4-14

executionParameters

ControlEngineService 4-14

expansion boards, I/O 10-7

external links 1-12, 1-26, 2-9

F

facets (views) 3-8

fault conditions 5-21

Flash space, JACE-4/5 1-26

foreignAddress property 5-9, 6-6

foundation object

Station 1-9



Index



FunctionGenerator object 5-73 to 5-76

examples 5-76


ramp mode 5-75

sinusoid mode 5-75

G

General tab, UserAdmin 1-18

Gx objects 8-1 to 8-34


common things 8-3

current selected color 8-8

execution of 8-2

graphic file / color-based types 8-3GxBarGraph 8-10

GxBoolean 8-13

GxDamper 8-16

GxFan 8-18

GxFloat 8-20

GxImage 8-22

GxInteger 8-24

GxPipe 8-26

GxSpectrum 8-28

GxText 8-30

GxTimePlot 8-33

isvisible input 8-7

keyboard shortcuts 8-9

pre-designed types 8-2

shortcuts 8-8

Gx submenu 8-8

gx.properties file 1-32, 8-15

GxBarGraph object 8-10 to 8-12


GxBoolean object 8-13 to 8-15

property quick reference A-19GxDamper object 8-16 to 8-17


GxFan object 8-18 to 8-19


GxFloat object 8-20 to 8-21


GxImage object 8-22 to 8-23


GxInteger object 8-24 to 8-25


GxPage object 7-24 to 7-28

composite 7-28

layer control 7-26


GxPipe object 8-26 to 8-27


GxSpectrum object 8-28 to 8-29


GxText object 8-30 to 8-32

link flexibility 8-32


GxTimePlot object 8-33 to 8-34


H

hierarchies, in objects 1-4

HighSpeedCounterInput object (Ndio) 10-29

host address 1-16

host properties files 1-28

Hot Links tab, UserAdmin 1-19

HTTP port, station 1-11

I

image file reference 8-8

inactive xiii, 3-1

incoming archives 4-34

index property (Ndio) 10-5

inhibitTime property 5-14

input xiii

IntegerLog object 6-41 to 6-43


similarity to AnalogLog 6-43

integral and derivative gain, PID control 5-90

integral gain, PI control 5-92

integral overshoot, PI control 5-92

internal links 2-8

interval property 6-17





Index

IntToFloat object 5-77 to 5-78

example 5-78


IP address 1-16

isVisible input 8-7

applications for 8-7

J

JACE I/O expansion boards 10-7

JACE-4/5

checking CPU utilization 1-25

checking Flash space 1-26

JACE-NP and JACE-NX, monitoring CPU

temperature 1-27

JAR file xiii, 1-8

K

keyboard shortcuts for moving objects 8-9

L

layer controlcontainer objects 7-3

GxPage 7-26

license.properties file 1-32

licensing services 4-3

limits and guidelines

station resources 1-24

links 2-5 to 2-13

categories 2-7

external 2-9

internal 2-8

local link 2-8

colors 2-11

data flow 2-12

editor 2-6

GxText flexibility 8-32

notification objects 9-3

resources 2-13

rules 2-11

service objects 7-36

types 2-10

composite 2-10

LonTalk local binding 2-10

Lontalk network binding 2-10

normal 2-10

trigger 2-10

ui 2-10

links view 2-7

List Filters, DatabaseBrowser 4-25

Local Library xiv, 5-78, 6-18, 8-27, 10-2

local links 2-8

log objects 6-7 to 6-17

archive (SQL) storage 6-10

archiveSetup property 6-17

bufferSize property 6-10

collectionMode property 6-17

commands 6-15


daysOfTheWeek property 6-17

interval property 6-17

location of

JACE controller 6-11

WebSupervisor 6-11

log samples 6-7

order of 6-9log selector 6-14

LogTable 6-7

stopWhenFull property 6-16

timeRange property 6-17

trigger inputs 6-15

trigger outputs 6-15

views 6-12

visual properties 6-30

log servlet 4-33

log storage 6-10

LogChart 6-12

controls and toolbar 6-13

title from description 6-5, 6-16

logEnableDefault property 6-17

Logic object 5-79 to 5-82

examples 5-82




Index



truth tables 5-81

LogService object 4-31 to 4-35


LonTalk local binding link 2-10

LonTalk network binding link 2-10

LonWorks xiv, 1-3, 2-6, 3-8, 5-2, 7-31, A-2

Lonworks 5-78

Loop object 5-83 to 5-94

action 5-92

bias 5-90, 5-92

configuration guidelines

PI mode 5-92

PID mode 5-93

P-only mode 5-90

examples 5-93

loop terminology 5-88output calculation

PI configuration 5-91

statusInhibit 5-89

output limits 5-90, 5-92

PI control 5-90

integral gain 5-92

overshoot 5-92

PID control 5-93

P-only control 5-89


repeats per minute 5-91

statusInhibit 5-89

M

MailRecipient object 9-9 to 9-12

example e-mails 9-12


MailService object 4-36 to 4-38

outbox 4-38


master/slave

Calendar objects 6-38

data flow 2-13

NotificationClass objects 9-2, 9-7

Schedule objects 6-57

Math object 5-95 to 5-100

cascading multiple 5-100

for valve compenstation 5-99

NaN 5-98


reset function 5-99

MAX_VALUE, MIN_VALUE 2-2

mime.properties file 1-32

monitor function, in AddressBook 1-16

multistate xiv

MultistateInput object 5-101 to 5-111

alarm delay 5-109


alarm inhibit 5-108

BACnet guidelines 5-105

examples 5-111

property quick reference A-30routinely configured properties 5-105

stateText 5-105

MultistateLog object 6-44 to 6-46


similarity to BinaryLog 6-46

MultistateOutput object 5-112 to 5-123

alarm delay 5-121


alarm inhibit 5-121


BACnet guidelines 5-118

command tags 5-119

control-related properties 5-118

examples 5-123



stateText 5-117

MultistateOverride object 5-124 to 5-127



remaining override time 5-127with Command object 5-126

N

names of objects 1-5

NaN (not a number) 5-98





Index

Ndio objects 10-1 to 10-41

common things 10-8

inputs 10-5

like control objects 10-8

outputs 10-6

ndio.properties file 1-32

Ndio0to10VInput object 10-13 to 10-15


Ndio0to10VOutput object 10-16 to 10-19


NdioBinaryInput object 10-20 to 10-23


NdioBinaryOutput object 10-24 to 10-29


NdioContainer object 10-10

property quick reference A-38 NdioHighSpeedCounterInput object 10-29 to 10-33


NdioProcessor object 10-11


NdioResistiveInput object 10-33 to 10-37

properties quick reference. A-39

NdioThermistorType3Input object 10-38 to 10-41


niagarad.properties file 1-32

node xiv

normal links 2-10

notification classes 9-2

notification objects 9-1 to 9-19


general notes 9-3

linking 9-3

MailRecipient 9-9

NotificationClass 9-5

PrinterRecipient 9-13

recipients 9-2

RemotePrinterRecipient 9-15SnmpRecipient 9-17

NotificationClass object 9-5 to 9-7

master/slaves 9-2


notificationClass property 5-13

NotificationService object 4-39 to 4-40


O

object count, checking for station 1-25

object model (integration platform) 1-3

object type xivobjects xiv, 1-1, 1-3

categories 1-7

commands 3-1

dependencies 1-7

execution 4-13

Gx execution 4-48

hierarchies 1-4

libraries 1-8

names (and rules) 1-5

property quick references A-3

shadow 1-3

swid 1-6

views 3-6

on_demand_transient property 2-5, A-1

outbox, MailService object 4-38

outgoing archives 4-34

outOfService property 5-12

output xiv

output limits, Loop object 5-90, 5-92

output types, SQL queries 4-23

outputs, Ndio 10-6

P

parent xv

parent dependencies 1-7

peer station, AddressBook 1-16

PeriodicTrigger object 5-128 to 5-129


persistent property 2-5, A-1

PI loop output 5-91

plot chartType 6-31

PollAlways object 7-29 to 7-30


PollArchiveService object 4-41 to 4-44

AddressBook setup 1-16




Index



PollOnDemand object 7-31 to 7-33

cache, view 7-33


port

HTTP (Station) 1-11

SMTP (MailService) 4-36

Time (TimeSyncService) 4-46

port.properties file 1-32

presentValue property 5-12

primitive xv

data species 2-2

objects 1-4

PrinterRecipient object 9-13 to 9-14


priority levels 5-47

priority variable types 2-4Prism servlet 1-25

Program object 6-47 to 6-51

debugger 6-50

editor 6-49


simple example 6-51

TRIPL language 6-50

properties xv, 2-1, 2-5

files in Niagara 1-27

quick references, by object A-3

proportional gain, loop 5-90, 5-92

protocol services 4-3

Q

queries, SQL 4-22, 4-24

R

ramp mode, FunctionGenerator 5-75

ras.properties file 1-32

recipient objects 9-2

remaining override time

AnalogOverride object 5-32

BinaryOverride object 5-56

MultistateOverride object 5-127

Remote Library xv

RemotePrinterRecipient object 9-15 to 9-16


repeats per minute, Loop object 5-91

reset function, Math object 5-99

resetAckedTransitions command 5-11

ResistiveInput object (Ndio) 10-33

resource count

checking station 1-25

comparison by object A-61

links 2-13

log objects 6-10

running an SQL query 4-21

S

Schedule object 6-52 to 6-59

editor 6-58

master/slave 6-57

outputs 6-57

processing and priorities 6-56


security administrator 1-20

security groups 1-21, 7-5

security mask, user 1-20

securityGroups property

about 1-21

apps objects 6-6


station 1-13

selecting

apps objects 6-3


control objects 5-4

selector, log 6-14

service objects 4-1 to 4-50adding or removing 4-4

AuditLogService 4-6

BackupService 4-8


ControlEngineService 4-10

core services 4-2

DatabaseService 4-16





Index

ErrorLogService 4-28

LogService 4-31

MailService 4-36

NotificationService 4-39

PollArchiveService 4-41

TimeSyncService 4-45

UiEngineService 4-47

WebUiService 4-49

ServiceContainer object 7-34 to 7-36

linking child services 7-36


services xv, 4-1 to 4-50

additional 4-2

core 4-2

optional 4-2

licensing 4-3 protocol (integration) 4-3

SMTP 4-36

SnmpRecipient object 9-17

sns xv, 1-12

spy utility 1-25

SQL database,database tables 4-19

SQL queries 4-21, 4-24

output types 4-23

running 4-21, 4-22

Standard Output xv, 1-25, 4-13, 4-37, 4-40, 4-43, 4-46, 5-5,

5-84, 6-4, 6-20

station xv, 1-1

administrator user 1-17

alarm types 1-23

limits and guidelines 1-24

object count 1-25

overview 1-2

resource count 1-25

Station object 1-9 to 1-31

ActiveUsers view 1-22

AddressBook view 1-15

Alarms view 1-23


UserAdmin view 1-17

station.properties file 1-33

statusColors.properties file 1-33

statusFlags property 2-3, 5-8, 10-9

statusInhibit property, Loop object 5-89

stopWhenFull property 6-16

StringLog object 6-60 to 6-62

FlexBinding input 6-62

subordinate station, AddressBook 1-16

supervisor station, AddressBook 1-16

swid xv, 1-6

in property sheets 1-6

sysmon (JACE-NP and JACE-NX) 1-27

system.properties file 1-33, 1-34

T

tables, database 4-19

ThermistorType3Input object (Ndio) 10-38

time zone 6-8timeDelay property 5-13

timeRange property 6-17

timestamp xvi, 4-6, 4-28

archive format 4-20

log format 6-7

notes 6-8

TimeSyncService object 4-45 to 4-46


Totalizer object 5-130 to 5-131


transient property 2-5, A-1

Tree View xvi, 7-2, 8-8

trigger xvi

trigger links 2-10

TRIPL program 6-50

U

UiEngineService object 4-47 to 4-48


units 5-6

URL xvi

user messages 1-22

UserAdmin 1-17

General tab 1-18

Hot Links tab 1-19



Index



Security tab 1-20

account enabled 1-20

security administrator 1-20

security mask 1-20

UTC (Universal Time, Coordinated) 6-8

V

valve compensation , Math object 5-99

variable types 2-3 to 2-4, A-49

boolean (primitive) 2-2, A-50

BooleanPriorityType A-50

BooleanStatusType A-50

BooleanTriggerType A-50

DateRangeType A-50

DateTimeType A-50

DateType A-50

DimensionType A-50

DurationType A-50

EventPrioritiesType A-51

EventTimestampsType A-51

EventTransitionBitsType A-51

float (primitive) 2-2, A-51

FloatPriorityType A-51

FloatStatusType A-51

FloatTriggerType A-51

int (primitive) 2-2, A-51

IntegerPriorityType A-51

IntegerStatusType A-51

IntegerTriggerType A-51

LimitEnableBitsType A-52

MailRecipientsType A-52

NotificationTriggerType A-52

PointType A-52

ScaleOffsetType A-52

StatusFlagsType A-52

String (primitive) 2-2, A-52

TimeRangeType A-52

TimestampType A-52

TimeSyncServerType A-52

TimeType A-53

TriggerType A-53

VasRecipient object 9-18 to 9-19

view cache

PollOnDemand 7-33views xvi, 3-6 to 3-11

all available, by object 3-8

special 3-7

standard 3-6

W

Web Supervisor xvi, 1-2, 1-15, 4-2, 4-8, 4-16, 4-36, 4-39,

4-45, 4-49, 7-16, 7-26, 9-13

WebUiService object 4-49 to 4-50 property quick reference A-49

Win32SysMonDriver 1-27

Workspace xvi, 3-7, 7-2

WorkspaceEditor xvi, 3-7, 7-4



You can help make th is manual even better!Please help us make our documentation as useful as possible. Use this form to advise

us of errors, descriptions that are not clear, or provide any other helpful information.

Mail this form to:

Tridium, Inc.

3951 Westerre Parkway, Suite 350

Richmond, Virginia 23233Attention: Tridium Documentation Team

Or fax it to us at: (804) 747-5204

Or e-mail your comments to us at: [email protected]

Thank you for taking the time to help us improve our documentation!

Documentation Comment Form

mailto:[email protected]%20?Subject=Niagara%20Standard%20Programming%20Reference%20(Release%202.3.4)

mailto:[email protected]%20?Subject=Niagara%20Standard%20Programming%20Reference%20(Release%202.3.4)

Date post:	10-Feb-2018
Category:	Documents
Upload:	mark-izsm-amerson
View:	216 times
Download:	0 times

Std Programming Reference

Documents