Tridium NiagaraAX User Guide
विज्ञापन
विज्ञापन
Technical Publications
Published: June 24, 2005
NiagaraAX User Guide
Copyright © 2005, Tridium, Inc.
All rights reserved.
See
“Copyright and Trademarks” on page xix
Contents
Niagara
AX
NiagaraAX User Guide
Contents
Document Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xix
The Niagara Framework solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About control systems integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
About common networking and Internet protocols . . . . . . . . . . . . . . . .
4
About programming for non-programmers . . . . . . . . . . . . . . . . . . . . . .
4
About embedded systems capabilities . . . . . . . . . . . . . . . . . . . . . . . . . .
5
About distributed systems capabilities . . . . . . . . . . . . . . . . . . . . . . . . . .
5
About component software design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
About Niagara software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
8
About Niagara building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About module characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
About module benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
13
About master/slave components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
About point components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
16
About presentation modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
About presentation xml (px) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
About presentation design philosophy . . . . . . . . . . . . . . . . . . . . . . . . .
18
About presentation media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
About BOG files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Tour of the Workbench GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About Workbench window controls . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
About the side bar panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
27 i
Published: June 24, 2005
ii
Contents
About the view pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
About the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
About the menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
38
About the locator bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
About the view selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Types of popup menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Customizing the Workbench environment . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Additional Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Creating tabs in the view pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
Workbench options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Types of control points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Other control components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
About data value categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
About point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
53
About point inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
About point actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
About point facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Extension process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Types of point extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
About the proxy extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
About control extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
About alarm extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
About history extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
How triggers are used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
About related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Types of status flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Priority of status indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
How status flags are set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
About “isValid” status check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
Location of proxy points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
How proxy points are made. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Proxy points versus simple control points. . . . . . . . . . . . . . . . . . . . . . .
79
ProxyExt properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
About the priority scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
About minimum On and Off times . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Some composite examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Composite issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
Where are networks located? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
About Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network component hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
About network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
About device components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
About device extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
About the Driver Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Driver Manager New and Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Common network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network status properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
About network Alarm Source Info . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
About Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
About Tuning Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
About poll components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
100
Additional network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103
About the Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device New Folder and New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
105
107
About Device Discover, Add and Match (Learn Process) . . . . . . . . . .
109
Match (Device) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
Manager table features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
Common device components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
Device status properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
114
Device Alarm Source Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
Device address properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
Driver-specific device slots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
116
Types of device extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
116
About the Points extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
117
About the Histories extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
118
About the Retry Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
About the Alarms extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
About the Schedules extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
120
About the Point Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Points New Folder and New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122
125
About Point Discover, Add and Match (Learn Process). . . . . . . . . . . .
126
About other Points views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
131 iii
Published: June 24, 2005
iv
Contents
About Histories extension views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
History Import Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
132
History Export Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
137
About Schedules extension views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schedule Import Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
143
Schedule Export Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
148
About the Niagara Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NiagaraNetwork component notes . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
Niagara Station Manager notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
154
NiagaraStation component notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
156
About the Bql Query Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
157
Niagara proxy point notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
161
Station Alarms notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
162
Station Schedules import/export notes . . . . . . . . . . . . . . . . . . . . . . . .
163
Common field bus concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Driver architecture framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
167
Learn versus New devices and points . . . . . . . . . . . . . . . . . . . . . . . . .
167
Types of History Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the history service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
170
About the audit history service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
172
About the log history service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
173
Types of history space views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the chart builder view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
175
About the database maintenance view . . . . . . . . . . . . . . . . . . . . . . . .
176
About the nav container view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
177
About the history chart view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
178
About the collection table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
179
About the history table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
180
About the history summary view . . . . . . . . . . . . . . . . . . . . . . . . . . . .
181
About the history editor view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
182
About the history process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add history extensions to a component. . . . . . . . . . . . . . . . . . . . . . . .
185
Configure history extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
185
About history names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
187
188
About editing history data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of the alarming process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
About alarm extensions and components . . . . . . . . . . . . . . . . . . . . . . .
192
About alarm extension properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
193
About the alarm service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About memory alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of alarm service views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About alarm service property sheet . . . . . . . . . . . . . . . . . . . . . . . . . . .
198
About alarm extension manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
199
About alarm database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . .
201
About the alarm class summary view . . . . . . . . . . . . . . . . . . . . . . . . . .
203
About alarm class properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
205
About alarm class mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
206
Types of alarm recipients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the console recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
208
About the alarm console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
209
About the station recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
211
About the email recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
212
About the lineprinter recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
213
Px views as slot properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
219
About the New Px View wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
219
221
About the Px Editor Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
223
View Source XML dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
226
Types of panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
227
Widget painting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
228
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
228
About widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
229
230
Types of bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
231
Types of binding properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
232
About bound label bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
233
About value bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
234
About spectrum bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
234 v
Published: June 24, 2005
vi
Contents
About setpoint bindings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
235
About increment setpoint bindings . . . . . . . . . . . . . . . . . . . . . . . . . . .
236
About spectrum setpoint bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . .
236
About action bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
236
About table bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
237
About field editor bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
237
Relative and absolute bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
238
Default Wb Web Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
240
Basic Wb Web Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
240
Default Hx Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
241
Basic Hx Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
242
About the Make Widget wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Make Widget wizard: examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nav file elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
265
About the Nav File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nav File Editor source objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
267
Nav File Editor result tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
268
Nav File Editor buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
268
Security model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Categories and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
272
Users and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
273
Permissions and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
275
About permission levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
276
UserService security notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
278
About user audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
278
Multi-station security notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
280
UserService properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
282
UserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
283
PermissionsBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
286
CategoryManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
289
CategoryBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
290
CategorySheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
292
About the scheduling model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
Schedule component categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
293
Schedule component views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
294
Schedule component links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
295
Schedule special events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
296
Schedule exports and imports (master/slave) . . . . . . . . . . . . . . . . . . . .
296
About weekly schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of weekly schedule components. . . . . . . . . . . . . . . . . . . . . . . . .
297
Weekly schedule output processing . . . . . . . . . . . . . . . . . . . . . . . . . . .
298
Weekly Scheduler view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
299
About calendar schedules (holidays). . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CalendarSchedule Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
309
Calendar Scheduler view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
310
Calendar day selections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
312
CalendarSchedule slots and other notes . . . . . . . . . . . . . . . . . . . . . . . .
314
Trigger Scheduler view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
315
TriggerSchedule slots and other notes . . . . . . . . . . . . . . . . . . . . . . . . .
319
Adding a schedule or calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
320
Configuring schedules and calendars . . . . . . . . . . . . . . . . . . . . . . . . . .
321
Linking schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
324
Importing schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
326
Lexicon Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
330
Lexicon Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
331
Lonworks service manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New module wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
License request dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workbench service manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting and exiting Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting started with stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the nav side bar (tree) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
Published: June 24, 2005
viii
Contents
Selecting a component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
347
Viewing a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
347
Editing component data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
349
Using the property sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
352
Using the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
353
Using the slot sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
354
Using the link sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
355
Creating alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
356
Routing alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
356
Managing alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
358
Making widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
360
Binding widgets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
361
Editing widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
361
Animating widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
362
Using the Nav File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a new Nav file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
363
Editing a Nav file in the Nav File Editor. . . . . . . . . . . . . . . . . . . . . . .
364
Component Reference Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Components in alarm module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alarm-AlarmClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
368
alarm-AlarmConsoleOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
368
alarm-AlarmPortalOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
368
alarm-AlarmService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
369
alarm-AlarmSourceExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
369
alarm-AlarmSourceInfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
369
alarm-BooleanChangeOfStateAlarmExt . . . . . . . . . . . . . . . . . . . . . . .
369
alarm-BooleanCommandFailureAlarmExt . . . . . . . . . . . . . . . . . . . . .
370
alarm-ConsoleRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
370
alarm-FaultAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
370
alarm-EnumChangeOfStateAlarmExt . . . . . . . . . . . . . . . . . . . . . . . . .
371
alarm-EnumCommandFailureAlarmExt . . . . . . . . . . . . . . . . . . . . . . .
371
alarm-LinePrinterRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
371
alarm-MemoryAlarmService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
371
alarm-OffnormalAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
372
alarm-OutOfRangeAlarmExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
372
alarm-StationRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
372
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
alarm-StatusAlarmExt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
372
Components in backup module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
backup-BackupService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
372
Components in baja module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
374
baja-CategoryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
374
baja-Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
374
375
375
baja-FileSystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
375
375
375
376
376
baja-StationSaveJob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
377
377
baja-LocalHost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
377
377
baja-ModuleSpace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
377
baja-Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
378
baja-PermissionsMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
378
378
baja-ServiceContainer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
378
378
378
baja-UnrestrictedFolder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
378
379
baja-UserService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
379
379
baja-WsTextBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
379
379
Components in bajaui module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bajaui-BorderPane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
380
bajaui-Bookmark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
380
bajaui-BoundTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
380
380
bajaui-CanvasPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
bajaui-CheckBox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
bajaui-ConstrainedPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
bajaui-EdgePane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
381
bajaui-ExpandablePane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
bajaui-FlowPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381
bajaui-GridPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381 ix
Published: June 24, 2005
x
Contents
bajaui-HyperlinkLabel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
382
382
382
bajaui-RadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
382
382
382
bajaui-Polygon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
bajaui-ScrollPane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
bajaui-Separator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
383
bajaui-SplitPane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
bajaui-TabbedPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
bajaui-TextEditorOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
383
bajaui-ToggleButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
bajaui-ValueBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
Components in chart module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
chart-BarChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
chart-ChartCanvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
chart-ChartHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
chart-ChartPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
chart-DefaultChartLegend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
chart-LineChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
385
Components in control module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
control-BooleanPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386
control-BooleanWritable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386
control-DiscreteTotalizerExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386
control-EnumPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386
control-EnumWritable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-NullProxyExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-NumericPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-NumericTotalizerExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-NumericWritable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-StringPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
control-StringWritable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
control-TimeTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
Components in converters module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
converters-EnumToSimpleMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
Components in crypto module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
crypto-CryptoService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
crypto-SslProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
Components in devkit module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
devkit-LexiconOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
388
Components in driver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
driver-ConfigRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
389
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
driver-DriverContainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
389
driver-HistoryNetworkExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
389
driver-PingMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
389
driver-SendTimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
390
driver-SendTimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
390
driver-TuningPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
390
driver-TuningPolicyMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
390
Components in email module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
390
email-EmailRecipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
391
email-EmailService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
391
email-IncomingAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
391
email-OutgoingAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
391
Components in file module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
file-ApplicationFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
392
392
392
392
file-BogScheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
392
393
393
393
393
393
393
393
393
393
393
393
394
394
file-PowerPointFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
394
394
394
394
394
394
394
394
Components in fox module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fox-FoxClientConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
fox-FoxFileSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
fox-FoxServerConnection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395 xi
Published: June 24, 2005
xii
Contents
fox-FoxService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
fox-FoxSession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
fox-ServerConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
395
Components in gx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
396
Components in help module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
help-BajadocOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
396
Components in history module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
history-AuditRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
history-AuditHistoryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
history-BooleanCovHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
history-BooleanIntervalHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
history-ConfigRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
history-ConfigRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-CovAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-EnumCovHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-EnumIntervalHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-FoxHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-FoxHistorySpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-HistoryConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-HistoryDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
history-HistoryEditorOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-HistoryId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-HistoryService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-IntervalAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-LocalDatabaseConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-LogHistoryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399
history-NumericCovAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
400
history-NumericCovHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
400
history-NumericIntervalAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . .
400
history-NumericIntervalHistoryExt. . . . . . . . . . . . . . . . . . . . . . . . . . .
400
history-StringCovHistoryExt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
401
history-StringIntervalHistoryExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
401
Components in kitPx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
kitPx-ActionBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
401
kitPx-AnalogMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
402
kitPx-Bargraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
402
kitPx-BoundLabelBinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
402
kitPx-BoundLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
402
kitPx-GenericFieldEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
402
kitPx-ImageButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
403
kitPx-IncrementSetPointBinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
403
kitPx-RefreshButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
403
kitPx-SaveButton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
404
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
kitPx-SetPointBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
404
kitPx-SetPointFieldEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
404
Components in ldap module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ldap-LdapClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
404
ldap-LdapConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
405
ldap-LdapUserService. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
405
Components in net module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
net-InternetAddress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
405
Components in niagaraDriver module. . . . . . . . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-DistributedQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
405
niagaraDriver-NiagaraAlarmDeviceExt . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraFoxService . . . . . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraHistoryDeviceExt . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraHistoryImport . . . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraNetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraPointDeviceExt . . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraPointFolder . . . . . . . . . . . . . . . . . . . . . . . . . . . .
406
niagaraDriver-NiagaraProxyExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-NiagaraScheduleDeviceExt. . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-NiagaraScheduleImportExt . . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-NiagaraStation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-NiagaraStationFolder. . . . . . . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-PointChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
407
niagaraDriver-QueryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
408
niagaraDriver-StationDiscoveryTask . . . . . . . . . . . . . . . . . . . . . . . . . .
408
niagaraDriver-StationWorker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
408
Components in program module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
program-Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
408
program-ProgramService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
408
Components in pxeditor module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
pxeditor-NewPxViewDialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
Components in raster module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
raster-RasterEditorOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
Components in rdb module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdb-RdbmsFolder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
rdb-RdbmsNetwork. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
rdb-RdbmsWorker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
Components in rdbDb2 module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdbDb2-Db2Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
410
rdbDb2-Db2HistoryDeviceExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
410
Components in rdbOracle module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdbOracle-OracleDatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
410
rdbOracle-OracleHistoryDeviceExt . . . . . . . . . . . . . . . . . . . . . . . . . . .
410 xiii
Published: June 24, 2005
xiv
Contents
Components in rdbSqlServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdbSqlServer-SqlServerDatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . .
410
rdbSqlServer-SqlServerHistoryDeviceExt . . . . . . . . . . . . . . . . . . . . .
410
Components in schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
411
schedule-BooleanSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
411
schedule-CalendarSchedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
411
schedule-EnumSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
411
schedule-NumericSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
411
schedule-StringSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
412
schedule-TriggerSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
412
Components in timesync module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
timesync-TimeServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
412
timesync-TimeSyncService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
412
Components in web module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
web-WebService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
413
Components in workbench module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-ComponentFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
413
workbench-WbFieldEditorBinding . . . . . . . . . . . . . . . . . . . . . . . . . . .
414
workbench-WbViewBinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
414
workbench-WsOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
414
alarm-AlarmConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
415
Alarm Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
416
Viewing Alarm Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
416
416
alarm-AlarmDbMaintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alarm-AlarmClassSummary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alarm-AlarmExtManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
backup-BackupManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
chart-ResourceManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
devkit-LexiconReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
driver-DeviceManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
driver-DriverManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
driver-HistoryExportManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
driver-HistoryImportManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
email-EmailAccountManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
history-DatabaseMaintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
Niagara
AX
NiagaraAX User Guide
history-HistoryChartBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
history-HistoryExtManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
history-HistorySummaryView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
html-WbHtmlView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
426
HTML Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
426
Stylesheet Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
429
ldap-LdapUserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-NiagaraHistoryExportManager . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-NiagaraHistoryImportManager . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-NiagaraPointManager . . . . . . . . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-NiagaraScheduleExportManager . . . . . . . . . . . . . . . . . . . .
niagaraDriver-NiagaraScheduleImportManager . . . . . . . . . . . . . . . . . . . .
niagaraDriver-ServerConnectionsSummary . . . . . . . . . . . . . . . . . . . . . . .
niagaraDriver-StationManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
program-ProgramEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
program-RobotEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdb-RdbmsHistoryExportManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rdb-RdbmsSessionView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
schedule-CalendarScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
schedule-CurrentDaySummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weekly Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
440
440
440
440
schedule-TriggerScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
timesync-TimeSyncManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WireSheet Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
441
workbench-PrintDialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
444
workbench-CompositeEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
444
workbench-ExportDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
444
wbutil-CategoryBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
wbutil-CategoryManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
Published: June 24, 2005
xvi
Contents
wbutil-PermissionsBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
wbutil-ResourceEstimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
wbutil-UserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-CollectionTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-DirectoryList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-HexFileEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-JobServiceManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-LinkSheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-ModuleSpaceView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OptionsButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
448
workbench-NavContainerView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-NavFileEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-PropertySheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PropertySheet Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
448
Config Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
449
449
OrdChooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
449
workbench:FileOrdChooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
450
workbench:DirectoryOrdChooser . . . . . . . . . . . . . . . . . . . . . . . . . . . .
450
workbench:HistoryOrdChooser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
workbench:RefChooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
workbench:BqlQueryBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
workbench:ProjectionBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
workbench:ExtentBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
452
workbench:QualifierBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
452
452
Enum Range Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
452
workbench-StationSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-TextFileEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-ServiceManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-WbPxView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
workbench-WbServiceManagerView . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In this appendix (introduction). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About keyboard shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of menu bar items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the File menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
461
About the Edit menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
463
About the Search menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
465
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Contents
About the Bookmarks menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
466
About the Tools menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
466
About the Window menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
467
About the Px Editor menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
468
About the Help menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
469
Types of popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the nav side bar popup menu items . . . . . . . . . . . . . . . . . . . . . .
470
About the wire sheet popup menu items. . . . . . . . . . . . . . . . . . . . . . . .
471
About the property sheet popup menu items . . . . . . . . . . . . . . . . . . . .
471
About the Px Editor popup menu items . . . . . . . . . . . . . . . . . . . . . . . .
471
Types of edit commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard toolbar icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
474
Slot Sheet toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
474
Px Editor toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
475
History editor toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
476
Types of view selector menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About console commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About console command usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
477
Types of console commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
477
Console commands optional flags . . . . . . . . . . . . . . . . . . . . . . . . . . . .
478
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
xvii
Contents
xviii
Published: June 24, 2005
Niagara
AX
NiagaraAX User Guide
Preface
Copyright and Trademarks
Copyright © 2005 Tridium, Inc.
All rights reserved.
Tridium, Inc. 3951 Westerre Parkway, Suite 350, Richmond, Virginia 23233 U.S.A.
NiagaraAX User Guide
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.
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.
The confidential information contained in this document is provided solely for use by Tridium employees, licensees, and system 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 rights 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 contained herein. Information and specifications published here are current as of the date of this publication and are subject to change without notice.
The release and technology contained herein may be protected by one or 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-Conditioning 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. Mozilla and Firefox are trademarks of the Mozilla Foundation. Echelon, LON, LonMark, LonTalk, and LonWorks are registered trademarks of Echelon
Corporation. Tridium, JACE, Niagara Framework, NiagaraAX and Vykon are registered trademarks, and Workbench, Work-
PlaceAX, and AXSupervisor, are trademarks of Tridium Inc. All other product names and services mentioned in this publication that is known to be trademarks, registered trademarks, or service marks are the property of their respective owners.The software described herein is furnished under a license agreement and may be used only in accordance with the terms of the agreement.
Preface
Document Change Log
Updates (changes/additions) to this NiagaraAX User Guide document are listed below.
• Draft: May 25, 2005 (Initial change log)
section “About point actions” on page 54 was expanded to cover the
, and
“Modifying default actions” . Various minor changes
were also made in other Data and Control Model sections.
section was reorganized and updated. Additional information added in the fol-
lowing sections: About alarm extension properties ,
About alarm extension manager ,
About alarm database maintenance
, About the lineprinter recipient . The
section
was added. Various minor changes were also made in other About alarms sections.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
xix
Preface
• Draft: June 1 2005
section had various minor changes after a technical review, including
many updated screen captures. The section “Types of status flags” on page 70 shows default sta-
tus colors, in addition to describing them.
“Types of alarm service views” section edited to add property sheet view–in order to include
description of “capacity” property. “About alarm class mapping”
section added. Updated
“About alarm database maintenance” section updated to reflect new database editing option. Corrected
description of “capacity in
“About the history summary view” section.
• Draft: June 6 2005
Provided more details about using the alarm class mapper in
.
Updated alarm console and alarm portal screens in
“Workbench options” section. Added,
removed and updated information in the
section.
• Draft: June 8 2005
, “Components in baja module” ,
, “Components in history module”
. .
• Draft: June 15 2005
.
• Published: June 24 2005
Added Copyright and Trademarks section to preface. Made minor changes in the “Component
sections, especially for the BackupService
xx
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
Well designed
About NiagaraAX Framework
Software frameworks provide a platform to allow businesses to more easily build their end-product offerings. Tridium’s patented Niagara Framework
®
is targeted at solving the challenges associated with managing diverse smart devices, unifying their data, and connecting them to enterprise applications. Examples of smart devices include: monitoring and control systems, sensors, metering systems, and embedded controls on packaged equipment systems.
framework, n. something composed of parts fitted together and united; a structural frame; a basic structure (as of ideas); in object-oriented programming, a reusable basic design structure, consisting of abstract and concrete classes, that assists in building applications.
Niagara Framework, n. a universal software infrastructure that allows companies to build custom, web-enabled applications for accessing, automating, and controlling smart devices in real time over the Internet.
NiagaraAX is the third generation of Tridium's Niagara Framework. This Java–based software framework provides an infrastructure to enable systems integrators and developers to build device–to– enterprise solutions, and Internet–enabled control and monitoring products. The Framework integrates diverse systems and devices (regardless of manufacturer or communication protocol) into a unified platform that can be easily managed in real time over the Internet (or intranet) using a standard web browser. The Framework also includes a comprehensive toolset that enables non-programmers to build rich applications in a drag-and-drop environment.
NiagaraAX is fully scalable, meaning that it can be run on platforms spanning the range from small, embedded devices to enterprise class servers. Niagara is being successfully applied in energy–services, building–automation, industrial–automation and M2M applications today.
Well designed
The Niagara Framework addresses the challenges of automation, control and device to enterprise connectivity of real time systems. NiagaraAX, and its derivative products, offer compelling value to both end users and partners. For OEM and reseller partners, the Niagara Framework solves several key challenges present in all control-related industries:
• High development costs associated with the foundation or infrastructure layer of software that communicates with devices and manipulates the data from them.
• The need to transform information from real-time control processes into a homogeneous structure enabling advanced product and service applications.
• Integration of legacy systems to enable companies to easily migrate their existing customers to new technologies and product offerings.
Partners who adopt the Niagara Framework as their infrastructure eliminate substantial engineering effort and are able to focus on their core competencies of application development and marketing.
These companies gain competitive advantage in their markets from lower development costs and quicker time-to-market for their specific products, applications and value-add services.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
1
The Niagara Framework solution
Chapter 1 — About NiagaraAX Framework
About control systems integration
End users of Niagara benefit from:
• Being able to preserve existing investments in control and monitoring devices as they move to new, standards-based technologies.
• Being able to access and control all of their diverse systems through a standard web browser.
• Combining information from different systems to support better overall management of their enterprise assets.
• Being able to specify interoperable systems and applications from multiple vendors, thereby reducing the potential for vendor lock-in.
Niagara is designed to address the following specific technical challenges:
• Platform independence - NiagaraAX works with a wide variety of operating systems and hardware platforms.
Unification of diverse systems - NiagaraAX integrates heterogeneous systems, protocols, and fieldbuses into normalized components.
Distributed architecture - NiagaraAX supports a highly distributed architecture. It successfully combines Internet/IT technology with the services necessary to implement real-time, peer-to-peer automation applications.
• Programming for non-programmers - NiagaraAX provides an environment and comprehensive toolset to enable domain experts to create sophisticated applications without writing code.
• Extensibility - NiagaraAX provides an extensible component model and rich library of open APIs to enable programmers to extend and enhance the Framework and build their own unique applications and products
• Support for embedded systems - NiagaraAX can be embedded in small low cost devices
The Niagara Framework solution
The following section describes how the Niagara framework addresses these challenges:
•
About control systems integration
•
•
About common networking and Internet protocols
•
About programming for non-programmers
•
About embedded systems capabilities
•
About distributed systems capabilities
•
About component software design
About control systems integration
Using the Niagara Framework, control systems integration means:
1. connecting devices on a common communications media
2. modeling those devices in software
3. programming applications to use the information in those devices
Before a device, such as a chiller, VAV box, or temperature sensor, can be used, information from
2
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
The Niagara Framework solution About Java those devices must be pulled into the Niagara software.
Niagara then models those devices and their data types in software through the common object model. This usually entails simplifying the device’s data types to make them easier to manipulate and control through the software.
The Niagara common object model is then used to build applications, with the goal being to provide non-programmers a means to program the system easily without developing raw code. The Niagara common object model is similar to a programming language in that there are a few key concepts that are used, but the real power is in the reusable libraries of applications and collections of objects that are available. Once you understand the key concepts and you can put them to work, you can use Niagara objects to build control system solutions quickly and efficiently.
The Niagara common object model, shown in
, allows the Niagara Framework to:
• provide two-way communication between devices and the Internet
• send real-time device information across the Internet
• control devices in real-time across the Internet.
Figure 1 Niagara common object model
About Java
All of the Niagara software is written in Java, which means that it is platform independent. Prior to
Java, most software was written and compiled for a particular machine or operating system. If that software needs to run on some other processor, the program has to be compiled again. Java, on the other hand, compiles once. NiagaraAX software runs on embedded JACE controllers using the QNX operating system and the IBM J9 Java Virtual Machine (JVM), and runs on Microsoft Windows desktop operating system platforms, as well as Linux and Solaris using the HotSpot JVM.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
3
The Niagara Framework solution
Chapter 1 — About NiagaraAX Framework
About common networking and Internet protocols
About Virtual Machines
It is possible to compile code once and run it on any platform due to a layer of software that exists between the machine and the software called the Java virtual machine (JVM). The Niagara framework uses the Java VM as a common runtime environment across various operating systems and hardware platforms. The core framework scales from small embedded controllers to high end servers.
The framework runtime is targeted for J2ME compliant VMs. The user interface toolkit and graphical programming tools are targeted for J2SE 1.4 VMs.
There are a number of different virtual machines for different platforms on which the NRE is running, but the NRE itself, and all of its modules, are the same regardless of platform. The VM is responsible for defining how the software works with a given set of hardware-how it talks to a lonWorks adapter, how it talks to the communications port, how it interacts with the operating system, among other tasks.
About common networking and Internet protocols
Niagara is designed from the ground up to assume that there will never be any one “standard” network protocol, distributed architecture, or fieldbus. Niagara's design goal is to integrate cleanly with all networks and protocols. The Niagara Framework standardizes what's inside the box, not what the box talks to.
The Niagara software suite implements a highly efficient adaptation of the JavaBean component software model and Internet technologies to provide true interoperability across a wide range of automation products. The Niagara object model can be used to integrate a wide range of physical devices, controllers, and primitive control applications including lonMark profiles, BACnet objects, and legacy control points. The architecture supports future enhancements by allowing legacy systems to be brought forward, where they can readily adopt new standards, solutions, and applications.
Enterprise-level software standards include Transmission Control Protocol/Internet Protocol (TCP/
IP), eXtensible Markup Language (XML), Hyper Text Transfer Protocol (HTTP), and others. These standards provide the foundation on which to build solutions that allow information to be shared between the control system and the enterprise information system.
About programming for non-programmers
Most features in the Niagara Framework are designed for dual use (for programmers as well as nonprogrammers). These features are designed around a set of Java APIs to be accessed by developers writing Java code. At the same time, most features are also designed to be used through high level graphical programming and configuration tools. This vastly increases the number of users capable of building applications on the Niagara platform.
4
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
The Niagara Framework solution
About embedded systems capabilities
About embedded systems capabilities
NiagaraAX is one of the only software stacks designed to run across the entire range of processors from small embedded devices to server class machines. Niagara is targeted for embedded systems capable of running a Java VM. This excludes some very low-end devices that lack 32-bit processors or have only several megabytes of RAM, but opens up a wide range of processor platforms.
To speed time to market for partners designing smart devices, Tridium has developed a reference design processor core. Known as the Niagara Processor Module (NPM), this platform can be licensed from Tridium and makes it possible to quickly develop NiagaraAX-based products.
About distributed systems capabilities
The framework is designed to provide scalability to highly distributed systems composed of tens of thousands of nodes running the Niagara Framework software. Systems of this size span a wide range of network topologies and usually communicate over unreliable Internet connections. Niagara is designed to provide an infrastructure for managing systems of this scale.
About component software design
Niagara uses an architecture centered around the concept of “Component Oriented Development.” A
new applications. A component–centric architecture solves many problems in Niagara:
• Data normalization
Components provide a model used to normalize the data and features of different types of protocols and networks so that they can be integrated seamlessly.
• Graphic development tools
Applications can be assembled with components using graphical tools in the Niagara Workbench.
This allows new applications to be built without requiring a Java developer.
• Application visibility
Components provide unsurpassed visibility into applications. Since components are self-describing, it is very easy for tools to look at how an application is assembled, configured, and to determine what is occurring at any point in time. This provides great value in debugging and maintaining Niagara applications.
• Software reuse
Components enable software reuse. NiagaraAX supports custom development and extension of the framework. Niagara components are extensible and go beyond data and protocols to unify the entire development environment.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
5
The Niagara Framework solution
About Niagara software architecture
Chapter 1 — About NiagaraAX Framework
About Niagara software architecture
the host platform, either a JACE controller or a PC. The next layer is the Java virtual machine (JVM).
The JVM provides a layer between the hardware and its operating system and the Niagara software, known as the Niagara run-time environment (NRE). On top of the NRE are the Niagara modules.
Figure 2 NiagaraAX software architecture
NiagaraAX software subsystems are illustrated in Figure 3 and the software processes and protocols
Figure 3 NiagaraAX major software subsystems
6
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About Baja
Figure 4 NiagaraAX software processes and protocols
About Niagara software architecture
About Baja
The core framework built by Tridium is designed to be published as an open standard. This standard is being developed through Sun's Java Community Process as JSR 60. This JSR is still an ongoing effort, but it is important to understand the distinction between Baja and Niagara.
Fundamentally Baja is an open specification and the Niagara Framework is an implementation of that specification. As a specification, Baja is not a set of software, but rather purely a set of documentation.
The Baja specification will include:
• Standards for how Baja software modules are packaged
• XML schema for the component model;
• The component model and its APIs
• Historical database components and APIs
• Alarming components and APIs
• Control logic components and APIs
• Scheduling components and APIs
• BACnet driver components and APIs
• lonWorks driver components and APIs
Over time many more specifications for features will be added to Baja. But what is important to remember is that Baja is only a specification. Niagara is an implementation of that specification. Furthermore you will find a vast number of features in Niagara, that are not included under the Baja umbrella. In this respect Niagara provides a superset of the Baja features.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
7
About Niagara building blocks
Chapter 1 — About NiagaraAX Framework
About APIs
About APIs
(Application Programming Interface) defines how software engineers access the capabilities
of software like the Niagara Framework. Workbench is the Niagara API — and using the Niagara
Workbench, you can create and edit the control logic for your job site.
Many features found in Niagara are exposed through a set of Java APIs. In the Java world, APIs are grouped together into packages, which are scoped using DNS domain names. Software developed through the Java Community Process is usually scoped by packages starting with “java” or “javax.” It is important to understand the two types of APIs related to the Niagara framework:
•
•
javax.baja
The APIs developed for Baja (see
“About Baja” on page 7 for more about Baja) are all grouped under
javax.baja. These are APIs that will be part of the open Baja specification and may be implemented by vendors other than Tridium. Using these APIs guarantees a measure of vendor neutrality and backward compatibility.
com.tridium
Software developed by Tridium which is proprietary and outside of the Baja specification is grouped under the com.tridium packages. The com.tridium packages contain code specific to how Niagara implements the Baja APIs. The com.tridium code may or may not be documented. If com.tridium
APIs are publicly documented then Tridium encourages developers to use them, but does not guarantee backward compatibility. Undocumented com.tridium APIs should never be used by developers.
Note: Tridium has developed some APIs under javax.baja even though they are not currently part of the Baja specification. These are APIs that Tridium feels may eventually be published through
Baja, but are currently in a development stage.
About Niagara building blocks
This section describes some of the fundamental building blocks of the Niagara framework. It is important to understand these concepts and associated terminology in order to fully benefit from the use of the NiagaraAX Workbench. Concepts discussed in this section include the following:
• Modules
Modules are the most basic unit of software in NiagaraAX. For more details about modules, see
• Components
Components are the primary building blocks of the NiagaraAX framework. For more details about components, see
“About components” on page 12.
8
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About modules About module characteristics
• px
For more details about px., see
“About presentation xml (px)” on page 18.
• stations
For more details about stations., see
• ORDs
For more details about ORDs, see “About ORDs” on page 21.
• Views
For more details about views, see “About views” on page 22.
About modules
Modules are the smallest units of software in the Niagara architecture.
Major releases of the Niagara software are distributed along with a set of release modules, but as new modules are made available for that release of Niagara, they may be distributed as independent revisions within that release.
shows a partial list of modules, as displayed in the nav side bar pane.
Figure 5 Module listing in the nav side bar tree
Note: Don’t confuse modules with component
s. Components are used to build Niagara implementa-
The following sections describe module characteristics and benefits.
About module characteristics
All modules:
• are composed of a single Java ARchive (JAR) file compliant with PKZIP compression
• contain an XML manifest
• are independently versioned and deployable
• state their dependencies on other modules and their versions
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
9
About modules
Chapter 1 — About NiagaraAX Framework
About module characteristics
About jar files
JAR files are the standard mechanism for distributing Java modules. JAR stands for “Java archive.” A
JAR file (.jar) is basically a compressed package whose components can be viewed with WinZip or other archive viewing tool. Do not attempt to unzip a JAR file—it will not work. JAR files are the add-ins that are plugged into the software to give additional functionality. Inside the JAR file are the compressed software; its documentation; in some cases, examples or pre-canned applications; and libraries.
Some modules, such as the lonWorks module, are distributed as multiple JAR files because there are so many different lonWorks devices. The core protocol is packaged in a JAR file called lonWorks.jar.
There are individual JAR files for each LON device manufacturer (for example, lon_mfgName.jar).
Every JAR file or module is versioned independently.
About module versions
Niagara’s versioning system allows you to check to make sure that you have the latest available module for your system. Versions are specified as a series of whole numbers separated by a period, for example "1.0.42". To understand which version of a module is more recent, simply observe the module version number. For example, 2.3.42 is later than 2.3.35 because 2.3.42 > 2.3.35.
shows modules listed, by name, with the version number and file name, as viewed in the
Workbench software manager.
Figure 6 Module descriptions viewed in the software manager
Niagara versioning uses the following set of conventions:
• Versions are specified using a base four-part version with optional patch versions.
• The first number specifies the specification revision. This number starts at one and is incremented each time the specification of the module is incremented. It is used with Baja modules to track the
Baja specification version.
• The next two numbers specify a major Niagara release.
• The fourth number specifies a build number. A build number starts at zero for each major release and increments each time all the software’s modules are built.
• Additional numbers may be specified for code changes made off a branch of a specific build.
These are usually minor changes and bug fixes.
Every module has two versions. The first is the "bajaVersion" which maps the module to a Baja specification version. If the module is not published under the Baja process then this value is "0". Secondly every module declares a "vendor" name and "vendorVersion". The vendor name is a case insensitive identifier for the company who developed the module and the vendorVersion identifies the vendor's specific version of that module.
Tridium's vendorVersions are formatted as "major.minor.build[.patch]:
10
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About modules About module benefits
• Major and minor declare a feature release such as 3.0.
• The third number specifies a build number. A build number starts at zero for each feature release and increments each time all the softwares modules are built.
• Addition numbers may be specified for code changes made off a branch of a specific build. These are usually patch builds for minor changes and bug fixes.
So the vendorVersion "3.0.22" represents a module of build 22 in Niagara release 3.0. The vendorVersion "3.0.45.2" is the second patch of build 45 in release 3.0.
About module directory structure
Every module is managed in its own directory structure.
Figure 7 shows an example of a directory for
the alarm module.
Figure 7 Module directory structure
All of the source code that is used to build the module’s jar file is located under the "src" directory.
During the build process the "libJar" directory is used to build up the image, which will be zipped up for the module's jar file.
About module benefits
Modular software development provides several benefits, including the following:
• Improves tracking deployment and versioning
Modular development assists in tracking the deployment and versioning of Niagara features and releases. For example, if a new driver is available to be added to NiagaraAX Framework, it can be packaged, delivered, and added in as a single module or with multiple modules, using the NiagaraAX software manager, as shown in
Figure 8 . Refer to the NiagaraAX Platform Guide section
“Software Manager” for more information about managing modules.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
11
About components
Figure 8 Software manager view
Chapter 1 — About NiagaraAX Framework
About module benefits
• Requires less space on JACE
Niagara’s modular development allows you to save space on your JACE by only installing the modules that you need and choose for that JACE.
• Requires less space on the workstation
When you install NiagaraAX, you can choose the modules that you want to install with your application and omit any modules that you do not need. Later, if want to add additional modules
you can do so with the Software Manager (as shown in Figure 8 ).
• Create new modules
Software developers can use the tools in NiagaraAX to create new modules and deploy them using the New Module Wizard, as shown in
.
Refer to
“New module wizard” on page 332 for more details about the New Module Wizard.
Figure 9 New module wizard
About components
A component is the primary building block that you use to engineer an application using NiagaraAX
12
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About components About slots
Workbench. As described in the “About component software design” on page 5, components provide
many advantages for the application developer.
Components differ from modules in that components compose a Niagara implementation whereas modules compose the Niagara software itself.
The following sections describe characteristics of components:
•
•
•
About slots
Niagara components are defined as a collection of “slots.” You can see all the slots that make up a
component by viewing the “slot sheet” as shown in Figure 10. Slots have the following types of
attributes:
•
•
•
•
•
Figure 10 Slot sheet for a single component
Slot type
There are three types of slots:
• Property
Property slots represent a storage location of another Niagara object.
• Action
An action is a slot that specifies behavior that may be invoked either through a user command or by an event. Actions provide the capability to provide direction to components. They may be issued manually by the operator or automatically through links. Actions can be issued by right– clicking on the component.
• Topic
Topics represent the subject of an event. Topics contain neither a storage location, nor a behavior.
Rather a topic serves as a place holder for a event source.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
13
About components
Chapter 1 — About NiagaraAX Framework
About master/slave components
Slot name
Every slot is identified by a name that is unique within its Type. Slot names must contain ASCII letters or numbers.
Slot definition
Slots are either frozen or dynamic. A frozen slot is defined at compile time within a Type's Java class.
That means that frozen slots are consistent across all instances of a specified Type – they don’t change. Dynamic slots may be added, removed, renamed, and reordered during runtime – they can change. The power of the Niagara Framework is in providing a consistent model for both frozen
(compile time) slots and dynamic (runtime) slots.
Flags
Slots have flags that allow modification of an object’s presentation or behavior. For example, “read– only”, “operator allowed”, and “hidden”, are some of the slot flags that may be used to restrict the presentation or behavior of an object.
Facets
Facets contain meta data – or additional data about an object. For example, “units of measurement” is a type of facet. Facets may be viewed in the slot sheet and edited from a component property sheet, as shown in
Figure 11 Editing facets from the property sheet
About master/slave components
Master components can be defined so that persistent properties are copied to slave components when they are changed. This allows you to change a property in one component that automatically updates the components that are linked to it as slaves. In this way a master component can update slave com-
14
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About components About point components ponents in all the other stations in a system.
About point components
In any NiagaraAX station, all real-time data is normalized within the station database as points, a spe-
cial group of components. Figure 12 shows several types of control points, as listed in the control
module palette in Workbench.
Figure 12 Point types
Each type of point may be used for different purposes in Workbench. When you engineer a job you may want to name a point, as shown in
(a NumericWritable point named CondSetpoint).
Points may be named and renamed but they retain their initial point type characteristics and their characteristic icon color.
Figure 13 Numeric writable point named
Points serve as a type of shell in NiagaraAX, to which you may add point extensions. These extensions allow you to add only those functions that you need and therby limit your point properties to just those that are necessary for your current application.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
15
About presentation
Figure 14 Adding point extensions
Chapter 1 — About NiagaraAX Framework
About palettes
About palettes
The palette provides a hierarchical view of available components. You may copy a component from the palette and paste it where you need it — on a wire sheet, property sheet, Px View, or in the palette
About presentation
The NiagaraAX framework provides a powerful presentation architecture based on XML and the
Niagara component model.
Presentation is a term that is used to describe how Niagara provides visualization of information across different types of media. The terms information, visualization, and media may comprise the following:
• information
• real–time data
16
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About presentation
• historical data
• configuration data
• alarm data
• scheduling data
• graphical data
• textual data
• visualization
• bitmap and vector graphics
• text documents
• tables
• charts
• input controls (text fields, check boxes, trees)
• media
• desktop web browsers (HTML, CSS, JavaScript)
• workbench (Niagara stack)
• printed pages
• svg
• handhelds
• cell phones
About presentation modules
About presentation modules
Niagara’s presentation architecture is based on many modules and their associated public APIs:
• baja
The baja module defines the core component model upon which Niagara subsystems are built.
This document describes enhancements to the baja component model which will be used by the presentation stack.
• gx
The gx module provides an API for drawing 2D graphics to a device. The gx module deals with drawing primitives: color, strokes, gradients, vector geometries (line, rectangle, ellipse, paths), bitmap images, fonts, and transforms.
• bajaui
The bajaui module provides the widget toolkit. Widgets are the basis for graphical composition, layout, user input, and data binding. The bajaui module builds upon gx to paint the widgets.
The PDF implementation of the gx APIs.
• HTML
The HTML rendering and data binding engine.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
17
About presentation
Chapter 1 — About NiagaraAX Framework
About presentation xml (px)
About presentation xml (px)
An XML file format is used to define a Niagara presentation. This file format is called “px” for presentation XML and the term “px” is commonly used to describe the Niagara presentation architecture.
Presentation is a term that describes how Niagara visualizes information (text, graphics, alarms, and so on) across heterogeneous media – such as: Workbench, desktop browsers, handheld devices, and so on. Niagara uses “presentation xml” (px) to accomplish this.
shows an example of a Px file in the Text Editor (px source file), the Px Editor view, and as displayed in the Px Viewer.
Figure 15 Px file in Text Editor, Px Editor, and Px Viewer
About presentation design philosophy
The presentation architecture is based on the following design principles:
• Component model
The core philosophy of every subsystem in Niagara is to build atop the component model. The presentation architecture is no exception. The design embraces a pure component model solution.
The component model is used for the normalized representation of presentation - the “document object model” (DOM) of a Niagara presentation is always a BComponent tree.
• Unified visualization
Presentations include a unified approach to representing graphics, text, and input controls all within a single component model. This allows all visualizations to share a common file format as well as a rendering, layout, and input API.
• Unified media
The design goal of px is to build a single presentation that can be used across multiple media. For example, given a px file, it can be automatically rendered using the workbench, as an HTML web
18
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About presentation About presentation media page, or as a PDF file. All presentations are stored in the normalized component model as px files.
About presentation media
There are four primary target medias that NiagaraAX supports.
• Workbench
The Niagara stack must be available to take full advantage of the presentation architecture. The desktop version of Workbench provides a stand alone application that can render Niagara presentations with their full power. With the WbProfile feature, new custom applications can easily be built using Workbench framework and its presentation engine.
• Workbench applet
Workbench applet allows the full Niagara stack to be downloaded to a client machine using a web browser with the Java plug–in. Once loaded to the client, Workbench may be run as an applet within an HTML page. In this scenario, the presentation engine will be available with the full feature set. The WbProfile feature may be used to customize how Workbench is decorated inside the
HTML page.
Adobe's PDF format is the standard way to export a presentation to be printed to paper. PDF provides explicit control for how a presentation is rendered on paper in various sizes. It is also a convenient file format for access via HTTP or email. The presentation architecture includes an engine for generating PDF files from px files.
• HTML
For the casual user where installing the Java plug–in or downloading Workbench is impractical,
Niagara supports an engine for generating plain HTML pages from Px. A simple set of HTML,
CSS, and JavaScript provide a web interface using common standards. This interface may also be used to support handheld devices and cell phones. Designers are limited to a subset of widgets when creating HTML presentations (the Px tools provide this support).
Refer to “About Px target media” on page 238 for information about presentation media technologies.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
19
About stations
Figure 16 Presentation media options
Chapter 1 — About NiagaraAX Framework
About presentation media
About stations
A station is the main unit of server processing in the Niagara architecture.
• A station database is defined by a single .bog file, for example:
"file:!stations/{name}/config.bog"
• Stations are booted from their config.bog file into a single Virtual Machine (VM), or process, on the host machine.
• There is usually a one–to–one correspondence between stations and host machines (Supervisors or Jaces). However it is possible to run two stations on the same machine if they are configured to use different IP ports
A station runs the components of the Niagara Framework and provides the access for client browsers to view and control these components. The primary parts of a station include components and services. It is the combination of a database, a web server, and a control engine. The station either runs on a Web Supervisor PC or a JACE controller.
Figure 17 Station in nav tree
20
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About ORDs About BOG files
A system can be a single station or multiple stations depending on the size of the project and it is
About BOG files
(baja object graph) contains Niagara components. It can be a complete database or any collection of components. A bog file is a special file that describes the components in a database. All views can be used on components in a bog file just as if they were in a station.
Figure 18 Sample bog file and nav tree presentation
About ORDs
An ORD is an "Object Resolution Descriptor". The ORD is the Niagara universal identification system and is used throughout the Niagara framework. The ORD unifies and standardizes access to all information. It is designed to combine different naming systems into a single string and has the advantage of being parsable by a host of public APIs.
An ORD is composed of one or more queries. Each query has a scheme that identifies how to parse and resolve the query into a BObject. ORDs may be displayed visually, as with the Open Ord locator
or they may be entered in a text field, as shown in the Open ORD dialog box (see Figure 19 ).
Figure 19 Open Ord and graphic locator system
ORDs can be relative or absolute. An absolute ORD usually takes the general format of “host|session|space”. The host query identifies a machine – usually by an IP address such as "ip:hostname".
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
21
About views
Chapter 1 — About NiagaraAX Framework
About BOG files
The session is used to identify a protocol being used to communicate with the host.
For example "fox:" indicates a fox session to the host. The space query is used to identify a particular type of object. Common spaces are "module:", "file:", "station:", "view:", “spy:”, or "history:".
The local VM is a special case identified by "local:" which always resolves to BLocal-
Host.INSTANCE. The local host is both a host and a session (since no communication protocols are required for access).
Both a slot path and a
can name components within a ComponentSpace. So the ORD for a component usually involves both a space query and a path/handle.
Examples of ORDs:
• ip:somehost|fox:|station:|slot:/MyService
• ip:somehost|fox:|station:|h:/42
• ip:somehost|fox:|file:/C:/dir/file.txt
• local:|file:!lib/log.properties
• local:|module://icons/x16/cloud.png
• local:|spy:/
In Niagara you may view the complete list of installed ord schemes at "spy:/sysManagers/registry-
Manager/ordSchemes" (“local:|fox:|spy:/sysManagers/registryManager/ordSchemes”).
About views
There are many ways to visualize your system and its components. A “view” is a “visualization” of a component. One way to view a component is directly in the side bar nav tree. In addition, you can right-click on an item and select one of its views to display in the view pane. You can see many different views of components. For example, a component that appears in the nav side bar tree may have a wire sheet view, a property sheet view, and a slot sheet view, that all display in the view pane as shown in
. Each component has a default view that appears whenever you activate a component (double-clicking, for example) without specifying a particular view.
Figure 20 Views
See “About the view pane” on page 36 for more information on the view pane.
Refer to
for a comprehensive list of views.
22
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 1 — About NiagaraAX Framework
About lexicons About BOG files
About lexicons
NiagaraAX provides non-English language support by use of lexicons. Lexicons are identified by
Java locale codes, such as “fr” (French) or “de” (German). When installing NiagaraAX on your PC, an installation step asks you to select “language packages”—these are lexicons. Typically, you install only those you might need, even though a “Select All” option is available.
Each lexicon is a folder that contains a collection of lexicon files (moduleName.lexicon). Lexicon files are text files that map various entity “keys” (such as interface names or error and status values) to localized language characters. Often, mapped characters use special encoding.
Note: Factory-supplied lexicons on a NiagaraAX installation CD typically require review and editing before they can be used on an actual job. If needed, you can install lexicons from a NiagaraAX CD to your Workbench PC by simply copying them from the CD’s lexicon folder into a
“lexicon” directory created under your Niagara release directory.
Lexicon files installed on your PC can be accessed and modified using a simple text editor. However, you typically use the Workbench’s lexicon editor (Tools > Lexicon Editor). The lexicon editor not only provides edit features, but also shows the default (English) value for each line entry.
In addition, the editor provides a “Lexicon Report” view, useful to see various statuses about a lexi-
con and its contained files. For more details, see “Lexicon editor” on page 330. Once reviewed and
edited, you typically install any needed lexicon into all JACE platforms. For more details, see “Lexicon Installer” on page 21.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
23
About lexicons
Chapter 1 — About NiagaraAX Framework
About BOG files
24
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
About Workbench
Tour of the Workbench GUI
Tour of the Workbench GUI
, you will see the Workbench screen, as shown in Figure 1 .
Figure 1 Niagara AX Workbench
Menu Bar
Tool Bar
Locator Bar
View Selector
Side Bar Pane
View Pane
Console
The primary window of the Workbench GUI is divided into three main areas:
• Side bar pane
Top-left area displays one or more side bars that you may choose from the Windows menu. For
details, see “About the side bar panes” on page 26.
• View pane
• Console
Bottom area displays a command line that allows you to issue certain commands directly to the system. For details, see
“About the console” on page 37.
About Workbench window controls
The Workbench window provides typical Windows-type controls plus other features unique to Nia-
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
25
Chapter 2 — About Workbench
Tour of the Workbench GUI
Figure 2 Windows controls
Title bar
Status bar
Scroll bars and borders
You may create additional windows after starting Workbench—all have these basic features:
• Title bar
Has standard Windows title bar features, including windows name and icons to minimize, maximize, and close. Double-click the title bar to toggle between maximized and a sizable window.
• Borders
As needed, drag any outside border to resize the entire window. Drag the inside border between the side bar and view areas, or (if shown) the console area to change their relative sizes.
• Scroll bars
Scroll bars appear in window areas when some content portions are not visible. They are along the right and/or bottom portions of a window area (side bar, view, or console).
Simply drag a scroll slider (highlighted area) to scroll quickly. Or, click an ending scroll arrow to move in small increments.
• Status bar
At the bottom left of the Workbench window is a status bar.
The status bar displays meanings of toolbar buttons. When working in a wire sheet view, other details are revealed in the status line.
About the side bar panes
Side bar panes are normally visible only if a side bar is open. When you close all side bars, the side bar pane will collapse and the view pane and console pane (if open) will expand to fill the window.
Two types of side bar panes are:
• Primary side bar pane
The primary side bar pane is the first area on the left, below the locator bar, as shown in Figure 3
.
• Px Editor side bar pane
This side bar pane appears on the right side of Workbench and is only available when the Px Editor is active.
26
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Figure 3 Side bar pane
Tour of the Workbench GUI
You use a popup menu to perform all operations that are available from inside the side bars (such as cutting or pasting). You use the title bar to open, close, and resize the side bars.
•
For more information about the side bar title bar, see “About the side bar title bar” on page 27.
•
For more information about types of side bars see “Types of side bars” on page 28.
About side bars
All side bars display in the side bar pane and have some common features, such as the side bar title bar. The following sections describe characteristics of each type of side bar:
•
•
About the side bar title bar
bar to vertically resize the side bar or you can click on a minimized side bar to restore it to the previous size.
Figure 4 Side bar title bar
Title
Close
Minimize/Maximize
In addition, all side bars have the following controls:
• Close menu
Drop down control used to close the side bar pane.
• Pane title
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
27
Chapter 2 — About Workbench
Tour of the Workbench GUI
Icon and text that identifies the side bar.
• Maximize button
When more than one side bar is open, this button appears on the right side of any non-maximized side bar. Clicking on the maximize button will expand the side bar to fill the side bar pane and the restore button will change to the maximize button.
• Restore button
If the side bar pane is at maximum size, the restore button appears on the top right corner of the title bar. Clicking on this button will restore the side bar pane to its previous size and the maximize button will change to the restore button.
To find out more about specific side bar panes and their controls see
Types of side bars
The following side bars may be displayed in the side bar pane:
• Bookmarks side bar
Displays a list of bookmarks. For details, see
“About the bookmark side bar” on page 28.
• Help side bar
• Navigator side bar
Provides a tree view of the system. For details, see “About the nav side bar” on page 30. For more
information about the nav side bar, see “Types of nodes in the nav side bar tree” on page 31, and
“About the nav side bar toolbar” on page 32.
• Palette side bar
Provides a tree view of available components. For details, see
“About the palette side bar” on page 33 and “About the palette side bar toolbar” on page 33.
• Jobs side bar
Provides a tree view of available components. For details, see
“About the jobs side bar” on page 34.
• Bound ords side bar
• Widget tree side bar
• Properties side bar
Provides a listing of all properties for a component that is selected in the Px Editor. For details,
see “About the properties side bar” on page 35.
About the bookmark side bar
When you open the bookmark side bar, it appears in the side bar pane, as shown in Figure 5 .
28
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Figure 5 Bookmark side bar
Tour of the Workbench GUI
From the bookmark side bar, you can double click on bookmark nodes or use popup menus to perform all operations that are available from the side bar (for example, go directly to a bookmarked location, manage bookmarks, edit bookmarks, and more). The quick access provided here is very helpful for changing screens without having to go through multiple selections using other menus or submenus.
For more details about the bookmark side bar, refer to the following:
•
•
For details about managing bookmarks, see “To manage bookmarks” on page 342
•
For details about editing bookmarks, see “To edit a bookmark” on page 343
About the help side bar
When you open the help side bar, it appears in the side bar pane, as shown in Figure 6 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
29
Tour of the Workbench GUI
Figure 6 Help side bar
Chapter 2 — About Workbench
The help side bar has three tabs that you may select by clicking on the tab. The three help tabs are listed and briefly described, as follows:
• Table of Contents
Contains a tree view of help topics, listed in alphabetical order by topic.
• API
Contains a tree view of help topics, listed in alphabetical order by module
.
• Search
About the nav side bar
When you open the nav side bar, it appears in the side bar pane, as shown in Figure 7 . The nav side
bar contains the tree view that provides a hierarchical view of the whole system. From the nav side bar, you can double click on nodes in the nav tree or use popup menus to perform all operations that are available from the nav side bar (for example, connect or disconnect to a station, refresh a tree node, and more). The expandable tree provided here is very useful for performing actions on nodes and for navigating through various screens and views in the Workbench. Items are displayed in the tree with an icon that represents the associated function or file type.
Items are displayed in the tree with a symbol based on type. If the item is a file, it will be based on file type. Refer to
“Types of nodes in the nav side bar tree” on page 31 for more details about file types.
Refer to
“About the nav side bar popup menu items” on page 470 for more details about the nav side
bar popup menu.
30
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Figure 7 Nav side bar
Tour of the Workbench GUI
At the highest level, the nav side bar tree may include the following (when working from a localhost):
• My Host (local system)
• My Modules
• Platform
• Stations (connected or disconnected)
Types of nodes in the nav side bar tree
The nav side bar tree may include the following types of nodes and their child nodes:
• Host node
Represents a physical computer (hardware) that the rest of the nodes (subnodes) reside on. For
• Module node
When expanded, displays a tree view of available modules, listed in alphabetical order by module.
For more details on modules, see “About modules” on page 9.
• File system node
Represents the top level of a tree view of the host file system. File system subnodes represent drives and locations on the host system. It is important to understand that the file system provides access to files that are outside of the station database.
• Station node
Represents a station (connected or disconnected). When expanded, the station node displays the station contents in a hierarchical tree. For more details on stations, see
• Platform
When expanded, displays a hierarchical view of the Niagara host platform. You can double-click on the platform node and sub-nodes, or use a right-click shortcut menu to perform all operations that are available on or under this node (connecting, disconnecting, refreshing, and more). For
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
31
Chapter 2 — About Workbench
Tour of the Workbench GUI details on the platform node and its subnodes, refer to “About a platform connection” in the Plat-
form Guide for more details.
• Station
When connected and expanded, displays a hierarchical view of the Niagara station. You can double-click on the station node and sub-nodes, or use a right-click shortcut menu to perform all operations that are available on or under this node (connecting, disconnecting, selecting views, and
more). For details on the station node, refer to “About stations” on page 20.
• Config node
When expanded, displays a tree view of the station contents or “configuration”.
The config node usually contains one or more of the following types of nodes:
• Component
When expanded, components (as containers) display a tree view of the sub-components that they contain. Various component types may be displayed either in containers or at the root of
the component node. For more details on components, see “About components” on page 12.
• Control
Control points may be displayed directly in the root of the Config node. For more information
about Control points, see “About point components” on page 15 and
“Data and Control Model” on page 51.
• Drivers
Provides a place to store driver modules (such as the Niagara Network, BACnet drivers, Modbus, and more). When expanded, displays a tree view of loaded driver modules. For more de-
tails about drivers, see “Driver architecture” on page 89.
• Services
Component for storing services, such as alarm service, history service, program service, and more.
About the nav side bar toolbar
In addition to the standard side bar title bar (see
“About the side bar title bar” on page 27 for more
details) the nav side bar has a toolbar, located just below the title bar as shown in
.
Figure 8 Nav side bar tool bar
New tree
Close tree
Drop-down selector
The nav side bar toolbar includes the following:
•
New tree
button
When clicked, creates a new tree in the nav side bar. When you have more than one tree node, you can select one to activate from the Drop-down tree selector.
•
Close tree
button
When clicked, closes the currently displayed palette.
32
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Tour of the Workbench GUI
•
Drop-down tree
selector
When palettes are open in the palette side bar, this selector allows you to choose which palette to display
About the palette side bar
When you open the palette side bar, it appears on the left side of the Workbench in the side bar pane,
as shown in Figure 9 . The palette side bar provides a place to open and view sets of modules. From
the palette side bar, you can open multiple palettes (displaying them one at a time), close palettes and view modules within palettes. You may also double-click or use popup menus to perform all operations that are available from the palette side bar (for example, copy modules, select a module view, refresh the tree node, and more). The expandable tree provided here allows you to perform actions on nodes within the palette and to navigate through the palette sub-directories. Items are displayed in the tree with an icon that represents an associated function or file type.
Figure 9 Palette side bar
For more details about the palette side bar, refer to the following:
• To find out how to use the palette side bar, see
“Using the palette side bar” on page 345.
• For details about adding palettes to the palette side bar, see
“To open a palette” on page 346
About the palette side bar toolbar
In addition to the standard side bar title bar (see
“About the side bar title bar” on page 27 for more
details) the palette side bar has a toolbar, located just below the title bar as shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
33
Chapter 2 — About Workbench
Tour of the Workbench GUI
Figure 10 Palette side bar tool bar
Open palette
Close palette
Drop-down palette selector
The palette toolbar includes the following:
•
Open palette
button
When clicked, opens the Open Palette dialog box. For more details about this dialog box, see
About the Open Palette dialog box in “Types of dialog boxes” on page 476. Refer to
“To open a palette” on page 346 for information about opening palettes.
•
Close palette
button
When clicked, closes the currently displayed palette.
•
Drop-down palette
selector
When palettes are open in the palette side bar, this selector allows you to choose which palette to display.
About the jobs side bar
The Jobs side bar shows all the current jobs in all the stations with which you have a connection. The current status of each job is shown: running, canceling, canceled, success, or failed. If the job is running then a progress bar displays estimated progress. For details about using the job side bar, refer to
“Using the jobs side bar” on page 345.
Figure 11 Jobs side bar
About the bound ords side bar
The bound ords side bar, in
Figure 12 , is available when the Px editor view is active. It displays a list-
ing of all the bound ords in the current Px view. Double click on any ord in the list to display the ord
34
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench in the ord editor dialog box.
Figure 12 Bound ords side bar
Tour of the Workbench GUI
About the widget tree side bar
ments, and so on) that are in the current Px view.
Figure 13 Widget tree side bar
Note: It is often easier to use the Widget Tree to select objects when you have a lot of objects on a view–especially when there are several layers of objects. When you select an object in the tree view it is selected in the Px view as well and displays the selection borders and handles.
About the properties side bar
The properties side bar, shown in
Figure 14 , is available when the Px editor view is active. It displays
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
35
Chapter 2 — About Workbench
Tour of the Workbench GUI a listing of all the properties that are in the currently selected object in the Px view. Double click on any object in the widget tree or in the in the Px viewer to display the properties dialog box (same information as the properties side bar).
Figure 14 Properties side bar
About the view pane
The View pane is the largest window area and is located on the right side, below the locator bar, as shown in
. Features of the view pane include tabbed views and a thumbnail view.
Figure 15 View pane
Multiple tabbed views may be added to the view pane by using the tab feature. You can add, close, and select tabs in the view window. The view area displays the currently selected view for the active tab. You can change the selected view by doing any of the following:
36
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Tour of the Workbench GUI
• double-click on an item in the nav palette tree
• select a view or action from the nav palette popup menu
• select a command from a menu or submenu
• select a command from the locator bar
• select a view from the view selector or from the view popup menu
The thumbnail view, when active, appears in the top right corner of the window to help you find your way around the wire sheet. For more details about the thumbnail view, refer to
For more details about the view pane, refer to
“Types of views” on page 476. For more details about
using tabs, refer to “Creating tabs in the view pane” on page 45.
About the console
The console, see
, is located along the bottom of the Workbench interface and may be alternatively hidden or shown by selecting Window > Hide Console or Window > Console from the menu bar.
Figure 16 Niagara AX console
The console has scroll bars on the right side and the window size may be adjusted by dragging the top border bar. The console provides you with access to a command line prompt without leaving the
Workbench environment. From the console you may type in commands directly, including the help command for additional help. The following lines are some console level commands, parameters, and options:
>wb -help usage: wb [options] <ord> parameters: ord initial ord to display options:
-profile:<type> workbench:WbProfile to use
-locale:<x> set the default locale (en_US)
-@<option> pass option to Java VM
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
37
Chapter 2 — About Workbench
Tour of the Workbench GUI
About the menu bar
The menu bar is the row of pulldown menus located along the very top of the Workbench GUI, as
shown in Figure 17 . You may use these menus to perform operations throughout the Workbench GUI.
Figure 17 Menu bar
For detailed information about the menus, refer to “Types of menu bar items” on page 460.
About the toolbar
The toolbar is the row of icons, just below the menu bar, as shown in Figure 18
. The toolbar provides menu choices for objects that appear in the view pane. Usually, toolbar icons provide single–click access to many of the most commonly used features of the Workbench.
38
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Figure 18 Toolbar
Tour of the Workbench GUI
In addition to the primary (always visible) toolbar, additional sets of toolbar icons are added to the toolbar when different views are active. For example, when the wiresheet view is active, the Delete
Links
icon is available. When an icon is dimmed, it is unavailable. For more information about specific toolbar icons, refer to
“Types of toolbar icons” on page 473.
About the locator bar
The locator bar is the area just below the toolbar that spans horizontally from the left edge of the
Workbench GUI to the view selector on the right side, as shown in Figure 19 .
Figure 19 Locator bar
The purpose of the locator bar is to provide a graphical navigation field for selecting and displaying
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
39
Chapter 2 — About Workbench
Tour of the Workbench GUI destination references. The locator serves two functions.
• First, it is automatically updated each time a new view is selected - so that it shows you the Ord of each view.
• Second, since the Ord is displayed in a graphical row of icons, you may click on any icon along that Ord or any child node from the Ord graphical dropdown menu.
Find the Open Ord command by selecting File > Open from the menu bar.
About the view selector
.
Figure 20 View selector
The view selector provides a context sensitive menu with commands that allow you to quickly display different views of the information that is currently in the view pane. The commands in the view selector differ, depending on the current view pane contents. For example, the view selector commands that are available when you are viewing the platform in the view pane are different from the commands that are available when you are displaying the driver manager view. For the list of com-
Types of popup menus
Workbench provides view–specific, or context–specific commands for editing components in many of the views. Following, is a list of the standard Workbench popup (right–click) menus.
• Nav side bar
40
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Tour of the Workbench GUI
For an overview of the nav side bar, refer to “About the nav side bar” on page 30.
• Wire sheet
For an overview of the popup menus in the wire sheet, refer to
“About the wire sheet popup menu” on page 42.
• Property sheet
For an overview of the popup menus in the property sheet, refer to
“About the property sheet popup menu” on page 42.
• Px Editor
About the nav side bar popup menus
The nav side bar menu is the popup menu that displays command options when you right–click on a component item in the nav side bar. The nav side bar popup menu is context-sensitive and displays items that relate to the object that is currently selected. For example, the popup menu for a station is
different from a popup menu for a folder or a point. Figure 21 shows a popup menu for a selected
node in the nav side bar.
Figure 21 Nav side bar popup menu
If you right-click in a blank area of the pane (not selecting any items any the tree), the nav side bar pane will display the Refresh Tree Node and Sync Tree commands. For descriptions of nav side bar popup menu items, refer to
“About the nav side bar popup menu items” on page 470.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
41
Chapter 2 — About Workbench
Tour of the Workbench GUI
About the wire sheet popup menu
shows the wire sheet popup menu with a wire sheet object selected. The menu displays different items depending on whether you right-click on an item or on a blank area of the wire sheet. For descriptions of wire sheet popup menu items, refer to
“About the wire sheet popup menu items” on page 471.
Figure 22 Wire sheet popup menu
For a description of the wire sheet, refer to
“wiresheet-WireSheet” on page 441.
About the property sheet popup menu
shows the property sheet popup menu. For descriptions of wire sheet popup menu items, refer to
“About the property sheet popup menu items” on page 471.
42
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Figure 23 Property sheet popup menu
Tour of the Workbench GUI
For a description of the property sheet refer to “workbench-PropertySheet” on page 448.
Px Editor popup menu
The Px Editor popup menu appears when you right-click on an object in the Px Editor view. The menu commands are context-sensitive and are dimmed or available, depending on the type of object that you select.
shows the Px Editor popup menu. For descriptions of the Px Editor popup menu items,
refer to “About the Px Editor popup menu items” on page 471.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
43
Customizing the Workbench environment
Figure 24 Px editor popup menu
Chapter 2 — About Workbench
For a description of the Px Editor view, refer to “workbench-WbPxView” on page 457.
Customizing the Workbench environment
You can customize your Workbench GUI as well as many of the settings in the Workbench environment. Some settings require an acknowledgement via the OK button on a dialog box, while others are invoked immediately and saved automatically on exit from Workbench. For example, when you exit
Workbench with four tabbed windows in your view pane, those same four windows will be displayed the next time you open Workbench.
You can customize the Workbench environment in the following ways.
Customizing the Workbench GUI
•
•
Creating tabs in the view pane
•
•
•
•
•
•
Creating Additional Windows
Workbench allows you to create multiple fully functioning Workbench windows. Choosing File:
44
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Customizing the Workbench environment
> New Window
from the menu bar, creates a duplicate of your current Workbench window.
After you create multiple windows, you can then customize each individual window, as needed, to access different information, allowing you to see multiple concurrent views. You can also copy and paste items from one window into another window.
Creating tabs in the view pane
Workbench allows you to create multiple tabbed views within the view pane of a Workbench window,
as shown in Figure 25 , by doing one of the following:
• From the menu bar, select File: > New Tab.
• If tabs already exist, right-click on a tab and select New Tab from the popup menu.
The new tab has a view identical to the previous one.
Figure 25 Tabs in view
As needed, you can use each tab to display a different view, component, or even host, all within the same Workbench window. When you select a tab (make it active), the locator bar shows the current path and view. Also, the menu and tool bars update to show appropriate options for the current view.
From the view of the active tab, you can copy items, select another tab, and then paste them into that view. You can also drag items into an active view from the (Nav or Palette) side bar.
In the Workbench view pane you can use tabs to help organize and selectively display information.
Only one tab may be active at a time. In addition to simply clicking on a tab to make it active, you can select File: > Next Tab from the menu bar to move to the next tab, moving left to right, or you can move to the last tab by choosing File: > Last Tab from menu bar.
To close a tab, do any of the following:
• Right-click a tab and choose Close Tab to close that tab, or
• Right-click a tab and choose Close Other Tabs to close all tabs except that tab.
• From the menu bar, choose File: > Close Tab.
The currently active tab is closed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
45
Chapter 2 — About Workbench
Customizing the Workbench environment
Workbench options
Use the Workbench options dialog box, shown in Figure 26 , to customize your Workbench GUI
and to set other preferences.
Figure 26 Options dialog box
The following options are available in the options dialog box:
•
•
•
•
•
•
•
Alarm console options
Alarm console options, shown in
Figure 27 , allow you to customize both the appearance and behavior
of the alarm console.
Figure 27 Alarm console options
Alarm console options include the following:
• Minimum Group Ack Priority
Set a minimum priority level at which groups of alarms (more than one at a time) may be acknowledged.
• Needs Explicit Acknowledgement
46
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Customizing the Workbench environment
When set to true, all Alarms must be acknowledged by this console before they are removed from the alarm table.
• Sounds Enabled
When set to true – causes a sound to accompany an alarm.
• Default Sound File
Sets the path to the default sound file.
• Continuous Alarm
When set to true, causes an alarm to repeat continually, until it is acknowledged or cleared.
• Low Priority Color
Choose a color to designate a low priority alarm.
• Mid Priority Color
Choose a color to designate a mid priority alarm.
• High Priority Color
Choose a color to designate a high priority alarm.
• Alarm Class Mapping
Provides a way for you to create alarm classes and map specific alarms to classes.
Alarm portal options
Alarm portal options, shown in
, allow you to customize both the appearance and behavior of the alarm console.
Figure 28 Alarm portal options
Alarm console options include the following:
• Tray Icon Enabled
When set to True, displays an alarm icon in the system tray when the alarm portal is active.
• Alarm Popup Enabled
When set to True, displays an alarm popup window when the alarm portal is active.
• Alarm Popup Always On Top
When set to True, causes the alarm popup window to stay on top of other windows when the alarm portal is active.
• Alarm Popup Uncloseable
When set to True, makes the alarm popup window uncloseable when the alarm portal is active.
Bajadoc options
Baja reference documentation includes both Java API details as well as Baja slot documentation.
• Show Baja Only
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
47
Chapter 2 — About Workbench
Customizing the Workbench environment
When set to True displays only the reference documentation for slots (Properties, Actions, and
Topics). When set to False, documentation on the Java constructors, methods and fields is also displayed.
• Flatten Inheritance
This option allows you to flatten the inheritance hierarchy into a single set of documentation.
When set to False only the Java members and Baja slots declared in the specified class are displayed.
When set to True all Java members and Baja slots inherited from super classes are also shown.
General Workbench options
General Workbench options include setting for:
• AutoLogoff Enabled
Setting this parameter to True will activate the AutoLogoff feature. When activated, the AutoLogoff feature will automatically log off a user from a platform when there is no activity detected in Workbench for the period specified in the AutoLogoff Period field. Setting this parameter to
False
will disable the AutoLogoff feature.
• AutoLogoff Period
Time until Workbench logs off a user when AutoLogoffEnable is set to True.
• Prompt For Name On Insert
When set to True, Workbench will display a Name dialog box, when a new item is added to the workspace.
• Use Anti Alias
Anti-aliasing causes text to look crisper or smoother on the screen. When Anti-Alias is set to true, any editable text (for example a label or a text block) will be anti-aliased.
Text editor options
These options offer a whole range of ways to customize the presentation and behavior characteristics of the text editor tool. Settings include text and symbol color coding options, as well as key bindings for shortcut keys.
Wiresheet options
Wiresheet options, shown in
, allow you to customize the appearance of the wire sheet.
Figure 29 Wire sheet options
48
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 2 — About Workbench
Customizing the Workbench environment
Wire sheet options include the following:
• Show Grid
When set to True displays a grid background on the wire sheet view.
• Show Status Colors
When set to True, will display a different color for each status when it appears in the wire sheet.
• Show Thumbnail
When set to True – provides a small “thumbnail” view of the whole wiresheet for orientation and navigation purposes.
• Thumbnail X
A field is provided here for setting the X axis for the default position of the thumbnail view.
• Thumbnail Y
A field is provided here for setting the Y axis for the default position of the thumbnail view.
Lexicon options
report and the lexicon editor.
Figure 30 Lexicon options
Lexicon options include the following options:
• Hide Ref Values
Ref Values are those filter values that begin with a / . Setting this to True will hide the filter values from lexicon view. Use this if you do not want to localize references (like icons).
• Hide Accelerators
When set to True this option hides entries that define keyboard accelerators. Use this if you do not want to localize the accelerators.
• Show Missing
When set to True this option hides entries that are localized. Use this if you do not want to see localized keys.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
49
Customizing the Workbench environment
Chapter 2 — About Workbench
50
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points
Data and Control Model
In any NiagaraAX station, all real-time data is normalized within the station database as points, a special group of components. Each point represents one data item.
Note: This applies to a Supervisor station as well as a JACE station, a shift from r2 Niagara data modeling. Stations no longer have “external links” between them. Instead, proxy points under
a Niagara network are used. For more details, see “About the Niagara Network” on page 149.
The following sections provide more details:
•
•
•
•
•
•
•
About control points
In the most simple form, points are control points. Find them in palette control: Points.
Figure 1 Control points
Control points are the foundation for all points in the station, including all proxy points.
•
•
•
•
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
51
About control points
Chapter 3 — Data and Control Model
Types of control points
Types of control points
As shown in
there are 8 different simple control points. Each type reflects a combination of a data (value) category and a point type.
Table 1 Control point types
Boolean Category
BooleanPoint
BooleanWritable
Numeric Category
NumericPoint
NumericWritable
Enum Category
EnumPoint
EnumWritable
String Category
StringPoint
StringWritable
See “About data value categories” on page 52 and
“About point types” on page 53.
Other control components
Apart from the 8 simple points, many other components are found in both the control palette and the kitControl palette. Briefly, these components include:
• Extensions
To “extend” point functionality. See “About point extensions” on page 62.
• Triggers
To provide periodic “actions.” See
“About control triggers” on page 68.
• Other control objects
Found in various folders in the kitControl palette. Use these to provide station control logic based on data obtained from points. Example objects include (numeric) math types, (Boolean) logic types, and a PID loop, among others. Also, a few point extensions are in kitControl. See the section “Application for kitControl components” in the kitControl Guide.
About data value categories
There are four distinct data value categories for points, as well as for other components (for example, weekly schedules). These value types are:
• Boolean
Represents a binary value with only two states, such as “Off” or “On.”
• Numeric
Represents an analog value such as a temperature, level, rate or similar floating point number, or a varying count (integer). Double-precision (64 bit) values are used.
• Enum
Represents an enumerated state (more than two), such as a multi-speed fan with states “Off,”
“Slow,” and “Fast.” Enums are often called multi-states or discretes. States typically derive from established integer value/state name pairs.
52
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points About point types
• String
A string of one or more ASCII characters (and if alpha-numeric), often with some literal meaning.
Among the four categories, numeric and boolean points are the most common, as data usually falls into these two categories.
About point types
Within each of the four point data categories, there are two point types:
• (read-only) e.g. BooleanPoint or NumericPoint
Represents a read-only data item. Unlike with the writable point type, there are no “input” type properties.
Note: As copied directly from the control palette, there is no application for read-only points.
However, proxy points based upon read-only points, identical except for a non-null proxy extension and manner of creation, are both common and useful. For more details, see
“About the proxy extension” on page 63 and
“About proxy points” on page 74.
• Writable
Represents a data item that can be written, as well as read by the station (typically). An array of 16
“InN” inputs, each with a different priority level, is available to write the value. By default, the point’s value can also be set with an operator-issued action (right-click command), available at priority levels 8 (override) and 1 (emergency). For more details, see
“About point actions” on page 54. Writable points also have other features. See,
“About writable points” on page 81.
About point Out
Each point has a property “Out” that provides real-time information, as shown in
.
Figure 2 point Out provides real-time information
At a minimum, the Out property provides:
• value
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
53
About control points
Chapter 3 — Data and Control Model
About point inputs
• facets
Items affecting the display of the value, such as decimal places, engineering units, or text descriptors for Boolean/enum states. See
“About point facets” on page 58.
• status
Current status of the data, meaning the health and validity of the associated value. Status is specified by a combination of status flags, such as “fault,” “overridden,” “alarm,” and so on. If no status flag is set, status is considered normal and appears by default as “{ok}.”
Status flags are set in a number of ways. See “About point status” on page 69.
• priority
Currently active Niagara priority level (from a 16-level priority scheme), for writable control
points only. For more details on priority, see “About the priority scheme” on page 81.
Note: All writable control points include priority in status, including writable proxy points.
Priority appears at the end of the Out value, by default formatted as “@ n”, where n is 1 to 16, or if the fallback value is in effect, formatted as “@ def”. For example: “Off {ok} @ 1”.
About point inputs
Writable points have 16 input properties: “In1” to “In16,” corresponding to priority levels. As needed, you can link up to 14 of these inputs to another component in the station.
shows a Boolean-
Writable with links made to 3 inputs.
Note: Read-only (plain) points do not have any input properties.
Figure 3 Example links made to priority inputs
By default, a writable point’s glyph (shape on wire sheet) shows only inputs In10 and In16 “pinned” for linking. However, when linking to a writable point, the Link editor shows all available priority
inputs. For more details, see “About the priority scheme” on page 81.
About point actions
Writable points have actions—by default, these appear in a right-click menu when you select a point in a Workbench view or in the Nav tree (
).
54
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points
Figure 4 Actions available on right-click menu
About point actions
An action is a slot that defines a behavior. Some other control objects and extensions also have actions.
In the case of the 4 writable control points, default actions include the ability to:
• Override the point at priority levels 8 (override) and 1 (emergency override), where control can be independently set or “auto’ed” at either level. An override can be for a defined (or custom) length
duration, as specified in the action’s popup dialog. See “About override actions” on page 55.
• Set the value of the point’s “Fallback” property. See
“About set (Fallback) action” on page 56.
Often, you modify a writable point’s default actions—see “Modifying default actions” on page 57.
About override actions
Whenever a writable point is controlled from an action issued at either override level, it has an “override” status. By default, override status color is magenta, as shown in
. For more point status
details, see “How status flags are set” on page 71.
An override action to a value (not an “auto”) prompts for an override duration, see
Figure 5 Override action duration (“argument”) dialog
By default, a “Permanent” override is the first choice in the drop-down list—the override value will remain effective until the next time this action is auto’ed. Other timed durations are available, including a “Custom” selection in which a user specifies a duration in hours, minutes, and seconds.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
55
About control points
Chapter 3 — Data and Control Model
About point actions
After clicking OK, the override action is issued to the point—if this is the highest effective priority level, the writable point operates under this control. If this is a timed override, the action is automatically auto’ed upon expiration of the override period.
About set (Fallback) action
Whenever a writable point has a “null” or “invalid” value at inputs In1—In16 (note this means that both override levels are currently “auto’ed”), the Out slot is set to the value of the Fallback property.
For more details, see “About the priority scheme” on page 81.
By default, an operator-level user can change the Fallback property, using the “set” action. This produces a popup dialog that displays the current Fallback value (
).
Figure 6 Set action prompt to change writable point’s Fallback property
From the set action prompt, a “Cancel” leaves the current Fallback property unchanged. Otherwise, the Fallback property is set to the value entered (or currently displayed value).
Note: The set action prompt does not display (or accept) a “null” value for Fallback. However, a
Fallback of null can be entered from the point’s property sheet.
A common application for this feature is with NumericWritables used as setpoints, particularly under a NiagaraNetwork. As Niagara proxy points are always read-only points (not writable types), yet inherit any actions of the source point, this feature provides user access to setpoints via px graphics without creating additional proxy points. In particular, this “set” action is designed to work well with
“SetPoint” type widgets (found in the kitPx palette). For details, see
Note: Each of the four “constant” kitControl components also provides a “set” action that works in a similar manner, including with kitPx widgets. However, a constant object (NumericConst,
BooleanConst, etc), has no priority inputs or Fallback property—the set action simply writes directly to the component’s current Out slot. For details, see the “About Constant compo-
56
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points About point actions nents” section in the kitControl Guide.
Modifying default actions
Unless all the “defaults” for actions of a writable point are acceptable (display names, all actions available, default user access), you may wish to modify action defaults. Do this from the slot sheet of
the writable point. For general information, see “About slots” on page 13, and
“Using the slot sheet” on page 354.
The following sections provide more details:
•
— Change how the point’s popup action menu lists available actions
•
— Limit the actions that are made available, either by user level or for all users
Display names. By default, action display names are generic (“Emergency Inactive” and so on). You can change the display name for any action. From the slot sheet, click on an action’s Display Name
Figure 7 Editing action display names from slot sheet
When a user invokes an action, the popup menu lists possible actions by more meaningful descriptors. For example, you could change the “set” action display name from “Set” to “Set Fallback.”
Action access. By default, for any writable point, all actions are available to any admin-level user, and all actions except emergency-level ones are available to an operator-level user. As needed, you can selectively “hide” actions (from any level user), or change default permissions for actions.
From the slot sheet, do this by editing the action’s config flags (right-click the action and select Con-
fig Flags
, as shown in
).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
57
About control points
Figure 8 Editing config flags of action to “hide” or change permission level
Chapter 3 — Data and Control Model
About point facets
In the Config Flags editor, you click to assign or remove config flags. As pertains to action slots, the following flags are most often changed:
• Operator
If checked, only operator-level access is needed to invoke the action. If cleared, admin-level
access is needed. For details on permission levels, see “About permission levels” on page 276.
• Confirm Requried
If checked, a second (confirmation) dialog appears after the action is invoked, before the action
executes. An example confirmation dialog is shown in Figure 9 . By default, this flag is cleared.
• Hidden
If checked, the action does not appear (is hidden) from the action popup menu—for any user. You may wish to do this selectively for some actions, for example, the “set” action for Fallback access.
(Note that a user with admin-level rights to the point may still access the point’s slot sheet.)
Figure 9 Action confirmation dialog (from “Confirm Required” config flag)
About point facets
Primarily, facets determine how the point’s value displays in the station. Examples include engineering units and decimal precision for numeric types, and descriptive value (state) text for boolean and enum types. With the exception of proxy points (with possible defined device facets), point facets do
not affect how the point’s value is processed.
Note: Besides control points, various other components have facets too. For example, many kitCon-
trol and schedule components have facets. Details about point facets apply to these components too, unless especially noted.
58
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points About point facets
Topics about facets include:
•
•
Facets importance for Enum points
•
Effect of facets on point actions
•
Effect of facets on proxy points
Accessing and editing facets
, you modify facet values in a point’s property sheet, using the Edit Facets dialog.
Figure 10 Point facets and edit dialog
Optionally, you can add or remove facet values in a point—however, for most points you will only modify or provide new values for the default facets.
Note: For string-type points (StringPoint, StringWritable), facets have little practical application. By default, the Facets slot is empty for string-type points.
Facets importance for Enum points
Facets for enum-type components (EnumPoint, EnumWritable, EnumSchedule, etc.) define the operating range of the component, meaning its different possible enumerated states. Each state is defined by a pairing of an integer value-to-text, also known as ordinal-tag. Each ordinal must be a unique integer, and each tag must be unique text. By default, the point’s value displays using tag text.
If you add an enum point from the control palette, its Facets slot has a blank range entry. Until you
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
59
About control points
Figure 11 Enum dialog for enum point “range” facets
Chapter 3 — Data and Control Model
About point facets
When defining range enumerations, instead of defining a custom one with your supplied ordinals and tags text, you can also select from well known “frozen” enumerations, as defined in various installed modules. A checkbox enables this and provides a drop-down list for you to select by module and enu-
meration type (see Figure 12 ).
Figure 12 Frozen enum selection in Enum dialog
Depending on the driver/network type, the Point Manager under a device may automate this facets range configuration when you add enum-type proxy points. For example, under a Lonworks device, if you add a EnumPoint for a Lonworks NVO that uses an enumerated SNVT, that point’s facets will automatically be configured with the correct range values.
Note: If an enum-type point receives an input value not included in its defined facets range, it displays the ordinal integer value for that input. This varies from the multistate objects used in r2
Niagara, which would display “Error” for any value not defined in its “stateText” entries.
60
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About control points About point facets
Effect of facets on point actions
the point’s action (command) menu, as follows:
• EnumWritable
Upon an override or emergency action, a secondary drop-down selection dialog lists the possible enum values (in its range), using display tag text. This list appears ordered top-to-bottom by the tag associated with each ordinal, lowest-to-highest.
• NumericWritable
Upon an override or emergency action, an entry dialog permits a value only between the facets
“min” and “max” values, inclusive. By default, these facets values for numeric-type points are min= -inf and max= +inf (no effective range checking for an action).
For example, you could use this facet’s feature with a NumericWritable that sets a temperature control setpoint, by setting its facets min= 65 and max=85. After saving this change, any override or emergency action issued to that NumericWritable would need to fall within this range. Otherwise, a user would see a message showing the acceptable range, and be prompted to try again.
Note: Facets “min” and “max” values do not affect any received input values or proxied data, only what can be issued via an action.
Effect of facets on proxy points
Each proxy point typically represents a piece of data in a remote device (see
facets (units) already defined—these reflect its “Device Facets” (in its ProxyExt).
If needed, you can change the parent proxy point’s facets to use similar (same family) units. For example, if a Lonworks proxy point for a temperature NVI (learned in degrees C), you can change the proxy points facets to degrees F. The “default” conversion performed in the LonProxyExt automatically adjusts the output value appropriately. In this case, facets directly affect the point’s out value.
Note: If you change a proxy point’s facets to use units that are dissimilar from the device facets in its
ProxyExt (without also changing its Conversion from “Default”), the proxy point will have a fault status (to show misconfiguration). For example, if its device facets are temperature, and you change the point’s facets to pressure, the point will have a fault status.
For details on properties common to the ProxyExt in all proxy points, including Device Facets and Conversion, see
“ProxyExt properties” on page 80.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
61
About point extensions
Chapter 3 — Data and Control Model
Extension process overview
About point extensions
As needed, you can add one or more extensions to a point, each as a child of that point. Extensions are a way to add functionality to a point (or extend it) in a modular fashion.
The following topics provide more details on extensions:
•
•
•
•
•
•
Note: Extensions also apply to most kitControl objects. See
“Extensions and kitControl components” on page 4 for more details.
Extension process overview
Extensions are found in several palettes, including alarm, control, history, and kitControl.
You typically add an extension by either:
• dragging it into the property sheet of the point, or
• dropping it on the point’s icon in the Nav tree.
A point’s property sheet lists extensions below its normal (frozen) properties. You can expand each
extension to view and modify its properties, as shown in Figure 13 .
Figure 13 Extension expanded in a point’s property sheet
If a point has multiple extensions, they are processed in the same top-to-bottom order that they appear listed in that point’s property sheet. You can re-order extensions in a point—from the top of the
62
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point extensions Types of point extensions point’s property sheet, or on the point’s icon in the Nav sidebar, right-click and select Reorder.
Note: If needed, you can also select and expose extension properties (for linking convenience) on the point’s glyph by using the Composite editor of the parent point. For more details, see
“About composites” on page 83.
Types of point extensions
Optional extensions are in three main categories:
•
control extensions
from control palette. See “About control extensions” on page 64.
•
alarm extensions
from alarm and kitControl palette. See “About alarm extensions” on page 65.
•
history extensions
from history palette. See “About history extensions” on page 67.
About the proxy extension
Each point has a proxy extension (Proxy Ext), a frozen property. The proxy extension is important— it indicates how the point’s data originates, including details specific to the parentage of the point’s network and communications (driver).
A point’s proxy extension is either:
• Null
For any point that you copy from the control palette (or add using the right-click menu), the proxy extension is simply null (NullProxyExt)—an empty placeholder. The station itself originates the point's default Out value.
• <DriverType>
For any proxy point, meaning any of the 8 point types you create using the Points extension under a device represented in any of the network types, the proxy extension is <DriverType>ProxyExt.
For example, a BooleanWritable proxy point under the Points container of a Bacnet Device has a proxy extension of “BacnetBooleanProxyExt.”
For any proxy point, its proxy extension contains information organized in child properties. Some properties may be unique to that specific driver type.
compares property sheet views of the proxy extension properties for two BooleanWritable points, on the left a control point, on the right a BACnet proxy point.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
63
About point extensions
Figure 14 Proxy extension for control point (null) and a Bacnet proxy point.
Chapter 3 — Data and Control Model
About control extensions
For more details, see “About proxy points” on page 74 and
“ProxyExt properties” on page 80.
About control extensions
Control extensions are found in palette control: Extensions ( Figure 15 ). As needed, you can
add them to points along with alarm and history extensions.
Figure 15 Control extensions
Control extensions perform additional processing on a point’s received value. There are relatively few types of control extensions. See
“Types of control extensions” on page 64.
Types of control extensions
lists all available control extension types and the applicable point parents.
64
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point extensions About alarm extensions
Table 2 Control extension types
Control extension type
(palette:Folder)
(control:Extensions)
(control:Extensions)
ProxyExt
(control:Extensions)
Applies to point types
(read-only) Writable
What it does
BooleanPoint
EnumPoint
—
BooleanWritable
EnumWritable any object with single
Boolean Out, e.g. kitControl: Logic object “And”
NumericPoint
—
NumericWritable any object with single
Numeric Out, e.g. kitControl: Math object “Add”
(standard for any point, see “ “About the proxy extension” on page 63)
Accumulates runtime and change of state (COS) count.
Extension actions permit resetting (zeroing) the runtime and
COS count.
Accumulates numeric total using hourly or minutely totalization. Extension has action to reset (zero) total.
Provides methods to driver communications.
About alarm extensions
Use an alarm extension for any point you wish to monitor for offnormal values, and show alarm indication when a limit or value is met or exceeded. In an alarm extension, you also specify whether an alarm annunciation should occur upon alarm transitions, plus many other parameters.
Find the alarm extensions in palettes alarm: Extensions (
) and kitControl:Alarm.
Figure 16 Alarm extensions
Alarm extension properties define items such as alarm enable (annunciation) transition types, alarm delay times, associated alarm class, and alarm display text for different transition types. You define the actual alarm limits or state(s) in properties in the extension’s “Offnormal Algorithm” slot. For more details, see
“About alarm extension properties” on page 193.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
65
About point extensions
Types of alarm extensions
lists all alarm extension types and the applicable point parents.
Table 3 Alarm extension types
Chapter 3 — Data and Control Model
About alarm extensions
Alarm extension type
(palette:Folder)
(alarm:Extensions)
(alarm:Extensions)
(alarm:Extensions)
(alarm:Extensions)
(alarm:Extensions)
(alarm:Extensions)
LoopAlarmExt (kitControl:Alarm)
ElapsedActiveTimeAlarmExt
(kitControl:Alarm)
Applies to point types
(read-only) Writable
NumericPoint
—
BooleanPoint
—
—
EnumPoint
— any type that accepts extensions
—
BooleanPoint with
DiscreteTotalizerExt
—
General description
NumericWritable any object with single numeric Out, e.g. kitControl: Math object “Add”
BooleanWritable any object with single
Boolean Out, e.g. kitControl: Logic object “And”
BooleanWritable
Provides alarming based upon numeric alarm high and low limits. Includes configurable deadband.
Provides alarming based upon one of two possible values (state) as an alarm condition.
EnumWritable
EnumWritable any type that accepts extensions
LoopPoint
BooleanWritable with DiscreteTotalizerExt any object with single
Boolean Out (also with a
DiscreteTotalizerExt), e.g. kitControl: Logic object
“And”
Provides alarming based upon mismatch between commanded value and actual (sensed) value.
Extension has feedbackValue input property for linking.
Provides alarming based upon one of multiple possible values
(state) as an alarm condition.
Provides alarming based upon mismatch between commanded value and actual (sensed) value.
Extension has feedbackValue input property for linking.
Provides alarming based upon any combination of status flags, including overridden, null, etc.
Sliding alarm limit for LoopPoint based upon controlled process deviation from setpoint.
Provides alarming based upon accumulated runtime (elapsed active time). References a specific DiscreteTotalizerExt under same parent point.
66
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point extensions About history extensions
Alarm extension type
(palette:Folder)
Applies to point types
(read-only) Writable
General description
ChangeOfStateCountAlarmExt
(kitControl:Alarm)
BooleanPoint with
DiscreteTotalizerExt
—
BooleanWritable with DiscreteTotalizerExt any object with single
Boolean Out (also with a
DiscreteTotalizerExt), e.g. kitControl: Logic object
“And”
Provides alarming based upon accumulated COS (change of states). References a specific
DiscreteTotalizerExt under same parent point.
About history extensions
Add a history extension to any point for which you want to log historical data, that is collect a history.
In a point history, each collected sample of slot “Out” has a date-timestamp, point status and value.
Point history data is viewable in both a table and chart format.
Find the history extensions in palette history: Extensions ( Figure 17 ).
Figure 17 History extensions
Each history extension has various properties in two major groups:
• Collector
Determines how or when data is collected, such as active time, and (if applicable) either change tolerance or the collection interval time.
• History Config
Determines how the data is stored and accessed in the system, such as history name, capacity, and full policy.
For more details, see About Histories.
Types of history extensions
lists all history extension types and the applicable point parents.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
67
About control triggers
Table 4 History extension types
History extension type
BooleanChangeOfValue
BooleanInterval
Applies to point types
(read-only) Writable
BooleanPoint
— as above
BooleanWritable any object with single
Boolean Out, e.g. kit-
Control: Logic object type “And” as above
NumericChangeOfValue NumericPoint
—
NumericInterval
EnumChangeOfValue
EnumInterval
StringChangeOfValue
StringInterval as above
EnumPoint
— as above
StringPoint
— as above
Chapter 3 — Data and Control Model
About history extensions
General description
Collects upon each change of
Boolean value (state) or status.
NumericWritable any object with single
Numeric Out, e.g. kit-
Control: Math object type “Add” as above
Collects upon a repeating time interval, as configured.
Collects upon each change of value (outside a specified tolerance) or change of status.
EnumWritable any object with single
Enum Out as above
Collects upon a repeating time interval, as configured.
Collects upon each change of enumerated state or status.
StringWritable any object with single
String Out as above
Collects upon a repeating time interval, as configured.
Collects upon each change of string value or status.
Collects upon a repeating time interval, as configured.
About control triggers
There are two “time triggers” in the palette control:Trigger. These objects do not represent data, but instead regularly fire a topic.
68
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point status
Figure 18 Control triggers
How triggers are used
The two control trigger types are:
• Interval
Fires at a regular, repeating intervals specified in its Trigger Mode property.
For example, every n minutes, n hours, or whatever combination needed.
• Daily
Fires once a day at a specific time and day of week, as specified in its Trigger Mode property. For example, at 00:00:00 (midnight) all days of week except Sunday.
Each type has even more configuration capabilities to further define the fire time.
How triggers are used
To use a trigger, you typically link it to a selected action of a point extension (e.g. control, alarm, and history) to automate an action. Often, you use a trigger as a child of a particular point (sibling to the linked extension). Or, you can have a trigger in the same container as multiple points, and link it to more than one point or point extension.
For example, a Daily trigger (defined for midnight) can be linked to the ResetElapsedActiveTime action of a DiscreteTotalizerExt extension of a BooleanWritable point. In this case, that point’s DiscreteTotalizerExt would only show runtime accumulated during the current day.
About related objects
Other objects with trigger functions are found in various palettes. The most closely related is the TriggerSchedule object, found in the Schedule palette. See
“About trigger schedules” on page 315.
About point status
Along with point value, point status is available at point Out. Status reflects status flags, which may get set singly, or in combinations. Status flags are typed by a unique text string (for example: “alarm” or “down”), and many have associated status colors (a background and a foreground). For example, the default status colors for alarm is white text on red background.
Status without any flags set is considered normal (text “ok”), and is without color indication.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
69
About point status
Chapter 3 — Data and Control Model
Types of status flags
Note: For each installed lexicon, text strings for status flags (plus associated colors), are individually adjustable by editing default values in that host’s baja lexicon, using Workbench’s Lexicon
Editor. For a default English installation, to change default status appearance settings, edit the en: baja lexicon. For more details, see About Lexicons.
The following topics explain further details about point status:
•
•
•
•
Types of status flags
Status flag types are listed in
Table 5 , along with associated default colors (if any).
Table 5 Status flag types
alarm
Type Default Colors, Example
white text, red background
Meaning
Point currently has a value in an alarm range, as defined by property in its alarm extension.
fault overridden black text, orange background black text, magenta background
Originates from a proxy point only. Typically indicates a configuration or licensing error. If it occurs after normal operation, it may indicate a
“native fault” in device, or the point’s parent device has a fault status.
Current point control is from an action, meaning a user-invoked command at either priority level 8 (override) or priority 1 (emergency).
disabled gray text, light gray background
Originates from a proxy point only. Point (or its parent device or network) has been manually disabled (property enabled = false).
down black text, yellow background stale black text, tan background null (no color indication) unackedAlarm (no color indication)
Originates from a proxy point only. Driver communications to the parent device are currently lost, based upon the device status (Monitor) configuration for that network.
Originates from a proxy point only. Driver communications have not received a requested response for this data item within the configured times (Tuning period).
Current point control has entered a null state, vs. a specific value and priority level. Typical to fallback operation for a writable point.
Last point alarm event has not yet received user acknowlegment.
Point’s alarm extension uses alarm class requiring acknowledgment.
70
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point status Priority of status indication
Priority of status indication
for a point or object can get set in combinations, status color indication uses a priority method. Among those 6 status flags with associated colors, priorities (and default colors) are:
1. disabled (dark gray)
Proxy point origination only. Point may have other status flags set. Typically, you manually set and clear this status (unlike others). After disabled is set for a proxy point, it is no longer polled.
Further status changes do not occur until disabled is cleared.
2. fault (orange)
Proxy point origination only. See
“Proxy point status” on page 73.
3. down (yellow)
Proxy point origination only. See
“Proxy point status” on page 73.
4. alarm (red)
Point may have other status flags set.
5. stale (tan)
Proxy point origination only. See
“Proxy point status” on page 73.
6. overridden (magenta)
Point may have other status flags set.
Note: Status types unackedAlarm and null do not affect the indicated status color.
How status flags are set
Status flags are set differently depending on the type of point or control object. The following sections explain:
•
•
Propagate Flags status option (linked Math and Logic objects)
•
Simple control point status
For simple control points (NullProxyExt) the following status flags are the only ones set and cleared:
• alarm
Point is currently in an alarm condition as defined in its alarm extension.
• unackedAlarm
Point has alarm extension assigned to an alarm class requiring acknowledgment, but the last alarm event has not yet been acknowledged. Point may/may not be in alarm.
• override
Writable points only, during a user-initiated action at priority levels 8 (override) or 1 (emergency).
The override flag clears when the action “times out,” or when a user issues an “auto” action at that same priority level.
• null
Writable point has “null” or otherwise “invalid” value at In1—In16, plus “null” configured as
“Fallback” value. See
“About “isValid” status check” on page 74.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
71
About point status
Chapter 3 — Data and Control Model
How status flags are set
See Figure 19 for examples of override and alarm status in simple control points.
Figure 19 Status with simple control points
Propagate Flags status option (linked Math and Logic objects)
By default, kitControl objects maintain independent status flags from input-linked points. However, as a configuration option in each math or logic-type kitControl object (kitControl palette folders
“Math” and “Logic”), you can specify “out” status to propagate from input status.
The object’s Propagate Flags property allows you to select any combination of the following status types for propagation:
• disabled
• fault
• down
• alarm
• overridden
Note: If the math or logic object has multiple inputs, and you set the propagateFlags property to select one or more of the statuses above, simple “OR” logic is used across all inputs for the propagation of each selected status.
Depending on usage, status propagation may be extensive. Note that four of the five status types (all except alarm and overridden) are “invalid status,” meaning they cause the output of the object (if
As an example of status propagation, some number of NumericWritable points are used to establish setpoints, and you link them all to a Math: Average object for downstream zone control. In turn, the
Average object feeds a Math: Reset object. Both math objects have “override” enabled in their “propagateFlags” property. A user issues an override (action) to one of the NumericWritable points, to
override a setpoint ( Figure 20 ).
72
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About point status
Figure 20 Status propagation in linked writable points, kitControl objects
How status flags are set
For the duration of the override, the linked Average object will also have an overridden status, as will the Reset object, and so on. However, note that the linked writable point (NWcombined) in this example does not have overridden status—status never propagates to any point.
Note: Status propagation did not occur in Niagara r2, and is a new configuration option in NiagaraAX. Before using this feature in an actual job, you should test and evaluate results to be sure it has the desired effect. For example, if a Logic or Math object is exposed in a graphic and appears overridden, a user may (incorrectly) assume that they can right-click command (perform an action) on that kitControl object, based on status color indication.
Proxy point status
In addition to status flags that also apply to non-proxy points (see
updates received via the parent driver’s communications subsystem, for example:
• down
Driver unable to receive reply from parent device, as per configuration in Monitor extension. In this case, all proxy point children of the device will have status down.
• fault
Typically, this indicates an AX configuration error or license error. If a fault occurs following normal (ok) status, it could be a “native fault” condition detected within the device, or perhaps some other fault criteria that was met. The point’s proxy extension contains a “Fault Cause” text property that contains more information.
• stale
Since the last poll update, the point’s value has not updated within the specified “Stale Time” of its Tuning Policy. This stale status clears upon next received poll value.
Statuses above are set automatically, but you typically set a fourth status for a proxy point manually:
• disabled
Using the proxy extension’s Boolean property “Enabled” (default is true). While set to false (disabled), polling stops for that point, as well as any further status changes.
Note: Typically, a proxy point has an alarm status only if its value falls in the “offnormal algorithm” limits specified in its own (NiagaraAX) alarm extension. If the driver and protocol has
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
73
About proxy points
Chapter 3 — Data and Control Model
About “isValid” status check
“native” alarm determination methods (such as with BACnet), a proxy point may show alarm status that originated locally within that device. In the case of the Niagara Bacnet driver, this also applies to override status, possibly a “native” condition for a proxied BACnet object.
About “isValid” status check
When linking an input-type slot of a writable point or kitControl object, the value received at the input is processed (evaluated) by that point or object only if it is valid.
Note: A valid input is one with none of the following status flags set:
• down
• fault
• disabled
• null
• stale
If any of the above status bits are set at an input, that input value is not used.
• If a kitControl object with a single input, by default that object uses the last known valid received
(at least until the input becomes valid again).
• If a kitControl object with a multiple inputs, only the valid inputs are evaluated.
•
If a writable point, the priority scan continues. See “About the priority scheme” on page 81.
About proxy points
Proxy points are often the bulk of all points in a station. This is true whether a JACE or a Supervisor
proxy extension. See “About the proxy extension” on page 63.
These following sections provide more details about proxy points:
•
•
•
Proxy points versus simple control points
•
Location of proxy points
In the AX station architecture, proxy points must reside under the driver network and device from which the specific data originates. Proxy points are under that device’s Points container (Points exten-
sion), as shown in Figure 21 .
74
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About proxy points
Figure 21 Proxy points location example
How proxy points are made
As needed, you can create folders under a device’s Points container to further organize the proxy points. In addition to proxy points, you can also add simple control points (null proxy ext), schedule objects, and other kitControl objects under a device’s Points container.
Note: See also
“Location for kitControl components” in the kitControl Guide.
Depending on station type, proxy point locations will vary as follows:
• JACE station
Most proxy points are under non-Niagara driver networks, such as Lonworks, Bacnet, and Modbus, to name a few. These points represent real-time data in various devices attached (or somehow networked) to the JACE controller.
Like all AX stations, the JACE will also have a Niagara Network too. Any proxy points under it will represent data received from other JACE stations and/or perhaps the Supervisor station.
• Supervisor station
Typically, most proxy points are under its Niagara Network, where each JACE appears as a station device. Proxy points under each station device represent real-time data from that JACE. Typically, most data in a JACE station also originates as a proxy point, and so these points are often a
“proxy of a proxy.” For details, see “About the Niagara Network” on page 149.
Note: If the Supervisor is specially licensed for direct field device communications, such as a
BACnet Supervisor or OPC Supervisor, its station will have many proxy points under other driver network types, and perhaps only a few under its NiagaraNetwork. In Drivers architecture, it resembles a JACE.
For more details, see “Driver architecture” on page 89.
How proxy points are made
Note: You create proxy points in a station as one of the later stages in building a driver network.
This section only provides an overview of the proxy points portion. For more complete
details, see “Driver architecture” on page 89.
When you add a device under a network, one of its default extensions is a container named “Points.”
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
75
About proxy points
Chapter 3 — Data and Control Model
How proxy points are made
The default view for Points is a “ Point Manager ,” which you use to add proxy points to the station
database. An example Bacnet device Points Manager is shown in Figure 22 .
Figure 22 Points Manager example (Bacnet Device)
Typically, you have performed your previous station configuration of this network with the host (e.g.
JACE) networked and communicating to the devices of interest. This allows you to use the “Learn
Mode” feature (provided by most drivers). This feature is especially useful for adding proxy points to the station.
In the Point Manager, the Learn Mode toggles the view between only proxy points that are currently in the station (“Database”), and a split view showing both a “Discovered” area and the “Database”
area. See “About Learn toggle” on page 109 for more details.
Clicking the Discover button launches a “point discovery job.” The driver queries the selected device to retrieve available data. Depending on a number of factors (driver type, communications rate, amount of data), this can take from only a few seconds to over a minute. See
.
Figure 23 Points Discover in progress
When the discover completes, the “Discovered” view portion provides a table of available data items.
Each row represents at least one item (a candidate for one proxy point). If there are multiple, closely-
76
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About proxy points How proxy points are made related data items, that row appears with a leading plus (“+”). You can expand it to see other available data items. Again, each row is a candidate for one proxy point.
Depending on the driver type, table column headings vary—for example a Bacnet points discover
shows “Object Name,” “Object ID,” etc., in the Discovered table (see Figure 24 ).
Figure 24 Points Discover completed
As needed, you click on column headers to resort and/or use the scroll bar to view available discovered data items. After selecting one or more items by clicking on rows (to highlight), you can click
the Add button to start the proxy point creation process. The Add dialog appears ( Figure 25 ).
Figure 25 Add points dialog
The Add dialog allows you to select each data item and change things about its default point creation
before it is added to the station database. Most important is “Type,” meaning the control point type— as unlike other things (such as Name) you cannot change that after the creation. Apart from Name and
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
77
About proxy points
Chapter 3 — Data and Control Model
How proxy points are made
Type, most other properties are proxy extension properties.
driver recognizes the data item as writable, this will include writable point types.
Figure 26 Type drop-down in Add dialog
Typically, you do not change the data category type (Boolean, Numeric, etc.), but you may wish to select either a read-only point or a writable point.
You click any discovered data item to select it for changing Type, or any other property. If a common change is needed among data items (for example, Poll Frequency), you can select multiple items and edit that property one time.
When you are satisfied with the point types shown for each item, you click the OK button at the bottom of the Add dialog. Those proxy points are then created in the station database in the Points container, and now appear as table rows in the “Database” (lower) table of the Point Manager view. The source data items now appear “ghosted” in the “Discovered” (upper) table, to indicate that they now
exist in the station database. See Figure 27 .
Figure 27 Proxy points added to station
You may repeat this process as needed to create additional proxy points, where you can toggle the display of the Discovered portion off and on by clicking the Learn Mode tool.
Once in the Database table of the Points Manager, you can click to select (highlight) a proxy point, then modify it using the Edit button, or simply double-click it. This produces an Edit dialog nearly identical to the Add dialog, where you can change the same proxy extension properties and Name
78
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About proxy points Proxy points versus simple control points
(but not Type). You can also select multiple proxy points and use the Edit dialog to “gang edit” one or more of the same properties that are common to each selected point.
In the Database portion, you can right-click a proxy point to access its normal views, including property sheet. There, you can expand its Proxy Ext to see many of the same properties you saw in the
Add and Edit dialogs. Also, you can right-click a proxy point in the Database table to access any available point actions (if a writable point).
Each Points container has other views besides the default Point Manager. For example, you can select its Wire Sheet view to see and organize the proxy points glyphs (
Figure 21 on page 75), add addi-
tional objects from palettes control and/or kitControl, and so forth.
Note: The following notes apply when working with proxy points.
• In a Niagara Network, the Discover and Add process is different than in other driver networks.
There, you use a “BQL Query Builder” to select data items in a remote station. For more details,
see “About the Niagara Network” on page 149 and
“About the Bql Query Builder” on page 157.
• Any Point Manager view only shows proxy points. If you added other objects (for example, control points with null proxy extension, or kitControl objects), they do not appear in the Database table. However, they are visible in the Nav tree and the Points wire sheet.
• If you want folders under Points to organize your proxy points and other objects, use the “New
Folder” button in the Point Manager to create each folder. This provides a Point Manager view for each folder. For more details, see
“About the Point Manager” on page 121.
Proxy points versus simple control points
Functionally, there is little difference between a simple control point (NullProxyExt) and the equivalent proxy point. For example, you can add the same extensions (e.g. control, alarm, and history) to a proxy point as to a simple control point—there is no need to “duplicate” the point first.
However, apart from the location differences (see “Location of proxy points” on page 74) and manner
of creation (see “How proxy points are made” on page 75), proxy points have the following differ-
ences from simple control points:
• Status flag processing
Status flags of proxy points are affected by real-time changes that may occur in the remote device, plus changes in communications between that device and the station. This is in addition to “AXadded” status flags set by an alarm extension (for example, “alarm” or “unackedAlarm”). See
“Proxy point status” on page 73.
Related are “global” status rules common among NiagaraAX drivers, set at both the networklevel as well as adjustable at the proxy-point level. For details, see
“About Tuning Policies” on page 98.
• Point duplication
When you duplicate a proxy point, you are duplicating information in its Proxy Ext that might be better left unique. This may result in redundant messages between the device and station for the same data item, adding overhead. If duplicating a proxy point, you should have a clear idea of what you will change to prevent this inefficiency.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
79
About proxy points
Chapter 3 — Data and Control Model
ProxyExt properties
ProxyExt properties
Regardless of the driver, the proxy extension (ProxyExt) for any proxy point has a number of core
properties that provide the same behavior. Depending on the driver, other ProxyExt properties are often present—see the particular driver document for details on those properties.
Core properties in any ProxyExt include the following:
• Status
• Fault Cause
(read only) If point has fault status, provides text description why.
• Enabled
Either true (default) or false. While set to false, the point’s status becomes disabled and polling is suspended.
• Device Facets
(read only) Native facets used in proxy read or writes (Parent point’s facets are used in point status display, and are available for edit in Add and Edit dialogs in in Point Manager).
• Conversion
Specifies the conversion used between the “read value” (in Device Facets) and the parent point’s output (in selected point facets).
Note: In most cases, except when working with particular Ndio proxy points, or perhaps Modbus proxy points, the standard “Default” conversion selection is best.
Conversion selections include:
•
Default
(The default selection). Conversion between “similar units” is automatically performed within the proxy point. For example, if a Lon proxy point with a LonFloatProxyExt (Device Facets of degrees C), if you set the point’s Facets to degrees F, its output value automatically adjusts.
If you set the parent point’s Facets to dissimilar units (say, in this case to kilograms), the parent point has a fault status to indicate a configuration error.
•
Linear
Applies to certain Ndio proxy points, such as NdioVoltageInput and NdioResistiveInput. Also commonly used in some Modbus proxy points. For these points, you typically want the point’s output value in some units other than Device Facets (if Ndio, voltage or resistance), and the
Linear selection provides two fields to make the transition:
Scale: Determines linear response slope.
Offset: Offset used in output calculation.
•
Reverse Polarity
Useful in a Boolean-type Ndio proxy point to reverse the logic of the hardware binary input.
Also, may be used in any driver’s proxied BooleanPoint, as a way to “flip” the read state of the native value.
Note: Be careful in the use of the reverse polarity conversion, as it may lead to later confusion when troubleshooting logic or communications problems.
•
Thermistor Type 3
Applies to an NdioThermistorInput point, where this selection provides a “built-in” input re-
80
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About writable points About the priority scheme sistance-to-temperature value response curve for Type 3 Thermistor temperature sensors.
•
Tabular Thermistor
Applies to an NdioThermistorInput point, where this selection provides a control for a popup dialog for a custom resistance-to-temperature value response curve, including ability to import and export response curves.
• Tuning Policy Name
(most drivers) Associated network tuning policy for this proxy point, by name. Tuning policies are used to separate poll rates and other driver features. See
“About Tuning Policies” on page 98.
• Read Value
(read only) Last value read from the device, expressed in device facets.
• Write Value
(read only) Applies if writable point only. Last value written, using device facets.
About writable points
All writable points provide right-click actions. Override actions are evaluated within the priority scheme used by any writable point. In the case of the “set” action, the point’s “Fallback” property is modified (see
“About point actions” on page 54). BooleanWritable points also offer built-in “mini-
mum on/off” timers.
•
•
About minimum On and Off times
About the priority scheme
Each writable point uses a 16-level priority scheme, with corresponding inputs In1—In16, plus a
“Fallback” property. Level 1 is the highest priority, and level 16 is the lowest.
The following topics further describe the priority scheme:
•
•
•
Priority input scan
For any writable point, the effective input value is determined by a priority scan, looking for a “nonauto” action at level 1 (emergency), then the value at the highest valid input, going from level 2, to 3, and so on to level 16. (At level 8, any “non-auto” action is evaluated as valid).
Like almost all control execution, this priority scan is event-driven, meaning it occurs when any input value changes. An input’s value typically comes from a link—however, note that for most inputs, you may enter a value directly in the point’s property sheet (as an alternative source).
Note: A valid input is one with none of the following status bits set:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
81
About writable points
Chapter 3 — Data and Control Model
About the priority scheme
• down
• fault
• disabled
• null
• stale
If all 16 priority levels are evaluated without a valid input (and without an action at levels 1 and 8), then the fallback value is used.
Note: You can configure the writable point’s “Fallback” property to be “null,” so that the point’s Out has a null status in this condition. Depending on the specific control sequence and usage of the writable point, this may be an effective solution.
However, note that by default, a “set” action exists on any writable point, which writes directly to the Fallback value. See
“About set (Fallback) action” on page 56. If you want a writable
point to always have a Fallback of “null,” go to its slot sheet and set the “Hidden” config flag on the “set” slot. Otherwise, a user can invoke a right-click command to set Fallback to any
value. For more details, see “Modifying default actions” on page 57.
Priority linking rules
When linking to the priority inputs of a writable object, you may notice these default rules:
• Only one link per input (level).
• Levels 1 and 8 are unavailable for links. If a BooleanWritable, level 6 is also unavailable.
See “About minimum On and Off times” on page 83.
Note: Both rules vary from the r2 Niagara priority input scheme, where a single priorityArray input was used for a writable object (AnalogOutput, BinaryOutput, and so forth). That input could be linked to multiple priority type outputs, including those with duplicate priority levels and/ or levels also used for object commands (emergency and manual).
Priority level conventions
The 16 priority levels used by writable points are modeled after corresponding BACnet priority levels, using the following conventions, from highest to lowest:
1. Emergency (Manual Life Safety)—Unlinkable input, but available as action (command).
2. Automatic Life Safety
3. User Defined
4. User Defined
5. Critical Equipment Control
6. Minimum On/Off (BooleanWritable meaning only, see “About minimum On and Off times”
)
7. User Defined
8. Override (Manual Operator)—Unlinkable input, but available as action (command).
9. Demand Limiting
10. User Defined
11. Temperature Override
82
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About composites About minimum On and Off times
12. Stop Optimization
13. Start Optimization
14. Duty Cycling
15. Outside Air Optimization
16. Schedule
Note: Although priority levels are patterned after BACnet, there is no direct linkage to BACnet priorities, even with BACnet writable proxy points. Priority inputs of all AX writable points are strictly a station-centric NiagaraAX implementation.
About minimum On and Off times
Each BooleanWritable point has built-in timers to specify minimum on and/or minimum off times.
The respective point properties are “Min Active Time” and “Min Inactive Time.” Usage is optional, and both properties work independently. Typical usage is to prevent short-cycling of equipment controlled by the point.
Default property times for a BooleanWritable are all zeros (“00000h 00m 00s”), which effectively disables a timer. In either property, you can specify any value needed using of a mix of hours (h), minutes (m), and seconds (s) to enable that timer.
A minimum timer is triggered by a state change transition to active or inactive. This results in the new state value being stored in the point’s priority array (at priority level 6) for the duration of that timer.
While a minimum timer is in effect, only input changes at a higher priority (5 or above) or an emergency action can affect the Out value.
For example, a BooleanWritable point controls a fan, with related properties set as follows:
• Min Active Time:00000h 01m 30s
Specifies that once started, the fan must run at least 90 seconds.
• Min Inactive Time:00000h 03m 5s
Specifies that once stopped, the fan must remain stopped at 3 minutes, 5 seconds.
Starting with the fan stopped at schedule level (priority 16), if a user gives it a manual override on
(priority level 8), the fan will run for 90 seconds at priority level 6 (a higher level). After this period, the fan continues running at the override 8 level for the duration of the override.
During the initial 90 seconds, a different override action (off or auto) will be ineffective—as the
higher priority level 6 remains in control. See “Priority level conventions” on page 82.
Once stopped, the point’s minimum off time will keep the fan off at priority level 6 for the specified duration (in this example, 3 minutes and 5 seconds). During this period, only an emergency command or input change at In2—In5 can effect further change.
About composites
Currently, a composite is something that Workbench allows you do to virtually any component in a station, notably control points and objects, and even folders that contain control logic. When you
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
83
About composites
Chapter 3 — Data and Control Model
Some composite examples make a composite, you expose slots of child components in the glyph (object shape) of that parent
(composited) component. This can simplify linking and promote reuse of control logic.
Caution: Composites have associated issues—see
“Composite issues” on page 88. For now, you
should avoid making folder composites in your control logic, and instead use the composite feature only at the point/object level to expose extension slots (if necessary). See exam-
ple “Point-level composite” on page 84.
When you composite a component (say a control point, meaning its contents), you select specific slots in child components (say, properties and/or actions of its extensions) to be “exposed” in the
“shape” of that point. Then, when looking at that point in the wire sheet view of its parent folder, you can see exposed properties of children as linkable slots (and/or available actions).
Note: If you are familiar with Niagara r2, the composite concept is similar to “Bundle” or “Composite” objects, only more flexible—you can expose slots in containers many levels down, for example. However, please see the
Some composite examples
A few simple examples of composites are included here, as follows:
•
•
Point-level composite
shows a proxy NumericPoint representing a space temperature value that has two extensions:
• an alarm extension (OutOfRangeAlarmExt)
• a history extension (NumericInterval)
Figure 28 Property sheet of proxy point with two extensions
In this example, when another system-related BooleanWritable (representing the system fan) has a false (Off) status, it is desired that this temperature point be:
• disabled from alarming, and
• disabled from continued history collection
84
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About composites Some composite examples
To achieve these “disable” functions, you must link the controlling source fan out to a slot of each
extension (visible in point’s wire sheet view, but not in the parent wire sheet for the point itself). Furthermore, other kitControl objects needed. Without making a composite, the necessary objects and links may appear as shown in
.
Figure 29 Proxy point example without composite kitControl objects
Proxy
NumericPoint
Proxy point’s wire sheet
(with linked extensions)
Notice that when looking at the proxy NumericPoint in the wire sheet of its parent folder, it is not apparent that this point has linked extensions.
By making a composite of the NumericPoint (acting as the container for both the extensions plus the
now-composited NumericWritable linked to the controlling BooleanWritable, and the wire sheet view of the NumericWritable that contains the needed kitControl objects.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
85
About composites
Figure 30 Proxy point as composited container
Chapter 3 — Data and Control Model
Some composite examples
In this example, the exposed input slots in the composite were renamed from “In” to “almInhib” and
“histStop” respectively, to clarify what each does. When looking at the Composite Editor for this example NumericPoint, it appears as shown in
.
Figure 31 Composite Editor for example NumericPoint
Folder-level composite
Note: Please see the related
shows a simple example of three Math objects chained together, located in a “LogicA” folder. Together, they perform a “Celsius to Fahrenheit” conversion. A NumericWritable is also shown linked to the first Math object to test.
86
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 3 — Data and Control Model
About composites
Figure 32 Simple example of folder before compositing
Some composite examples
If this application was needed later, you could copy all 3 linked objects again and insert in another
(perhaps already crowded) wire sheet. However, the middle “Multiply” object reveals an intermediary result that is distracting. Or, you could just create a new subfolder with only the 3 linked objects and then link directly to the child objects as needed (however, it would not be obvious from the parent’s wire sheet that links to children in that folder were established).
It would be better to “encapsulate” this into a single object with only a single “input” (degrees F) and single “output” (degrees C). You can do something like this by compositing the parent container, in this example folder “FolderA.”
In this case, you would want to delete the link from the test NumericWritable first, then open the
Composite Editor for the parent component FolderA ( Figure 33 ). The Composite Editor lets you
expand the tree of all contained components and “expose” those items of interest.
Figure 33 Launching and using the Composite Editor
In this example, only the “In A” of the first math object and the “Out” of the third math object is selected to be exposed. The Composite Editor provides a tree pane showing slots of points and objects
(by clicking the expand controls), and a slot is exposed by simply double-clicking it. Other controls in the editor are available to rename, remove, reorder and reverse exposed items, but are not used here.
(For more details, see Making a composite.)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
87
About composites
Chapter 3 — Data and Control Model
Composite issues
After clicking OK to perform the composite, the item composited (in this example, “LogicA”) shows exposed slots when viewed in its parent’s wire sheet.
shows the test NumericWritable now linked to the composited LogicA folder.
Figure 34 Example LogicA folder showing exposed input and output
You could later reopen this folder’s Composite Editor and rename the exposed properties differently, perhaps “inDegF” and “outDegC” (to make the purpose of the composited folder clearer). This would not affect the three (child) math objects in any way.
Composite issues
Although composites can simplify linking and make understanding logic flow easier, they always introduce performance issues. Perhaps the biggest issue is that once you link a dynamic value to a composite, for example the “out” of a proxy point, it essentially “pinned” into the “subscribed” state.
This means that proxy point will always be polling (regardless of any other usage).
In addition, each item exposed in a composite represents a link, where each link consumes some small amount of station resources. If used excessively, composites could noticeably reduce the total capacity of the station.
88
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
What are networks?
Driver architecture
Where are networks located?
In any NiagaraAX station, one or more driver networks are used to fetch and model data values. Data is modeled with proxy points, lower-tier components in that driver’s architecture. For more details,
see “About proxy points” on page 74.
To support a driver’s proxy points, the station must have that driver’s network architecture.
The following main topics apply to common driver architecture:
•
•
•
•
•
•
•
•
•
About Histories extension views
•
About Schedules extension views
•
What are networks?
Networks are the top-level component for any NiagaraAX driver. For drivers that use field bus communications, such as Lonworks, BACnet, and Modbus (among many others), this often corresponds directly to a physical network of devices. Often (except for BACnet), the network component matches one-to-one with a specific comm port on the NiagaraAX host platform, such as a serial
(RS-232 or RS-485) port, Lonworks FTT-10 port, or Ethernet port.
Note: A BacnetNetwork component is unique because it supports multiple logical BACnet networks, which sometimes use different comm ports (e.g. if a JACE-4/5 with BACnet MS/TP, one or more RS-485 ports). See the Bacnet User Guide for more details.
Other “non field bus” drivers also use a network architecture, for example the Ndio (Niagara Direct
Input / Output) driver has an NdioNetwork to interface to physical I/O points on the host JACE (Ndio applies only to a JACE model with onboard I/O or with an attached hardware I/O board). Also, “database” drivers also use a network architecture, for example the “rdbSqlServer” driver includes an
RdbmsNetwork. (Database drivers apply only to Supervisor or SoftJACE hosts.)
Where are networks located?
In any NiagaraAX station, all driver networks are located under the
component in
the station’s database (“Drivers” in the root of the station, as shown in Figure 1).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
89
Chapter 4 — Driver architecture
Network component hierarchy About Network architecture
Figure 1 DriverContainer in Nav tree
Note: Currently, all stations require a
NiagaraNetwork . It may be used to model data in other Niaga-
raAX stations. Also, it contains the NiagaraFoxService required for Workbench-to-station
communications. For more details, see “About the Niagara Network” on page 149.
By convention, you should keep all driver networks located under the station’s Drivers con-
tainer—it is a special component with a view that provides some utility. See “About the Driver
Manager” on page 93 for more details.
About Network architecture
To represent any driver in a station database, a consistent “driver framework” using a network architecture is used. This includes the upper-tier parent network component, and one or more child device components, each with device ext (extension) child components.
The following sections explain further:
•
•
•
•
Network component hierarchy
Hierarchically, the component parentage is: network, device, device extensions, points ( Figure 2 ).
Figure 2 Example driver architecture (Bacnet)
90
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Network architecture About network components
To simplify driver modeling, the New Station wizard automatically creates the necessary “Drivers” container, complete with a NiagaraNetwork (and its required component slots).
• If engineering a JACE station, you invariably add additional driver networks, opening the driver’s
palette and copying the network-level component into Drivers. Or, you can use the New
button in the Driver Manager. Examples are a LonNetwork or BacnetNetwork.
• If engineering a Supervisor (PC) station, the NiagaraNetwork may be the only one needed.
Optionally, you may add a “database” network (providing the PC host is licensed for it). And, if a
PC host licensed as a direct “integration Supervisor” (e.g. BACnet Supervisor), you may add a driver network (e.g. BacnetNetwork) directly into its Drivers container.
Note: Regardless of host platform, in most cases the network component is the only item you need to manually copy from that driver’s palette. After that, you use “manager views” to add child components like devices and proxy points, even if programming offline.
This enforces the correct component hierarchy under that driver as you engineer, and helps coordinate mechanisms used by the driver for communications. Exceptions to this rule are noted
(as applicable) in other documentation about NiagaraAX drivers.
About network components
A network component (“generically”: DriverNetwork) is the top-level component for any driver, and by default has mandatory (frozen) component slots, such as:
•
“Health” and other status properties—see “Network status properties” on page 95.
•
AlarmSourceInfo—see “About network Alarm Source Info” on page 96.
•
PingMonitor—see “About Monitor” on page 96.
• TuningPolicyMap—see
“About Tuning Policies” on page 98.
Access these slots in the DriverNetwork’s property sheet (Figure 3).
Figure 3 Example BacnetNetwork property sheet
Note: Depending on the specific driver, there may be additional slots in the DriverNetwork. For example, if a field bus network, there may be “PollScheduler” and/or “CommConfig” slots.
Some of these may require proper configuration before driver communications occur. See
“Additional network components” on page 103.
The DriverNetwork is also the parent container for all device-level components. Devices list in tabular format in the default view for that network, the DeviceManager. See
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
91
About Network architecture
Chapter 4 — Driver architecture
About device components provides this), use discover features.
About device components
A device component (“generically”: DriverDevice) is a second-tier component for any driver, and by default has mandatory (frozen) component slots, such as:
•
“Health” and other status properties—see “Device status properties” on page 114.
Note: Depending on driver type, a device typically has other properties. For example, if a device under a field bus, it may have a “Device Address” property, or a similar properties. See
“Driver-specific device slots” on page 116.
• One or more device extensions—for example “Points” (DriverDevicePointExt). See
“About device extensions” on page 92.
Typically, the property sheet is the default view for a device component—you can access device prop-
erties, slots, and its extensions using the device’s property sheet (Figure 4).
Figure 4 Example BacnetDevice property sheet
extensions (e.g. “Points”) are visible under the device when you expand it in the nav tree.
Figure 5 Example BacnetDevice extensions in Nav tree
About device extensions
A device extension is a child of a device, and represents some functionality of the device. Each extension contains properties and other components. Device extensions are container components, often with one or more special views. For more details, see
“Types of device extensions” on page 116.
92
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Driver Manager Driver Manager New and Edit
For example, in any of the field bus networks, each device has a Points extension, the parent container for proxy points. The default view of the Points extension is the Point Manager, which you use to cre-
ate and manage proxy points. See “About the Point Manager” on page 121 for details.
Note: Device extensions are required (frozen) components of a device—you cannot delete them.
They are created automatically when you add a device to the station database. This varies from the “point extension” model, where you individually add/delete extensions under control points and components.
About the Driver Manager
The Driver Manager is the default view for the DriverContainer (showing all networks) in a station.
shows an example Driver Manager for a JACE station.
Figure 6 Driver Manager
By default, each driver network lists showing its name, a type description, a real-time status field, whether it is enabled, and a fault cause field (empty, unless the network is in fault).
Within the Driver Manager view, network-level operations are available:
• Double-click a network to go to its Device Manager view. See
“About the Device Manager” on page 105.
• Right-click a network to see its popup menu, including available actions. Available actions will vary by driver, but may include “Ping,” “Upload,” and “Download” as examples.
Driver Manager New and Edit
Buttons at the bottom of the Driver Manager include:
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
93
About the Driver Manager
Chapter 4 — Driver architecture
Driver Manager New and Edit
Note: New and Edit are also on the Driver Manager toolbar and the Manager menu.
New
The New button in the Driver Manager allows you to add a new driver network to the station. This is equivalent to copying a driver network component from that driver’s palette. The New dialog pro-
vides a selection list for network type, and also the number of networks to add (Figure 7).
Figure 7 New dialog in Driver Manager
Note: Currently, you are allowed to add multiples of any driver network, as well as any network type
(regardless of the station’s host platform). However, please understand that many networks should be “one-only” per station, e.g. a NiagaraNetwork and BacnetNetwork. Also, consider that networks shown in the selection list reflect only the modules available on your Workstation, and may not be present (or supported) on the target NiagaraAX host.
Edit
The Edit button in the Driver Manager allows you to rename a selected network, or to set it to dis-
Figure 8 Edit dialog in Driver Manager
Caution: Whenever you set a network to disabled (Enabled = false), the network component and all
child driver components (all devices, proxy points, etc.) change to disabled status. If a field bus driver, communications routines like polling and device status pings also suspend. By default, disabled status color is gray text on a light gray background.
This network-wide action may be useful for maintenance purposes. Note that Enabled is
94
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common network components Network status properties also individually available at the device-level and proxy point-level, using the Edit button/ dialog in the Device Manager or Point Manager, respectively.
A disable at the device-level disables all child (proxy points), as well as polling to that points under that device. A disable at the proxy-point level disables the single point.
Common network components
Each driver network contains common properties and other components. This section describes those items.
•
•
About network Alarm Source Info
•
•
•
Network status properties
Status
The Status property of a network indicates if the driver is capable of communications—for any configured driver, network Status is typically “{ok}.” However, when adding some networks, the initial
Status may be fault, as shown in Figure 9. This might mean a communications port is yet unassigned,
or there is a port conflict.
Note: A fault status also occurs if the host platform is not properly licensed for the driver being used. If a network fault, see the Fault Cause property value for more details.
Figure 9 Network status properties
Enabled
By default, network Enabled is true—you can toggle this in the property sheet, or in the Driver Manager (by selecting the network and using the
Edit button). See related Caution: on page 94.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
95
Common network components
Chapter 4 — Driver architecture
About network Alarm Source Info
Health
Network Health contains historical properties about the relative health of the network in the station, including historical timestamps.
About network Alarm Source Info
A network’s Alarm Source Info slot holds a number of common alarm properties ( Figure 10 ). These
properties are used to populate an alarm if the network does not respond to a monitor ping. See
for details on the monitor mechanism.
Figure 10 Example Network Alarm Source Info properties
Alarm Source Info properties work the same as those in an alarm extension for a control point. For property descriptions, see
“About alarm extension properties” on page 193.
Note: Each child device object also has its own Alarm Source Info slot, with identical (but indepen-
dently maintained) properties. See “Device Alarm Source Info” on page 115.
About Monitor
A network’s Monitor slot holds configuration for the “ping mechanism” used by the driver network.
In the network’s property sheet, expand the Monitor slot to see configuration ( Figure 11 ).
96
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common network components
Figure 11 Example Monitor properties
About Monitor
Monitor provides verification of the general health of the network, plus the network’s “pingables”
(typically, devices) by ensuring that each device is minimally “pinged” at some repeating interval.
• If a device responds to the monitor ping, device status is typically “ok,” and normal communications routines to it (proxy-point polling, plus reads of device schedules, trends, etc. if supported by the driver) proceeds normally. Typically, this applies even if the device returns an error response to the ping, because this indicates that the device is “alive.”
• If a device does not respond to the monitor ping, it is marked with a down status—this causes normal communications routines to that device to be suspended. Upon the next successful monitor ping to that device, device status typically returns to “ok” and normal communications routines resume.
Note: Whenever successful communications occur to a device, that device component’s Health property is updated with the current time. The network ping Monitor will only “ping” the device if the time of last health verification is older than the ping frequency. Therefore, in normal operation with most drivers, the proxy point polling mechanism actually alleviates the need for the monitor ping, providing that the ping frequency is long enough. Also, in most drivers if a point poll request receives no response (not even a “null”) from a device, a “ping fail” condition is immediately noted, without waiting for the monitor ping interval.
The following sections provide more Monitor details:
•
•
Monitor considerations by driver
Monitor properties
The monitor ping properties are as follows:
• Ping Enabled
• If true, (default) a ping occurs for each device under the network, as needed.
• While set to false, device status pings do not occur. Moreover, device statuses cannot change from what existed when this property was last true.
Note: It is recommended you leave Ping Enabled as true in almost all cases.
• Ping Frequency
Specifies the interval between periodic pings of all devices. Typical default value is every 5 minutes (05m 00s), you can adjust differently if needed.
• Alarm On Failure
• If true (default), an alarm is recorded in the station’s AlarmHistory upon each ping-detected
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
97
Common network components
Chapter 4 — Driver architecture
About Tuning Policies device event (“down” or subsequent “up”).
• If false, device “down” and “up” events are not recorded in the station’s AlarmHistory.
• Startup Alarm Delay
Specifies the period a station must wait after restarting before device “down” or “up” alarms are generated. Applies only if the Monitor’s property Alarm On Failure is true.
Monitor considerations by driver
The monitor mechanism used by a specific driver may have unique characteristics.
• For example, in a BacnetNetwork, any monitor ping is directed to the device’s BACnet “Device
Object,” and in particular, to its “System_Status” property. In this unique case, a received response of “non-operational” is evaluated the same as getting no response at all!
• Or, in any Modbus network, when a monitor ping message is sent, it is directed to the device’s
“Ping Address,” which is configured by several properties in the ModbusDevice object.
Other drivers may have specific considerations for the Monitor ping mechanism. For more information, refer to the “Device Monitor Notes” section within any NiagaraAX driver document.
About Tuning Policies
A network’s Tuning Policies holds one or more collections of “rules” for evaluating both write
requests (e.g. to writable proxy points) as well as the acceptable “freshness” of read requests from polling. In some drivers (such as Bacnet), also supported is association to different poll frequency groups (Slow, Normal, Fast). Tuning policies are important because they can affect the status of the driver’s proxy points.
In the network’s property sheet, expand the Tuning Policies (Map) slot to see one or more contained
Tuning Policies. Expand a Tuning Policy to see its configuration properties ( Figure 12 ).
Figure 12 Example Tuning Policies Map (Bacnet)
Note: Some driver networks do not have Tuning Policies, for example an RdbmsNetwork for a database driver. Also, the NiagaraNetwork has greatly simplified Tuning Policies.
By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (“Default Policy”).
98
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common network components About Tuning Policies
However, you typically create multiple tuning policies, changing those items needed differently in each one. Then, when you create proxy points under a device in that network, you can assign each point (as needed) to the proper set of “rules” by associating it with a specific tuning policy.
As a simple example (under a BacnetNetwork), you could duplicate the default tuning policy twice, naming the first copy “Slow Policy” and the second copy “Fast Policy.” Then, in each copy change the “Poll Frequency” property from “Normal” to “Slow” or “Fast,” respectively. You would then have
3 available (and different) poll frequency groups to pick from when you create and edit proxy points.
The following sections provide more Tuning Policy details:
•
•
Tuning Policy considerations by driver
Tuning Policy properties
Tuning Policy properties for typical field bus drivers are as follows:
• Min Write Time
Applies to writable proxy points, especially ones that have one or more linked inputs. Specifies the minimum amount of time allowed between writes. Provides method to throttle rapidly changing value so that only the last value is written. If property value is 0 (default), this rule is disabled
(all value changes attempt to write).
• Max Write Time
Applies to writable proxy points. Specifies the maximum “wait time” before rewriting the value, in case nothing else has triggered a write. Any write action resets this timer. If property value is 0
(default), this rule is disabled (no timed rewrites).
• Write On Start
Applies to writable proxy points. Determines behavior at station startup.
• If true, (default) a write occurs when the station first reaches “steady state.”
• If set to false, a write does not occur when the station reaches “steady state.”
• Write On Up
Applies to writable proxy points. Determines behavior when proxy point (and parent device) transitions from “down” to “up.”
• If true, (default) a write occurs when the parent device transitions from down to up.
• If set to false, a write does not occur when the parent device transitions from down to up.
• Write On Enabled
Applies to writable proxy points. Determines behavior when a proxy point’s status transitions from “disabled” to normal (enabled). Note this status can be inherited globally if the parent device was set to disabled (or network-wide if driver network was set to disabled).
• If true, (default) a write occurs when writable point transitions from disabled.
• If set to false, a write does not occur when writable point transitions from disabled.
• Stale Time
Applies to all proxy points.
• If set to a non-zero value, points become “stale” (status stale) if the configured time elapses without a successful read, indicated by Read Status “ok.”
• If set to zero (default), the stale timer is disabled, and points become stale immediately when unsubscribed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
99
Common network components
Chapter 4 — Driver architecture
About poll components
Note: By default, proxy point status “stale” is indicated by tan background color. In addition, stale status is considered “invalid” for any downstream-linked control logic. For more
details, see “About “isValid” status check” on page 74.
• Poll Frequency
(Currently in TuningPolicy of BacnetNetwork only) Applies to all proxy points. Provides a method to associate the tuning policy with one of 3 Poll Rates available in the network’s Poll Service: Fast Rate, Normal Rate, or Slow Rate. The default poll frequency is “Normal.”
Note: Depending on driver, there may be a single “Poll Service” (or “Poll Scheduler”) slot under the network, or as in the case of a BacnetNetwork, a separate “Poll Service” for each configured port (IP, Ethernet, Mstp) under its BacnetComm > Network container. The NiagaraNetwork uses subscriptions instead of polling.
Tuning Policy considerations by driver
Tuning policies used by a specific driver may have unique characteristics. For example, under a NiagaraNetwork, its TuningPolicy has only two properties: Min Update Time and Max Update Time. For more details, see
“NiagaraNetwork component notes” on page 149.
Other drivers may have specific considerations for tuning policies. For more information, refer to the
“Tuning Policy Notes” section within any NiagaraAX driver document.
About poll components
Many driver networks use a single polling mechanism (Poll component, named “Poll Service” or
“Poll Scheduler”) adjusted at the network level in the station. In the case of a BacnetNetwork, a sepa-
.
•
•
Note: The Niagara Network does not use polling, but uses subscriptions only.
100
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common network components
Figure 13 Example BacnetPollService
About poll components
Poll scheduler operation
Regardless of driver type, the Poll Service provides a “poll scheduler” that operates in the same fashion via an ongoing scan of four “buckets” to service “pollables” as follows:
• The poll scheduler allocates three “rate group” buckets, one for each rate group (Slow, Normal,
Fast). “Pollables” (mainly proxy points) are associated with one of three “rate” groups (Slow,
Normal, Fast) via either:
• assigned Tuning Policy in each point’s proxy extension (BacnetNetwork)
• assigned Poll Frequency in each point’s proxy extension (drivers other than Bacnet)
In the case of device objects, a
property is used to select the rate directly.
• A fourth “dibs stack” bucket is allocated for pollables that transition to a subscribed state. This may be a “temporary subscription,” such as results when viewing unlinked proxy points (without alarm or history extensions) in Workbench or a browser. Or, it may occur when a permanently subscribed point is first polled (thereafter, it is no longer is “dibs stack-polled”).
Priority of polling by the scheduler occurs in this fashion:
1. Dibs stack. When first subscribed, a pollable moves to the top of the dibs stack (first dibs). The poll scheduler always polls the dibs bucket before doing anything else. The dibs stack is polled last-in, first-out (LIFO). As long as entries are in the dibs stack, they are polled as fast as possible with no delays.
2. When the dibs stack is empty, the scheduler attempts to poll the components in each “rate” bucket using an algorithm designed to create uniform network traffic.
For example, if the fast rate is configured to 10 seconds and there are 5 components currently subscribed in the fast bucket, then the scheduler will attempt to poll one component every 2 seconds.
Note: Every ten seconds the poll scheduler rechecks the buckets for configuration changes. So if a pollable’s configuration is changed from slow to fast, it takes at most ten seconds for the change to take effect.
Poll statistics are also updated every ten seconds. You can manually reset the statistics by issuing the
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
101
Common network components
Reset Statistics action to the Poll Service ( Figure 14
).
Figure 14 Reset Statistics action of PollService
Chapter 4 — Driver architecture
About poll components
Poll component properties
Properties of the poll component for typical field bus drivers include four writable properties and various read-only statistics properties, as follows:
• Poll Enabled
• If true (default), polling occurs for all associated pollables (proxy points, devices) under the network component, or if a BacnetPoll, under that BacnetStack, Network, Port.
• While set to false, polling is suspended and further value updates from polling do not occur.
Note: PollService actions Enable and Disable allow access to this property, see
• Fast Rate
Target poll interval for pollables assigned to this rate group (default often is 1 second).
• Normal Rate
Target poll interval for pollables assigned to this rate group (default often is 5 seconds).
• Slow Rate
Target poll interval for pollables assigned to this rate group (default often 30 seconds).
Note: All remaining properties are read-only statistics properties.
• Statistics Start
Timestamp reflecting either the last manual reset of poll statistics, or if statistics have not been reset, the first “steady state” time immediately following the last station restart.
• Average Poll
Average time spent in each poll.
• Busy Time
Percentage of time spent busy doing polls.
• Total Polls
Total number of polls made and time spent waiting for polls to execute.
• Dibs Polls
Total number of polls made processing the dibs stack.
• Fast Polls
Total number of polls processing fast queue.
• Normal Polls
Total number of polls processing normal queue.
• Slow Polls
Total number of polls processing slow queue.
102
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common network components Additional network components
• Dibs Count
Current and average number of components in dibs stack.
• Fast Count
Current and average number of components in fast queue.
• Normal Count
Current and average number of components in normal queue.
• Slow Count
Current and average number of components in slow queue.
• Fast Cycle Time
Average cycle time of the fast queue.
• Normal Cycle Time
Average cycle time of the normal queue.
• Slow Cycle Time
Average cycle time of the slow queue.
Note: Depending on driver, additional statistics properties may be present in a Poll component. For example, a BacnetPoll has additional properties Device Count, Point Count, and Object
Count. See the specific driver document for unique Poll Service features or notes.
Additional network components
Depending on the driver type, a network typically includes other components that define communications settings. Access these components on the property sheet of the network. More details are in the following subsections:
•
About communication components
•
About driver-specific properties
About communication components
Communication components contain properties and possibly other components that configure and represent communications ports, or other protocol layers. These components will vary from driver to driver. Often, you must configure (or verify) these components to allow online operations.
For example, the NiagaraNetwork contains the NiagaraFoxService, a BacnetNetwork contains a Bac-
netStack (Bacnet Comm), a LonNetwork contains LonCommConfig ( Figure 15 ).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
103
Common network components
Figure 15 LonNetwork’s LonCommConfig component
Chapter 4 — Driver architecture
Additional network components
See the driver document for specific details on configuring a network’s communications components.
About driver-specific properties
Depending on the driver, other specific properties (or even component containers) may be found in the network component’s property sheet.
For example, the NiagaraNetwork has container components Fox Service and History Policies, a
ModbusAsyncNetwork contains a number of properties for timeouts and byte-order conventions, and a LonNetwork contains a LonNetmgt component with various child properties (
).
Figure 16 LonNetwork’s LonNetmgmt component
For more details see
“About the Niagara Network” on page 149, or the corresponding driver docu-
ment for driver-specific properties and components of a network.
104
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Device Manager
About the Device Manager
Device New Folder and New
The Device Manager is the default view for any network container (for a NiagaraNetwork only, this view is called the Station Manager). The Device Manager is a table-based view, where each row represents a unique device (
). When building a network in the station, you use this view to create, edit, and delete device-level components.
Figure 17 Example Device Manager (BacnetDeviceManager)
Following station configuration, this view provides a status and configuration summary for all devices networked using that driver. The “Exts” column provides quick double-click access to device
extensions, such as Points for proxy points, Schedules for imported schedules, and so forth (see
devices, such as “ping,” upload, and so forth.
At the bottom of the view, buttons “New Folder” and “New” let you create new device folders and devices in the station database. The “Edit” button lets you edit one or more selected devices in the station database. If the driver supports online “device learning,” buttons “Discover,” and “Match” are also typically available. Finally, additional buttons may be available, depending on the driver.
For more details, see:
•
•
•
About Device Discover, Add and Match (Learn Process)
•
Device New Folder and New
New exist in the Device Manager view of a device-level component under
any driver network. Use of New Folder is optional. Typically, you use
New only if the driver does not
support online discovery, or if you are programming offline.
Note: New Folder and New are also on the Device Manager toolbar and the Manager menu.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
105
About the Device Manager
Chapter 4 — Driver architecture
Device New Folder and New
New Folder
The New Folder button in the Device Manager adds a special “DeviceFolder” component you can use to organize devices. This is equivalent to copying that same component from that driver’s palette.
A Name dialog lets you name the folder before it is created (
).
Figure 18 Example New Folder dialog in Device Manager
When you click OK, a new DeviceFolder component is added under the network.
Note: A driver’s DeviceFolder component is different than a “normal” Folder component, as it provides that driver’s Device Manager view by default (just like the parent network component).
Also, an “All Descendants” command is available from the root Device Manager, which
allows you to see all devices in the network.
All Descendants
When in the Device Manager of a device folder, it is “unaware” of devices in other device folders (or in the root of the network component). However, from the root Device Manager view (of the network), you can “flatten” the folder structure to view all devices by selecting it from the Manager
menu ( Figure 19 ) or by simply clicking the “All Descendants” tool on the toolbar (
).
Note: Be aware that in a large network, with many device folders and devices, using the all descendants feature may decrease performance. This might result from so many devices/points being subscribed.
Figure 19 Manager menu “All Descendants” command
106
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Device Manager
Figure 20 Device Manager “All Descendants” tool on toolbar
Device Edit
Note: If you are using device folders, and you click on a table to column to resort devices, please be aware that any device-to-device folder organization is lost during that view. However, you can always see contents of device folders clearly in the Nav tree, and again when returning to the
Device Manager view from another view.
New
The New button in the Device Manager allows you to add a new device component to the station.
This is equivalent to copying a device component from that driver’s palette. The New dialog provides
a selection list for device type, and also the number of devices to add ( Figure 21 ).
Figure 21 Example New dialog in Device Manager
When you click OK, a new device-level component is added under the network. You usually need to edit specific details for each new device, including addressing parameters for communications.
Device Edit
In the Device Manager view, you can edit any device component in the station database by simply double-clicking it. (Editing does not apply to device folders.)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
107
About the Device Manager
Edit
The Edit dialog appears with the device listed (
).
Figure 22 Example Edit dialog in Device Manager (single device)
Chapter 4 — Driver architecture
Device Edit
Note: The Edit dialog for a device component only shows some of the device component’s properties. Typically, these are key properties required for communications, and will vary among drivers (to access all properties of the device component, go to its property sheet).
When a single device is selected in the Edit dialog, you can edit any property except Type (it was fixed when you added the device). Included is the ability to edit the Name of the device in the station. This is equivalent to the right-click Rename command on the component.
The following related topics also apply:
•
•
Device “gang” edits
The Edit button in the Device Manager allows you to edit one or more device components in the station in a single dialog. Before clicking Edit, use standard Windows keyboard controls to highlight
(select) multiple devices (e.g. hold down Ctrl key and click desired devices).
Note: Edit is also available on the Device Manager toolbar and the Manager menu.
The “gang” edit feature is useful for making the same change in multiple (selected) devices. For
example, as shown in Figure 23 , you can change “Poll Frequency” in multiple devices at the same
time (versus editing this individually).
108
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Device Manager About Device Discover, Add and Match (Learn Process)
Figure 23 Example “gang edit” in Edit dialog in Device Manager
When you have the Edit dialog open with multiple devices, you can also click on select ones to make individual edits (e.g. Name, or any other editable property), during the same dialog session where you made “gang” property edits. When you click OK, all the changes are applied to the device components as made during your Edit session. For more details, see “About gang edits.”
Note: When you have multiple devices selected in the Edit dialog, properties that must be unique
(such as Name) are automatically unavailable (dimmed). However, note that some properties that typically should be unique (often address properties) may still be available for “gang edit,” as this rule is not automatically enforced. Typically, when editing these properties, you should verify only a single device component (row) is highlighted in the table.
About Device Discover, Add and Match (Learn Process)
Online “device learns” are possible using the
Device Manager for many drivers, for example the Nia-
garaNetwork, BacnetNetwork, LonNetwork, and NdioNetwork. Whenever available, this method is the easiest way to accurately add device components to the station database.
Note: With the exception of a “Quik Learn” option in a LonNetwork, any device learn in NiagaraAX is a two-step process where you first:
1.
Discover device candidates for inclusion in the station database.
2. Select and
Add from those candidates, creating device components in the network.
If you already added devices using New
, you can also Match candidates to existing devices. For
more details see “Match (Device)” on page 111.
The Device Manager reinforces this process by providing two separate panes in the view whenever you enter “Learn Mode.” See
“About Learn toggle” on page 109.
About Learn toggle
Any driver that offers online “learns” of devices, points, and possibly schedules and log data (histo-
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
109
About the Device Manager
Chapter 4 — Driver architecture
About Device Discover, Add and Match (Learn Process) ries) provides specialized “Manager” views. Any such view offers both a two-pane view (Learn
Mode) and a single-pane view (Database only).
At any time, you can toggle between Learn Mode and the single-pane (Database) view by clicking the
Learn Mode tool in the toolbar ( Figure 24
), or using the Learn Mode command in the Manager menu.
Also, note that the Discover tool (binoculars) is next to the Learn Mode tool.
Figure 24 Learn Mode toggle tool in any Manager
Note: Whenever in Learn Mode of any Manager view (DeviceManager, PointManager, and so forth) you can drag the border between the two panes to resize, as necessary.
Discover
The Discover button is available in the Device Manager only if the driver supports online discovery.
When you click Discover, the Device Manager view splits into two panes (Learn Mode), and at the
same time typically launches a discovery “job” ( Figure 25 ).
Figure 25 Discover splits Device Manager view
Note: In some drivers, an intermediate dialog may appear before the discovery job begins. For example, in a discover for a BacnetNetwork, a “Configure Device Discovery” dialog allows you to limit possible ranges of devices, before discovery begins. For more details, see the Bac-
net Users Guide.
The two panes in the Device Manager operate as follows:
110
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Device Manager Match (Device)
• Discovered (top pane)
Lists devices discovered on the driver’s network, as candidates. Any device found that already
exists in the station database appears “ghosted” (faintly listed). A job “progress bar” is also included on top of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists devices and device folders that are currently in the station database.
Add
The Add button is available in the Device Manager in Learn Mode when you have one or more devices selected (highlighted) in the top Discovered pane. When you click Add, an Add dialog appears that allows you to edit items before the device component(s) are created in the station data-
Figure 26 Add dialog from Add button in Device Manager
The Add dialog is nearly identical to the device Edit
dialog, but allows you to edit Type as well as other device properties. Often, device address properties in the Add dialog already have acceptable values for operation (otherwise, communications to that device would not have occurred). Often, you change only Name, unless you know other settings you wish to change. You can always Edit the device component(s) after you click OK and add them to your station.
Note: When you have one or more devices selected in the top Discovered pane, an Add tool is also available on the toolbar (“plus” symbol), as well as a command in the Manager menu. Also, you can simply double-click a discovered device to bring it up in the Add dialog.
Match (Device)
Device Match is a feature that may be useful when you have an application replicated many times at
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
111
About the Device Manager
Chapter 4 — Driver architecture
Match (Device) the device level, or if you have programmed offline using the New device feature.
• In the first case (replicated device application), you could discover and add one typical device, and complete further engineering under it (learning and adding proxy points, point extensions, creating other control logic, adding Px views, including all self-contained links and bindings).
Then, you could duplicate that typical device component (choosing Duplicate in its right-click menu) for as many identical devices as exist. The Match feature now allows you to match each duplicated device component to a unique discovered device, saving engineering time. This repopulates the necessary properties of the duplicated device object with the correct values from the discovered device.
• In the second case (offline programming) where a connection to the actual device network is unavailable, you can manually add
New devices and begin station engineering of a driver net-
work. Typically, most component creations under a driver network are possible (including all levels) using the New feature in the various “manager” views (Device Manager, Point Manager, other device extension managers). Or, you can add saved applications (from the device level on down) and edit as necessary. Then, when online with the driver network later, you could use
Match to “sync” to existing components (device-level, proxy points, and so forth).
The Match button in the Device Manager becomes available when in Learn Mode, and you have:
1. Selected one device candidate in the top (Discovered) pane.
2. Selected one existing device component in the bottom (Database) pane.
Note: In this case, the toolbar also has an available Match tool, and the Manager menu has a Match command.
When you click Match, the Match dialog appears, as shown in Figure 27 .
Figure 27 Match dialog example in Device Manager
Note: Match is strictly a “one-to-one” function for “discovered-to-database”—note that it is unavailable any time you have multiple items selected either in either the top or bottom pane.
The Match dialog is nearly identical to the single-device Edit
dialog, and typically provides the “discovered” device address values. Often, most properties in the Match dialog already have acceptable device address values required for operation (otherwise, communications to the discovered device would not have occurred). You can always Edit the device component after you click OK and add it to
112
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Device Manager Manager table features your station.
Manager table features
As with other table-based views in Workbench, manager views of various components under a driver’s network provide common features that can be useful (see “About table controls” for a general overview). These features apply to various component views found throughout a station’s driver architecture, for example, the
Of particular utility are the following table features:
•
•
Table options menu
Use the table options drop-down menu (small control in upper table right, as shown in
) to perform any of the following:
Figure 28 Table options menu in Device Manager
• Reset Column Widths
Useful if you manually changed widths of columns, and now some contents are hidden (even after scrolling). The reset restores all columns to widths that accommodate contents.
• Export
Produce the standard Export dialog, where you can select exporting the table to PDF, text, HTML, or CSV (comma separated variable). See “About table exports” for more details.
• select or clear columns for display
Depending on the driver, a certain “default” collection of columns is pre-selected for display in the Manager view. You can change that by checking or clearing column headings.
Column resorting
Click on any column header to toggle the table sort between ascending (first click) and descending
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
113
Common device components
Chapter 4 — Driver architecture
Device status properties
(second click). The current table sort is indicated by a small triangle in the sorting column.
Common device components
Each device component has some number of required (frozen) slots and properties, which will vary by driver. However, the following categories of components and slots are typical to most device-level components:
•
•
•
•
Also, a device component has one or more device extensions, which are visible when you expand the
device in the Nav tree. For more details, see “Types of device extensions” on page 116.
Device status properties
Status
The Status property of a device indicates whether it is communicating—good status is “{ok}” (no status flags). However, if using
to add a device, initial Status may be fault, as shown in Figure 29.
This could mean device address properties are yet unassigned, or are misconfigured.
Note: If a device status fault, see the Fault Cause property value for more details.
Figure 29 Device status properties
Status of devices is verified by successful polling, or the device status “ping” as configured in the network component’s Monitor configuration. See
From the Device Manager view, you can also right-click a device, and from the popup menu select
Actions > Ping
to manually verify communications.
Depending on conditions, a device may have one of various status flags set, including fault or disabled, or others in combination, such as down, alarm, stale, and/or unackedAlarm. In the Device
Manager, non-ok status in indicated for any device by row color other than white.
114
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Common device components Device Alarm Source Info
Enabled
By default, device Enabled is true—you can toggle this in the property sheet, or in the Device Manager (by selecting the device and using the
Health
Device Health contains historical properties about the last successful message received from the device, including timestamps.
Device Alarm Source Info
A device’s Alarm Source Info slot holds a number of common alarm properties ( Figure 10 ). These
properties are used to populate an alarm if the device does not respond to a monitor ping. This ping is
configured at the network level—see “About Monitor” on page 96.
Figure 30 Example Device Alarm Source Info properties
These properties work the same as those in an alarm extension for a control point. For property
descriptions, see “About alarm extension properties” on page 193.
Note: Each parent network component also has its own Alarm Source Info slot, with identical (but independently maintained) properties.
Device address properties
Depending on the driver, a device-level component typically has one or more address type properties, accessible from the device’s property sheet. For example, a BacnetDevice has an Address property with 3 separate fields (
).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
115
Chapter 4 — Driver architecture
Driver-specific device slots Types of device extensions
Figure 31 Example device address properties
In the case of a Lon device (DynamicDevice) various address parameters are stored under a Device-
Data component, itself visible when you expand the device in the Nav tree. For more details on device-level address properties, see the specific driver document.
Poll Frequency
Common to most devices is a Poll Frequency property, typically located below device address properties. It provides a drop-down menu to select among 3 poll frequencies, as configured in the network’s
Poll Service. For more details, see
“About poll components” on page 100.
Driver-specific device slots
A device-level component typically has slots unique to that driver, accessed on its property sheet. For example, a Lon device has a large collection of nv slots (network variables nvi, nvo, and nci), each as an expandable container holding numerous values. A BacnetDevice holds a number of properties that define Bacnet “services” that it supports. For details, see the specific driver document.
Types of device extensions
When you create a device-level component ( New
, Add , or simply drop from the driver’s palette), you
may notice that it has default children, collectively called device extensions. Device extensions group various functions of a device.
Note: For any device, its extensions are visible both in the Nav tree and in the Device Manager view
(
), providing double-click access to each extension’s default view.
116
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Types of device extensions
Figure 32 Device extensions in Nav tree and Device Manager
About the Points extension
Perhaps the most important of all device extensions is the Points extension—the container for all proxy points (representing data originating from that device).
Types of Device extensions include:
• Points extension—see
“About the Points extension” on page 117.
• Histories extension—see
“About the Histories extension” on page 118.
• Alarms extension—see
“About the Alarms extension” on page 119.
• Schedule extension—see
“About the Schedules extension” on page 120.
About the Points extension
A device’s Points extension (or simply Points) serves as the top parent container for real-time data values originating from that device.
Figure 33 Points under a Lon device
These values are “proxied” using NiagaraAX control points, or proxy points. Values can be both read
“About proxy points” on page 74.
Note: You create all proxy points using the Point Manager view of Points—simply double-click
Points under any device component, or right-click Points and select Views > Point
Manager
. See “About the Point Manager” on page 121 for more details.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
117
Types of device extensions
Chapter 4 — Driver architecture
About the Histories extension
About the Histories extension
Not all drivers have devices with a HistoryDeviceExt—notably, this exists only if the driver protocol
(or device) provides local data logging. Currently, this device extension exists only under compo-
and BacnetDevice (under a BacnetDevice it is named “Trend Logs”).
Figure 34 Histories device extension (NiagaraStation)
A device’s Histories extension serves as the parent container for history descriptors—components that specify how history-type collections (log data) are imported or exported. By default, it also contains a Retry Trigger, see
“About the Retry Trigger” on page 119.
Note: Creating history import and history export descriptors is how you save a Niagara history to a different location (station) from where it originated. In a typical application, this is considered
archiving. For example, an originating history (with a limited record count) may be in a JACE station. If imported to a supervisor station, its history import descriptor can be configured such that the imported history in the supervisor has “unlimited” record capacity. The JACE history can run collecting only the last 500 records, while the imported history in the supervisor will collect all (unlimited) records.
The difference between a history import and history export are as follows:
• Import
An imported history appears in the local station as a Niagara history, where data is effectively
“pulled” from a remote source device.
• If configured by a history import descriptor under Histories of a NiagaraStation device, the source is another Niagara history in that remote station.
• If configured by a history import descriptor under Trend Logs of a BacnetDevice, the source is a BACnet Trend Log object residing in that BACnet device.
• Export
(NiagaraStation only) An exported history is a Niagara history that exists in the local station, and is configured by a history export descriptor to “push” its data to a remote NiagaraStation. This adds it to the histories in that remote station.
Note: Under a BacnetNetwork, the single “LocalDevice” component (that represents station data exported to BACnet) has a special view on its child Export Table component that permits exporting station histories as BACnet Trend Log objects. For details, see the Bacnet Users
Guide.
You create history import descriptors and export descriptors under the Histories extension of a device
118
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
Types of device extensions About the Retry Trigger using separate views. For details, see
“About Histories extension views” on page 132.
About the Retry Trigger
By default, device extensions Histories and Schedules contain a “Retry Trigger”-named component,
appearing in the Nav tree but not in any Manager view ( Figure 35 ).
Note: Retry Trigger is unique in that it requires no linking of its output for operation.
Figure 35 Retry Trigger under device Histories extension
Upon any unsuccessful execution of a history import/export descriptor or schedule import extension/ schedule export descriptor contained in that same device extension, the Retry Trigger defines subsequent “retries” that will automatically occur upon the interval period defined (default value is 15 minutes). This continues until successful execution occurs.
About the Alarms extension
Not all drivers have devices with an AlarmDeviceExt (Alarms)—notably, this exists only if the driver protocol (or device) provides for local (native) alarming. Currently, only a device component under a
NiagaraNetwork (station) or BacnetNetwork has a child Alarms extension.
Alarms extension properties specify how alarms from that device are mapped into the station’s own
alarm subsystem, plus provide status properties related to alarm sharing. Unlike other device extensions, there are no special views, nor does the extension contain other special components.
Alarms extension properties
The following properties apply:
• Alarm Class
(Available only if checkbox “Use Existing Alarm Class” is cleared) Provides selection list of local
AlarmClass, from which you select one to use for all alarms received from this device.
• Use Existing Alarm Class
(checkbox, applies to NiagaraStation only)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
119
Types of device extensions
Chapter 4 — Driver architecture
About the Schedules extension
• If enabled (default), alarms from this remote station are routed to any “matching” AlarmClass, that is, one with identical name as the “alarmClass” field in each alarm record. If no local
“matching” AlarmClass is found, the station’s default AlarmClass is used.
• If cleared, all received alarms are routed to the single local AlarmClass specified.
• Last Received Time
Timestamp when last alarm from this station was received. This is configured remotely, either in the sending Niagara station or the BACnet device.
Note: Remaining properties apply to the Alarms extension under a NiagaraStation component only (are not available in Alarms extension under a BacnetDevice).
• Last Send Time
Timestamp when last local alarm was routed to this device. This is configured under the local station’s AlarmService with a corresponding StationRecipient or BacnetDestination component linked to one or more AlarmClass components).
• Last Send Failure Time
Timestamp when last local alarm routed to this station could not be sent.
• Last Send Failure Cause
Text string describing failure cause routing local alarm to this station.
About the Schedules extension
Not all drivers have devices with a ScheduleDeviceExt (Schedules)—notably, this exists only if the driver protocol (or device) provides local event scheduling. Currently, this device extension exists only under components NiagaraStation and BacnetDevice.
Figure 36 Schedules device extension (NiagaraStation)
A device’s Schedules extension is the parent container for imported schedules—Niagara schedule components with a ScheduleImportExt. Events in an imported schedule are obtained from that device, and are read-only (often called “slave schedules”). By default, the Schedules extension also contains a Retry Trigger, see
“About the Retry Trigger” on page 119.
The Schedules extension can also contain schedule export descriptors. These correspond to local sta-
tion schedules that are exported (“pushed”) to that remote station (often called “master schedules”). A schedule export descriptor is automatically created whenever a local schedule is “imported” into a
remote station.
120
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager About the Schedules extension
The difference between a schedule import and schedule export are as follows:
• Import
An imported schedule appears in the local station as a Niagara schedule, where read-only schedule events are configured/adjusted in a remote source device.
• If under a NiagaraStation device, the source is a Niagara schedule in that remote station.
• If under a BacnetDevice, the source is a BACnet Schedule or Calendar object residing in that
BACnet device. That object’s data is now modeled as a Niagara schedule component.
• Export
This is a Niagara schedule in the local station that is exported into a remote station (NiagaraNetwork) or BACnet Schedule or Calendar object (BacnetNetwork). A resulting schedule export descriptor allows configuration of a “push” mechanism to keep event configuration synchronized in the remote device.
Note: Under a BacnetNetwork, the single “LocalDevice” component (that represents station data exported to BACnet) has a special view on its child Export Table component that permits
“exposing” Niagara schedule components in the station as either a BACnet Schedule object or Calendar object. For details, see the Bacnet Users Guide.
You create imported schedules under a device’s Schedules extension using an Import Manager view.
A separate Export Manager view provides access to schedule export descriptors. For details, see
“About Schedules extension views” on page 142.
Note: Schedule components local to the station can reside anywhere under the station’s Config hierarchy and be imported by one or more other stations. As this occurs, a schedule export descriptor is automatically created under the NiagaraStation component that represents the remote station (and is located in its Schedules container). On the other hand, if you import a schedule from another NiagaraStation or BacnetDevice, it must reside in that device’s Schedule container. Imported schedules are always under a specific device.
About the Point Manager
The Point Manager is the default view for the Points extension under any device object. Like other manager views, it is table-based (
). Here, each row represents a proxy point (or a points folder) under Points.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
121
About the Point Manager
Figure 37 Point Manager under a BacnetDevice
Chapter 4 — Driver architecture
Points New Folder and New
When building a network in the station, you use this view to create, edit, and delete proxy points in
the station database. See “About proxy points” on page 74.
Following station configuration, this view provides a status summary for proxy points. You can also use it to issue an override action to a writable proxy point, e.g. “Active,” “Off,” and so on.
Note: Only proxy points appear in the Point Manager Database—any other components that may also reside under Points do not appear. For example, you do not see kitControl or schedule components, or any control point with a “null proxy extension.” However, you can use other
views of Points (wire sheet, property sheet, slot sheet) to access these items.
At the bottom of the view, buttons “New Folder” and “New” let you create new point folders and proxy points in the station database. An “Edit” button lets you edit one or more selected proxy points.
If the driver supports online “device learning,” buttons “Discover,” and “Match” are also typically available. Finally, additional buttons may be available, depending on the driver.
For more details, see:
•
•
•
About Point Discover, Add and Match (Learn Process)
•
Points New Folder and New
New exist in a device’s Point Manager view under any driver network.
Note: New Folder and New are tools on the Point Manager toolbar, and in the Manager menu.
122
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager Points New Folder and New
New Folder
New Folder in the Point Manager adds a special “PointFolder” component that you can use to organize proxy points. This is equivalent to copying that same component from that driver’s palette. A
Name dialog lets you name the folder before it is created ( Figure 38 ).
Figure 38 Example New Folder dialog in Point Manager
When you click OK, a new PointFolder component is added under Points. Point folders are often useful, especially if you are creating many proxy points, or need extra wire space for additional kitControl or schedule components (and whatever links you wish to create between them).
Note: A devices’s PointFolder component is different than a “normal” Folder component, because it includes that devices’s Point Manager view as its default view (just like the parent Points component). You can double-click a point folder (either in the Point Manager view pane or in
the Nav tree), to access its Point Manager. Also, an “All Descendants” command is available
from the root Points Manager, which allows you to see all proxy points in that device.
All Descendants. When in the Point Manager of a point folder, it is “unaware” of proxy points in
other point folders (or in the root of Points). However, from the root Point Manager view (of Points), you can “flatten” the folder structure to view all proxy points by selecting “All Descendants” from the
Manager menu (
) or simply clicking the “All Descendants” tool on the toolbar (
Note that “all descendants” is also available at any point folder (level) as well—you just see all points in descendants from that folder level on down.
Note: Be aware that in a device with many point folders and proxy points, using the all descendants feature (particularly at the Points root level) may decrease performance. This might result from so many points becoming subscribed.
Figure 39 Manager menu “All Descendants” command
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
123
About the Point Manager
Figure 40 Point Manager “All Descendants” tool on toolbar.
Chapter 4 — Driver architecture
Points New Folder and New
Note: If you are using point folders, and you click on a table to column to resort points, please be aware that any proxy point-to-point folder organization is lost during that view. However, you can always see contents of point folders clearly in the Nav tree, and again when returning to the Point Manager view from another view.
New
New in the Point Manager is to add new proxy points to the station. Typically, you use New only if the driver does not support online discovery, or if you are programming offline. Under any of the
Modbus drivers, for example, you use New to add proxy points.
Using New is equivalent to copying proxy points from that driver’s palette, except it provides more
utility to specify other parameters. Minimally, the New dialog provides a selection list for proxy point
type, and also the number of points to add (
).
Figure 41 Example New dialog in Point Manager
In some driver networks, the New dialog may provide other parameters, such as a starting address
124
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager Point Edit range when adding multiple proxy points. When you click OK, the number and type of proxy points you specified are added under Points or a point folder. You need to edit specific properties for each new proxy point (note these are typically properties of its proxy extension).
Point Edit
In the Point Manager view, you can
Edit any proxy point shown in the station database by simply
double-clicking it. (Edit does not apply to point folders.)
Edit
The Edit dialog appears with the proxy point listed (Figure 42).
Figure 42 Example Edit dialog in Point Manager (single point)
Note: The Edit dialog for a proxy point shows mostly properties under its proxy extension, plus (typically) the parent point’s Name and Facets. Many of the proxy extension values are required for communications, and will vary among drivers. To access all properties of the proxy point, including all those under any of its extensions, go to its property sheet.
When a single point is selected in the Edit dialog, you can edit any property except Type (fixed when you added the point). Included is the ability to edit the Name of the proxy point in the station. This is equivalent to the right-click Rename command on the point.
The following related topics also apply:
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
125
About the Point Manager
Chapter 4 — Driver architecture
About Point Discover, Add and Match (Learn Process)
Proxy point “gang” edits
The Edit button in the Point Manager allows you to edit one or more proxy points in the station in a single dialog. Before clicking Edit, use standard Windows keyboard controls to highlight (select)
multiple points (e.g. hold down Ctrl key and click desired points).
Note: Edit is also on the Point Manager toolbar and the Manager menu, if any point is selected.
The “gang” edit feature is useful for making the same change in multiple (selected) proxy points. For
ple points at the same time (versus editing this individually).
Figure 43 Example “gang edit” in Edit dialog in Point Manager
When you have the Edit dialog open with multiple points, you can also click on a specific one to make individual edits (e.g. Name, or any other editable property), during the same dialog session where you made “gang” property edits. When you click OK, all the changes are applied to the proxy points as made during your Edit session. For more details, see “About gang edits.”
Note: When you have multiple points selected in the Edit dialog, properties that must be unique
(such as Name) are automatically unavailable (dimmed). However, note that some properties that typically should be unique (often address properties) may still be available for “gang edit,” as this rule is not automatically enforced. Typically, when editing these properties, you should verify only a single point component (row) is highlighted in the table.
About Point Discover, Add and Match (Learn Process)
Online “point learns” are possible in some driver networks, for example the NiagaraNetwork, Bacnet-
Network, LonNetwork, and NdioNetwork. Whenever available, this method is the easiest way to accurately add proxy points to the station database.
126
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager About Point Discover, Add and Match (Learn Process)
Any proxy point learn in NiagaraAX is a two-step process using the Point Manager, where you:
2. Select and
Add from those candidates, creating proxy points under the device’s Points container.
(If you already used
New to add points, you can also
Match to those existing points).
Note: The Point Manager reinforces this process by providing two separate panes in the view when-
ever you enter “Learn Mode.” See “About Learn toggle” on page 109.
Discover
The Discover button is available in the Point Manager only if the driver supports online discovery.
When you click Discover, the Point Manager view splits into two panes (Learn Mode), and at the
same time typically launches a discovery “job” ( Figure 44 ).
Note: Under a LonNetwork, Point Manager has a Learn Mode, but no point Discover. All possible data items were already discovered when the parent device was discovered and added. Here, enter Learn Mode by toggling (see
“About Learn toggle” on page 109).
Figure 44 Discover splits Point Manager view
Note: Under a NiagaraNetwork (only), a Niagara Point Manager discover produces an intermediate
dialog: the Bql Query Builder. You use it to browse the remote station and specify what items to select from as discovered proxy point candidates. For details, see
In Learn Mode, the two panes in the Point Manager operate as follows:
• Discovered (top pane)
Lists data items discovered on the driver’s network, as proxy point candidates. For any data item found that already exists in the station database, it will appear “ghosted” (listed faintly). Note
items listed may be “expandable”—see “Discovered selection notes” on page 128.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
127
About the Point Manager
Chapter 4 — Driver architecture
About Point Discover, Add and Match (Learn Process)
A job “progress bar” is also included on top of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists proxy points and point folders that are currently in the station database.
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-pane Learn Mode and the single-pane (Database) view by clicking the Learn
Mode tool in the toolbar ( Figure 24 on page 110), or using the Learn Mode command in the
Manager menu.
Discovered selection notes. Often, data items listed in the Point Manager’s discovered pane are expandable, having one or more related items, each individually selectable. Expandable items are indicated by a leading plus (+), which you click to expand (a toggle control).
shows an example item (Lonworks nvoUnitStatus) expanded to reveal individual numerictype elements, each selectable as a separate proxy point.
Figure 45 Expand discovered data items to see all point candidates
Here, if you selected only the top “mode” element to add, you would have one proxy EnumPoint to monitor the enumerated unit status (auto, heat, cool, etc), but would not have any of the related numeric-type items proxied as control points.
Depending on the driver/device type, expandable discovered items represent individual properties or other “structured” data. Some examples:
• BacnetDevice—Each top item is typically the “present value” property of the BACnet object
(most commonly selected). Expand the item to see other properties of the object.
• NiagaraStation—Using Bql Query Filter defaults (Config, control, ControlPoint), each top item is equivalent to the “Out” slot of the Niagara component (and most commonly selected).
Expand the item to see other slots in the component (including Out).
• LonDevice—Each top item is typically the first element (field) in a structured SNVT (multi-field data structure), as used in that particular network variable (nv or nci). To access other data fields in the SNVT’s structure, you must expand that item.
For specific details, refer to the “Point discovery notes” section in a particular driver document.
128
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager About Point Discover, Add and Match (Learn Process)
Add
The Point Manager's Add button is available in Learn Mode when you have one or more data items selected (highlighted) in the top discovered pane. When you click Add, an Add dialog appears that allows you to edit properties before the proxy point(s) are created in the station (
).
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a discovered item to bring it up in the Add dialog.
Figure 46 Add dialog from Add button in Point Manager
properties.
Often, you may wish to change Type from the pre-selected one, at least between read-only points and the equivalent writable control point within that data category. For example, if adding a proxy point for the present value (default) property for a BACnet Binary Output object, you may wish it to be a read-only BooleanPoint point rather than the default BooleanWritable. As shown in
, you can do this in the Add dialog before it is added to the station database, (but not later using the point
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
129
About the Point Manager
Figure 47 Change Type as needed in point Add dialog
Chapter 4 — Driver architecture
About Point Discover, Add and Match (Learn Process)
Note: In most cases, alternate point Types include StringPoint, and possibly others. Generally speaking, there are few practical applications in changing the data category of a proxy point type
(e.g. from Boolean to Enum or Sting), however, this may be an option. Note that if working under a NiagaraNetwork, only read-only proxy points are available.
Address-related properties in the Add point dialog already have acceptable values for operation (otherwise, the data item would not have been discovered). It is possible you change only Name and possibly Type, unless you know other settings you wish to change now. You can always
properties in the proxy point(s) after you click OK and add them to your station.
Match
Match is a feature that may be useful when you have an application with proxy points you wish to reuse, or if you have programmed offline using the New point feature.
• In the first case (application for reuse), you could have some number of proxy points included in an application that you have saved and now recopied under the target Points container. Often, address-related properties in the copied proxy points are incorrect. However, you can use the
Point Manager’s Learn Mode and step through each proxy point in the copied application, and use the Match feature to “sync” with the intended (and discovered) data item.
• In the second case (offline programming) where a connection to the actual device network is unavailable, you can manually add
proxy points, and begin station engineering of a driver network. Typically, most component creations under a driver network are possible (including all levels) using the New command in the various “manager” views (Device
Manager, Point Manager, other device extension managers). Or, you can add saved applications
(from the device level on down) and edit as necessary. Then, when online with the driver network later, you could use Match to “sync” to existing components (device-level, proxy points, and so forth).
The Match button in the Point Manager becomes available when in Learn Mode, and you have:
1. Selected one point candidate in the top (Discovered) pane.
2. Selected one existing proxy point in the bottom (Database) pane.
Note: In this case, the toolbar also has an available Match tool, and the Manager menu has a Match command.
When you click Match, the Match dialog appears, as shown in Figure 48 .
130
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Point Manager
Figure 48 Match dialog example in Point Manager
About other Points views
Note: Match is strictly a “one-to-one” function for “discovered-to-database”—note that it is unavailable any time you have multiple items selected either in either the top Discovered pane or bottom Database pane.
The Match point dialog is nearly identical to the single-point
Edit dialog, and typically provides the
“discovered” point address values. Often, most properties in the Match dialog have acceptable
address values required for operation (otherwise, the item would not have been discovered). You can always Edit the proxy point after you click OK and add it to your station.
About other Points views
Although you initially use the Point Manager (default) view of a device’s Points extension (and/or child point folders), typically other views are needed when engineering a network. You can use the view selector in the locator bar, or in the Nav tree right-click Points (and/or child point folders) and select one of the View menu options.
Note: Remember that the Point Manager view provides access only to proxy points, and edit features apply only to proxy extension properties.
Commonly used Points views include:
• Wire sheet
Shows all proxy points, plus any kitControl and schedule components, simple control points, and so on, as well as links between them. Typically, you use this view to engineer control logic.
• Property sheet
Also includes all proxy points, plus any kitControl and schedule components, simple control points, and so on. As needed, you can use this view to expand down to any level to access and edit properties. For example, you can access an alarm extension under a proxy point.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
131
About Histories extension views
Chapter 4 — Driver architecture
History Import Manager
• Slot sheet
Also includes all proxy points, plus any kitControl and schedule components, simple control points, and so on. As needed, you can use this view to edit config flags from defaults (say, for security schemes), edit config facets, and add name maps.
• Px view (New View)
(Optional) A custom graphical view that you define by creating a new px file or using an existing px file. When created, this view becomes the default view for the device’s Points extension (or if created for a points folder, its default view).
About Histories extension views
For an overview of a device Histories extension, see
“About the Histories extension” on page 118.
Special views available on a device’s Histories extension may include:
•
•
History Import Manager
The History Import Manager is the default view for a device’s Histories extension. Like other managers, it is a table-based view (
Figure 49 ). Here, each row is a history import descriptor. Each descriptor
specifies how log data is imported (pulled) from the device into the station as a history.
Figure 49 History Import Manager under a NiagaraStation
When building a network in the station, you use this view to create, edit, and delete history import descriptors. Each import descriptor you add results in the creation of a local Niagara history.
132
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Histories extension views History Import Manager
Following station configuration, this view provides a status summary for collecting imported histories. You can also use it to issue manual “Archive” commands to one or more history descriptors. This causes an immediate import request to pull logged data from the remote device.
Note: Only history import descriptors appear in the History Import Manager view—any other components that may also reside under Histories do not appear. For example, you do not see the default “Retry Trigger” component (see
“About the Retry Trigger” on page 119). However,
you can use the Histories property sheet to access these items.
At the bottom of the view, the button “New” lets you manually create new import descriptors in the station. An “Edit” button lets you edit one or more import descriptors. Buttons “Discover,” “Add” and “Match” are also available, (these work similarly as in the Point Manager). An “Archive” button is available to manually import (pull data) into one or more selected histories. Finally, additional buttons may be available, depending on the driver.
For more details, see:
•
•
•
About History Import Discover, Add and Match (Learn Process)
History Import New
Button New exists in a device’s History Import view, but is used only if engineering offline (all devices with a Histories extension support online discovery). If used,
may be used later (when online with the device).
Note: A New tool is also on the History Import Manager toolbar, and in the Manager menu.
History Import Edit
In the History Import Manager, you can Edit
any import descriptor in the station database by simply double-clicking it.
Edit. The Edit dialog appears with the import descriptor listed (Figure 50).
Figure 50 Edit dialog in History Import Manager (single history)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
133
About Histories extension views
Chapter 4 — Driver architecture
History Import Manager
Note: The Edit dialog shows configuration properties of the history import descriptor, plus Name
(equivalent to the right-click Rename command on the descriptor). To access all properties,
(including all status properties) go to its property sheet.
The following related topics also apply:
•
•
History descriptor “gang” edits
•
History Import properties. Properties of history import descriptors available in the Edit or Add dialog are as follows:
• Name
Name for history import descriptor component. If discovered, typically left at default.
Note: Editing name does not affect name of the resulting history (imported into station).
• History Id
If under a NiagaraStation, (NiagaraNetwork), this property specifies the history name in the local station’s history space, using two parts: “/<stationName>” and “/<historyName>”. If learned, station name is “^” (see note below) and history name reflects the source history name. Typically, you leave both fields at default values, or edit the second (<historyName>) field only.
Note: The “^” character is basically a shorthand character to refer to the device name of the parent container (NiagaraStation component). This may be useful if you have multiple
JACEs with histories named the same. You can create and configure a single History
Import Descriptor and then duplicate and paste it under the other stations without having to go in and change the station name each time.
If under a BacnetDevice, the fields apply to the source BACnet object (“trendLog,” instance number <n>)—you typically leave learned values at defaults. You name the Niagara history using an additional Local History Name property.
• Execution Time
Either Daily (default), Interval, or Manual. If Manual, properties below are not available:
•
Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
•
Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds and this interval is added to the Time of Day. May prevent “server flood” issues if too many history archives are executed at the same time. Default is zero (no randomization).
•
Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
•
Interval (Interval)
Specifies repeating interval for archive execution. Default is every 15 minutes.
•
Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
• Enabled
Default is true. If set to false, does not execute import of history data.
• Capacity
Specifies local storage capacity for imported history, either as Unlimited or Record Count.
134
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Histories extension views History Import Manager
If set to Record Count, the following property is available:
• records
Number of records (samples) to locally store. Default is 500.
• Full Policy
Either Roll (default) or Stop. Applies only if capacity is set to record count
• If Roll, upon record count, oldest records become overwritten by newest records.
• If Stop, upon record count, importing stops (until history records are locally deleted).
Note: Bacnet History Import descriptors have additional properties, including a Local History
Name
property visible from the Add or Edit dialog.
History descriptor “gang” edits. The Edit button in the History Import (or Export) Manager allows you to edit one or more descriptors in a single dialog. Before clicking Edit, use standard Windows keyboard controls to highlight (select) multiple descriptors (e.g. hold down Ctrl key and click desired descriptors).
Note: Edit is also on the History Import (or Export) Manager toolbar and the Manager menu, if any descriptor is selected.
The “gang” edit feature is useful for making identical changes in multiple (selected) descriptors. For example, you can change “Execution Time” (when data is pulled into imported history) in multiple descriptors at the same time (versus editing individually).
When you have the Edit dialog open with multiple descriptors, you can also click on select ones to make individual edits (e.g. Execution, Time of Day), during the same dialog session where you made
“gang” edits. When you click OK, all the changes are applied to the descriptors as made during your
Edit session. For more details, see “About gang edits.”
Note: When you have multiple descriptors selected in the Edit dialog, properties that currently have
different values are automatically unavailable (dimmed). Only a property that currently has the same value (across all selected descriptors) is available for gang edit.
About History Import Discover, Add and Match (Learn Process)
Unless working offline, you can use the learn process to import histories in the station. As with other
NiagaraAX learns, this is a two-step process in the History Import Manager, where you:
1. Under a selected device component, use its (Histories extension) Histories Import Manager view
log data (histories) as candidates for inclusion in the station as histories.
2. Select and
Add from those histories, creating history descriptors under the device’s Histories con-
tainer.
Note: The Histories Import Manager reinforces this process by providing two separate panes in the view whenever you enter “Learn Mode.” See
“About Learn toggle” on page 109.
Discover. When you click Discover, the Histories Import Manager splits into two panes (Learn
Mode): discovered items in the top pane, and existing import descriptors bottom pane (
).
Note: If under a BacnetDevice, a “Bacnet Trend Logs Discover” job is started, with a progress bar at top. If BACnet Trend Log objects are found, they are listed in the discovered pane.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
135
About Histories extension views
Figure 51 Discover splits Histories Import Manager
Chapter 4 — Driver architecture
History Import Manager
Note: Under a NiagaraNetwork (only), the discovered pane shows the collapsed tree structure of all
Niagara histories of that selected NiagaraStation. Click to expand and select histories for
import. See “Discovered selection notes” on page 136 for more details.
In Learn Mode, the two panes in the Histories Import Manager operate as follows:
• Discovered (top pane)
Lists histories (Niagara) or Trend Logs (Bacnet) found in the device, as history descriptor candidates. Any item that already exists as a history in the station is “ghosted” (faintly listed).
If a BacnetDevice, a job “progress bar” is also included on top of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists history descriptors currently in the station database (each has an associated history).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-pane Learn Mode and the single-pane (Database) view by clicking the Learn
Mode tool in the toolbar ( Figure 24 on page 110), or using the Learn Mode command in the
Manager menu.
Discovered selection notes. In the Niagara History Import Manager, discovered histories of a NiagaraStation are under an expandable tree structure, organized by station name (
).
136
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Histories extension views
Figure 52 Expand Niagara stations to see all Niagara histories
History Export Manager
Histories under the same station name as the parent NiagaraStation (device) component are local his-
tories for that station. Histories under any other stations represent histories currently imported into (or exported to) that station.
For example, discovered histories in
for NiagaraStation J403IP98 include local histories
(expanded); other “imported” histories from station NxMbTest56 are shown contracted.
Note: From any NiagaraStation, you can import both its “local” histories and already-imported histories, as needed. However, unless circumstances warrant a “relay archive method,” it may be best to import histories directly from the source station whenever possible.
Add. The Add button is available in Learn Mode when you have one or more items selected (highlighted) in the top discovered pane. When you click Add, a dialog appears that allows you to edit properties before the history descriptor(s) are created in the station.
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a discovered item to bring it up in the Add dialog.
The Add dialog is identical to the history import descriptor
Edit dialog. For details on properties, see
“History Import properties” on page 134.
Match. Match, as an online function, is available if you have one history selected in the top (discovered) pane and one history import descriptor selected in the bottom (database) pane. However, usage of Match when importing histories from a device (NiagaraStation, BacnetDevice) is generally not recommended. Instead, use the
Add method to import histories.
History Export Manager
The History Export Manager view is available (only) on a NiagaraStation’s Histories extension.
Note: If using the Bacnet driver, Niagara histories in the local station can also be “exposed” to all
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
137
About Histories extension views
Chapter 4 — Driver architecture
History Export Manager networked BACnet devices as BACnet “Trend Log objects”. However, this is done using a different view under the Local Device component in the BacnetNetwork. See the Bacnet
Users Guide for more details.
Like other managers, the History Export Manager is a table-based view (
). Each row represents a history export descriptor. Each descriptor specifies how data from a local history is exported
(“pushed”) from the station to a selected NiagaraStation, where it appears as a history.
Note: The “capacity” and “fullPolicy” configuration for each “exported” history (as created on the remote station), is determined by that target station’s NiagaraNetwork component’s “History
Policies.” Before exporting any histories, you should review and adjust these policies as
needed. For more details, see “About History Policies” on page 151.
Figure 53 History Export Manager under a NiagaraStation
You use this view to create, edit, and delete history export descriptors. Each export descriptor you add results in the creation of a Niagara history on that remote station.
Following station configuration, this view provides a status summary for exporting local histories.
You can also use it to issue manual “Archive” commands to one or more history descriptors. This causes an export “push” of history data into the selected histories at the remote Niagara station.
Note: Only history export descriptors appear in the History Export Manager view—any other components that may also reside under Histories do not appear. For example, you do not see the default “Retry Trigger” component (see
“About the Retry Trigger” on page 119), or history
import descriptors. However, you can use the Histories property sheet or the Nav tree to access these items.
At the bottom of the view, the button “New” lets you manually create new export descriptors in the station. An “Edit” button lets you edit one or more export descriptors. Buttons “Discover,” “Add” and
“Match” are also available, (these work similarly as in the Point Manager). An “Archive” button is available to manually export (push data) into one or more selected histories. Finally, additional buttons may be available, depending on the driver.
138
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Histories extension views
For more details, see:
•
•
•
About History Import Discover, Add and Match (Learn Process)
History Export Manager
History Export New
Button New exists in a NiagaraStation’s History Export view, but is used only if engineering offline
(online discovery is preferred). If used,
Match may be used later (when online with the device).
Note: A New tool is also on the History Export Manager toolbar, and in the Manager menu.
History Export Edit
In the History Export Manager, you can Edit
any export descriptor in the station database by simply double-clicking it.
Edit. The Edit dialog appears with the export descriptor listed ( Figure 54 ).
Figure 54 Edit dialog in History Export Manager (single history)
Note: The Edit dialog shows configuration properties of the history export descriptor, plus Name
(equivalent to the right-click Rename command on the descriptor). To access all properties,
(including all status properties) go to its property sheet.
The following related topics also apply:
•
•
“History descriptor “gang” edits” on page 135
•
“Manager table features” on page 113
History Export properties. Properties of history export descriptors available in the Edit or Add dialog are as follows:
• Name
Name for history export descriptor component. Typically left at default. Begins with “Local_” for any history originating from the local station.
Note: Editing name does not affect name of resulting history (exported into remote station).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
139
About Histories extension views
Chapter 4 — Driver architecture
History Export Manager
• History Id
This property specifies the history name to be created in the remote station’s history space, using two parts: “/<stationName>” and “/<historyName>”. Histories originating in the local station show a “^” (shorthand for local station name), and history name reflects the source history name.
Typically, you leave both fields at default values.
• Execution Time
Either Daily (default), Interval, or Manual. If Manual, properties below are not available:
•
Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
•
Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds and this interval is added to the Time of Day. May prevent “server flood” issues if too many history archives are executed at the same time. Default is zero (no randomization).
•
Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
•
Interval (Interval)
Specifies repeating interval for archive execution. Default is every 15 minutes.
•
Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
• Enabled
Default is true. If set to false, history data is not exported.
Note: The capacity and full policy of any exported history (created on the remote station) is determined by rules under that station’s NiagaraNetwork “History Policies,” and is set at creation
time only. For details, see “About History Policies” on page 151.
About History Export Discover, Add and Match (Learn Process)
Unless working offline, you can use the learn process to export histories in the station. As with other
NiagaraAX learns, this is a two-step process in the History Export Manager, where you:
1. Under a selected NiagaraStation, use its (Histories extension) Histories Export Manager view to
Discover (local) station histories as candidates for export to that station as histories.
2. Select and
Add from those histories, creating history descriptors under the station’s Histories con-
tainer.
Note: The Histories Export Manager reinforces this process by providing two separate panes in the view whenever you enter “Learn Mode.” See
“About Learn toggle” on page 109.
Discover. When you click Discover, the Histories Export Manager splits into two panes, or Learn
). The top discovered pane is a collapsed tree structure of all Niagara histories of the
140
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Histories extension views
Figure 55 Discover splits Histories Export Manager
History Export Manager
In Learn Mode, the two panes in the Histories Export Manager operate as follows:
• Discovered (top pane)
Lists all histories in the local station (station you are engineering). Any history that already exists
as a history in the selected NiagaraStation device is “ghosted” (listed faintly).
• Database (bottom pane)
Lists history descriptors currently in the station database (each has an associated history, exported to that remote station).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-pane Learn Mode and the single-pane (Database) view by clicking the Learn
Mode tool in the toolbar ( Figure 24 on page 110), or using the Learn Mode command in the
Manager menu.
Discovered selection notes. In the Niagara History Export Manager, discovered local histories are
under an expandable tree structure, organized by station name ( Figure 56
).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
141
About Schedules extension views
Figure 56 Expand Niagara stations to see all Niagara histories
Chapter 4 — Driver architecture
History Export Manager
Histories under the same station name as the local station originated in that station. Histories under any other stations represent histories currently imported (or exported) into the local station.
For example, discovered histories in
for local station NxMbTest56 include locally-originated histories (expanded); other “imported” histories from station J403IP98 are shown contracted.
Note: To any NiagaraStation, you can export both a station’s “locally-originated” histories as well as already-imported histories, as needed. However, unless circumstances warrant a “relay archive method,” it may be best to export only “locally-originated” histories.
Add. The Add button is available in Learn Mode when you have one or more items selected (highlighted) in the top discovered pane. When you click Add, a dialog appears that allows you to edit properties before the history export descriptor(s) are created in the station.
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a discovered item to bring it up in the Add dialog.
The Add dialog is identical to the history export descriptor
Edit dialog. For details on properties, see
“History Export properties” on page 139.
Match. Match, as an online function, is available if you have one history selected in the top (discovered) pane and one history export descriptor selected in the bottom (database) pane. However, usage of Match when exporting histories from a device (NiagaraStation, BacnetDevice) is generally not recommended. Instead, use the
Add method to export histories.
About Schedules extension views
For a Schedules device extension overview, see
“About the Schedules extension” on page 120.
Special views on a device’s Schedules extension may include:
142
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Schedules extension views Schedule Import Manager
•
•
Note: Other standard views of a Schedules extension are commonly used. For example, the wire sheet may be used when linking imported schedules to other control logic in the station.
Schedule Import Manager
The Schedule Import Manager is the default view for a device’s Schedules extension. Like other man-
agers, it is a table-based view ( Figure 57 ). Each row corresponds to an imported Niagara schedule
(read-only). Configuration for each includes its name and whether it is enabled.
Figure 57 Schedule Import Manager under a NiagaraStation
When building a network in the station, you use this view to create, edit, and delete imported Niagara schedules. In the case of a Niagara network (only), each schedule that you import results in the creation of a remote “schedule export descriptor” in that remote Niagara station.
Following station configuration, this view provides a status summary for collecting imported schedules. You can also use it to issue manual “Import” commands to one or more schedules. This causes an immediate import request to pull schedule configuration data from the remote device.
Note: Only imported schedules appear in the Schedule Import Manager—any other components that may also reside under Schedules do not appear. For example, you do not see the default
“Retry Trigger” component (see “About the Retry Trigger” on page 119), or if a NiagaraSta-
tion, schedule export descriptors. However, the Nav tree and other views on Schedules provide you access to these items.
At the bottom of the view, the button “New” lets you manually create new imported schedules in the station. An “Edit” button lets you edit a few properties of one or more imported schedules. Buttons
“Discover,” “Add” and “Match” are also available, (these work similarly as in the Point Manager).
An “Import” button is available to manually import (pull data) into one or more selected imported schedules. Finally, depending on driver, additional buttons may be available.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
143
About Schedules extension views
For more details, see:
•
•
•
About Schedule Import Discover, Add and Match (Learn Process)
Chapter 4 — Driver architecture
Schedule Import Manager
Schedule Import New
Button New exists in a device’s Schedule Import Manager, but is used only if engineering offline (all devices with a Schedules extension support online discovery). If used,
(when online with the device).
Note: A New tool is also on the Schedules Import Manager toolbar, and in the Manager menu.
Schedule Import Edit
In the Schedule Import Manager, you can
Edit selected properties of a schedule in the station database
by simply double-clicking it.
Edit. The Edit dialog appears with the imported schedule listed ( Figure 58 ).
Figure 58 Edit dialog in Schedule Import Manager (Bacnet)
Note: The Edit dialog shows some properties of the schedule’s ScheduleImportExt, plus Name— equivalent to the right-click Rename command on the schedule component). To access all
properties of the schedule (including all status properties) go to its property sheet, or to see the imported schedule events, to its
.
To access the Scheduler, in the Nav tree you can simply double-click the schedule.
The following related topics also apply:
•
•
Schedule Import or Export “gang” edits
•
Schedule Import properties. Properties of imported schedules available in the
144
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Schedules extension views Schedule Import Manager the Schedule Import Manager are as follows:
• Name
Name for the imported Niagara schedule component. If discovered, will match the name of the source schedule. Must be unique among other components in same container.
Note: Editing name does not affect name of the source schedule, nor the name of the corresponding schedule export descriptor (if source is a Niagara schedule).
• Supervisor Id
(NiagaraStation only) Unique slot path of source Niagara schedule in that station.
• Object Id
(BacnetDevice only) Combination of BACnet object type (schedule or calendar) and instance number (unique within that object type in that device).
• Enabled
Default is true. If set to false, the imported schedule is disabled.
Note: While disabled, the schedule’s Out slot has status disabled. Any downstream logic linked to Out no longer processes it. See
“About “isValid” status check” on page 74.
• Execution Time
(BacnetDevice only) Specifies how event-configuration refresh (import) occurs with source schedule, using a “pull” request method. Options are Daily, Interval, or Manual (default).
If Manual, some properties below are not available, as noted:
•
Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
•
Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds and this interval is added to the Time of Day. May prevent “server flood” issues if too many schedule imports execute at the same time. Default is zero (no randomization).
•
Days of Week (Daily and Interval)
Select (check) days of week for import execution. Default is all days of week.
•
Interval (Interval)
Specifies repeating interval for import execution. Default is every 15 minutes.
•
Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
•
Last Trigger
Timestamp of when last interval or daily import occurred.
•
Next Trigger
Timestamp of when the next interval or daily import is configured to occur.
Schedule Import or Export “gang” edits. The Edit button in the Schedule Import (or Export) Manager allows you to edit one or more items in a single dialog. Before clicking Edit, use standard Windows keyboard controls to highlight (select) multiple items (e.g. hold down Ctrl key and click desired schedules).
Note: Edit is also on the Schedule Import (or Export) Manager toolbar and the Manager menu, if any item in the database is selected.
The “gang” edit feature is useful for making identical changes in multiple (selected) items. For exam-
ple, as shown in Figure 59 when using Edit in the Niagara Schedule Export Manager
, you can change
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
145
About Schedules extension views
Chapter 4 — Driver architecture
Schedule Import Manager the “Execution Time, Interval” in multiple schedule export descriptors at the same time (versus editing individually). For more details, see “About gang edits.”
Figure 59 Example “gang edit” in Edit dialog of Schedule Export Manager
About Schedule Import Discover, Add and Match (Learn Process)
Unless working offline, you can use the learn process to import schedules in the station. As with other
NiagaraAX learns, this is a two-step process in the Schedule Import Manager, where you:
1. Under a selected device component, use its (Schedules extension) Schedule Import Manager view
schedules as candidates for inclusion in the station as Niagara schedules.
2. Select and
Add from those candidates, creating imported schedules under the device’s Schedules
container.
Note: The Schedule Import Manager reinforces this process by providing two separate panes in the view whenever you enter “Learn Mode.” See
“About Learn toggle” on page 109.
Discover. When you click Discover, the Schedule Import Manager splits into two panes (Learn
Mode): discovered items in top pane, and existing imported schedules in bottom pane (
).
A schedule discovery job (either Niagara or Bacnet) is started, with a progress bar at top.
• If Niagara schedules are found in the remote station, they are listed in the discovered pane.
• If BACnet Schedule and/or Calendar objects are found, they are listed in the discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
146
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About Schedules extension views
Figure 60 Discover splits Schedules Import Manager
Schedule Import Manager
In Learn Mode, the two panes in the Schedule Import Manager operate as follows:
• Discovered (top pane)
Lists schedule components (Niagara) or Schedule and/or Calendar objects (Bacnet) found in the device, as candidates for imported schedules. Any item that already exists as a schedule in the station is “ghosted” (faintly listed).
• Database (bottom pane)
Lists schedules currently imported in the station database (contained in Schedules container).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-pane Learn Mode and the single-pane (Database) view by clicking the Learn
Mode tool in the toolbar ( Figure 24 on page 110), or using the Learn Mode command in the
Manager menu.
Add. The Add button is available in Learn Mode when you have one or more items selected (highlighted) in the top discovered pane. When you click Add, a dialog allows you to edit properties before the schedule is created in the station. The Add dialog and
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a discovered item to bring it up in the Add dialog.
For details on properties, see
“Schedule Import properties” on page 144.
Match2. Match, as an online function, is available if you have one schedule selected in the top (discovered) pane and one schedule selected in the bottom (database) pane. However, usage of Match when importing schedules from a device (NiagaraStation, BacnetDevice) is generally not recommended. Instead, use the
Add method to import schedules.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
147
About Schedules extension views
Chapter 4 — Driver architecture
Schedule Export Manager
Schedule Export Manager
The Schedules extension of a NiagaraStation or BacnetDevice has an available Export Manager view.
It allows management of schedule components in the local station made available to that remote device.
Like other managers, the Schedule Export Manager is a table-based view (
). Each row represents a schedule export descriptor. Each descriptor specifies how/when configuration for a local
schedule is “pushed” to either:
• An imported schedule component in the designated NiagaraStation.
• An existing BACnet Schedule object or Calendar object in the designated BacnetDevice.
Figure 61 Schedule Export Manager under a NiagaraStation
Note: A Schedule Export Manager works differently in NiagaraNetworks and BacnetNetworks.
• For NiagaraStation, you do not create export descriptors using this view—there is no “Learn
Mode,” Discover, Add, or New. Instead, each schedule export descriptor is automatically created upon the remote Niagara station “importing” a local schedule component. For more de-
tails, see “Station Schedules import/export notes” on page 163.
• For BacnetDevice, you do use Learn Mode to discover BACnet Schedule and Calendar objects in the device. Then, you select and add any as schedule export descriptor(s). In each export descriptor, you must specify the station’s local schedule component that “exports” (writes) its event configuration to that remote BACnet object. For more details, see the Bacnet Users
Guide.
After configuration, this view provides a status summary for exporting local schedules. You can also use it to issue manual “Export” commands to one or more schedules. This causes an export “push” of schedule configuration into the remote device.
Note: Only schedule export descriptors appear in the Schedule Export Manager view—any other components that may also reside under Schedules do not appear. For example, you do not see imported schedules or the default “Retry Trigger” component (see
these items.
148
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network
About the Niagara Network
NiagaraNetwork component notes
Currently, by default every NiagaraAX station has a Niagara Network under its Drivers container. The
Niagara Network is where data is modeled that originates from other stations. Generally, this is done using the same driver architecture used by other (non-Niagara) drivers. See
“About Network architecture” on page 90.
A Niagara Network has the following unique differences:
• All proxy points under a NiagaraStation are “read only” types, namely one of the following:
• BooleanPoint
• EnumPoint
• NumericPoint
• StringPoint
However, note that a Niagara proxy point inherits any actions from the originating (remote) point or object. For more details, see
“Niagara proxy point notes” on page 161.
• Connections between stations occur as client and server sessions using the Fox protocol. The requesting station is the client, and target (responding) station is the server. A Workbench connection to a station operates identically, where Workbench is the client, and station is server. Client authentication (performed by the server) is required in all Fox connections.
For more details specific to a Niagara Network, see:
•
NiagaraNetwork component notes
•
•
NiagaraStation component notes
•
•
•
•
Station Schedules import/export notes
NiagaraNetwork component notes
In addition to common network components (see “Common network components” on page 95), the
Niagara Network contains components specific to Niagara, namely:
• Fox Service
A container for Fox protocol settings affecting client connections made to the local station, such as from Workbench or from another station. Such connections appear locally as “server connections.” For details, see
“About the Fox Service” on page 150.
• History Policies
A container for “rules” that specify how remotely-generated histories should be changed when these histories are pushed into the station (that is, exported from remote stations). For details, see
“About History Policies” on page 151.
Also, Tuning Policies for a NiagaraNetwork are simplified, with only 3 properties, as follows:
• Stale Time
• If set to a non-zero value, points become “stale” (status stale) if the configured time elapses
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
149
About the Niagara Network
Chapter 4 — Driver architecture
NiagaraNetwork component notes without a successful read, indicated by Read Status “ok.”
• If set to zero (default), the stale timer is disabled, and points become stale immediately when unsubscribed.
• Min Update Time
The minimum amount of time between updates sent from the server to the client. It is used to throttle data changing at a rate faster than minUpdateTime. Default value is 1 second.
• Max Update Time
Used to resend the value if it hasn't been sent for other reasons (such as a change). Default value is
15 minutes.
About the Fox Service
The NiagaraNetwork’s Fox Service holds configuration for the local station’s Fox settings. (This var-
ies from most other services, which are found instead under the station’s ServiceContainer
). Included are properties for the TCP/IP port number assigned to the Fox server, authentication method used, and various timeout/trace settings. Typically, most properties are left at default values. See
Fox Service properties for more details.
Authentication is required when establishing any Fox connection to/from the station:
• If opening a station in Workbench, you must enter a valid station username and password for it in the station login dialog (otherwise it does not open).
• If accessing a station in a browser as a user with a
• If adding a NiagaraStation to a station’s NiagaraNetwork, you must configure username and password properties under its Client Connection slot (otherwise it remains “down”). Often, you enter the username and password of a “super user”-level account in that station. You also specify the software port used by that station’s Fox server.
Note: Often in a multi-station job, in each station you create a user account specifically for stationto-station communications, with an assigned profile type of “super user.” This is the account that you reference when you edit a NiagaraStation’s Client Connection properties, entering its
username and password. See “Multi-station security notes” on page 280.
child components. The summary view allows you to see all current connections, and if necessary, perform a right-click Force Disconnect action on one or more connected users.
Fox Service properties. NiagaraNetwork Fox Service properties are as follows:
• Port
Specifies well-known TCP/IP port used by Fox server (default is 1911).
• Authentication Policy
Either Digest Md5 (default) or Basic. Applies to password authentication when establishing a client connection.
• If Digest Md5, user password is encrypted. This is the recommended setting.
• If set to Basic, password is passed in clear text. Typically, Basic is used only if using LDAP.
• Request Timeout
Time to wait for a response before assuming a connection is dead (default is 1minute).
150
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network NiagaraNetwork component notes
• Socket Option Timeout
Time to wait on a socket read before assuming the connection is dead (default is 1minute).
• Keep Alive Interval
Interval between keep alive messages (default is 5 seconds). The keep alive should be well below the request timeout and socket option timeout.
• Enable Announcement
Either true (default) or false. Enables multicast announcement messages for learn/discover.
• Multicast Time To Live
Number of hops to make before a multicast message expires (default is 4).
• Server Connections
Provides status information about current Workbench client connections to the local station (does not reflect station-to-station Fox connections).
• Trace Session States
Either true or false (default). Debug usage for tracing session state changes.
• Trace Read Frame
Either true or false (default). Debug usage for dumping frames being read from the wire.
• Trace Write Frame
Either true or false (default). Debug usage for dumping frames being written to the wire.
• Trace Multicast
Either true or false (default). Debug usage for tracing multicast messaging.
About History Policies
The NiagaraNetwork’s “History Policies” (
HistoryNetworkExt ) holds “rules” that are used when
remote histories are “exported” into the local station. Unlike imported histories, which let you define
(and adjust later, if needed) the “capacity” and “full policy” settings in each HistoryImportDescriptor, histories that are exported into the station have no associated component—only the history itself. The capacity and “full policy” for each history is set only at creation time, using the local history policies.
Note: You export histories into the station working under a remote station—meaning, from a view of the Histories device extension under the NiagaraStation that represents this (local) station. See
“History Export Manager” on page 137.
For an example scenario showing histories in two JACE stations that are exported to a Supervisor sta-
tion, and how history policies apply, see Figure 62 .
Additional details are in the following sections:
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
151
About the Niagara Network
Figure 62 History Policies in a supervisor station
Chapter 4 — Driver architecture
NiagaraNetwork component notes
, the Supervisor’s History Policies “ Config Rules ” determine the capacity and
fullPolicy settings for each history upon export from the JACE stations “WestWing403” and
“EastWing403”. Rules are matched to remote station (device) names and history names, which determine the corresponding capacity and full policy values to apply upon history creation. If a history does not match any rule, it is created using the same capacity and full policy as in the source history.
For an example related to this scenario, see “Example rules” on page 153.
Default history policies. By default, under a NiagaraNetwork’s History Policies, only a single
“default rule” exists—with wildcard matches to “all” stations and history names, specifying “unlimited” capacity and a “roll” fullPolicy. This means that any history that is exported into the station
(from any remote station) is archived using a local history configured with unlimited capacity.
Given the vast storage capacity of a supervisor host PC, the default “one rule” setting may be acceptable on the target of most exported histories (supervisor station). However, if for some reason you are exporting histories to a JACE station, you should definitely change the “Default Rule” of the History
Policies under its NiagaraNetwork to specify smaller capacities. Even for a supervisor station, you
152
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network NiagaraNetwork component notes may wish to change the default rule, and/or add additional optional
, as needed.
Config Rules. When a history is exported to the station (from another station), these rules are evaluated to set the local (archived) history’s config properties “capacity” and “fullPolicy.” The first matching rule is used. The “Default Rule” is always at top, and cannot be deleted or renamed.
Note: Rule priority is set by order—as the “Default Rule” is always first, it is highest priority. If you create other rules (in Workbench, right-click a rule, then click “Duplicate”), you can edit, rename, and reorder as needed.
Each rule under the network’s History Policies has the following configuration properties:
• Device Pattern
String matching to device names, meaning name of NiagaraStation(s) that are exporting histories.
Default value is a wildcard (“*”), meaning all station names are matched.
• History Name Pattern
String matching to history names of histories being exported. Again, default value is a wildcard
(“*”), meaning all named histories are matched.
Note: Both device pattern and history name pattern must apply for the rule to be used—otherwise the next rule down (in order) in History Policies is evaluated.
• capacity
The capacity setting to use when creating the local history, if matched by device and history names. Either “unlimited,” or “Record Count,” with a finite record specified.
• fullPolicy
Applies if capacity is not “unlimited,” and specifies if collection continues when the capacity record limit is reached (“roll”) or collection stops (“stop”).
Example rules. As shown in the three-station scenario of
, histories in two JACE stations
are exported to the “Supervisor” station. As shown in Figure 63
, the receiving supervisor station has 2
additional config rules under its History Policies of its NiagaraNetwork.
Figure 63 Example history policies config rules (supervisor station)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
153
About the Niagara Network
Chapter 4 — Driver architecture
Niagara Station Manager notes
In this example, the highest-priority “Default Rule” matches all (any) stations exporting, with a history name pattern of “Audit*”—this matches any “AuditHistoryLog”. Capacity is set to unlimited, as all history records are wanted for archive.
The next two rules are applied to histories exported (by any stations), as follows:
• MetersRule — This rule applies to any station, for any history named beginning with “Meter”
(“Meter*”). Any such history is archived using unlimited capacity, as all records are wanted.
• EastWins — This rule applies only to stations named beginning with “East” (“East*”), for any history. Such a history is archived using a capacity of 100,000 and a “roll” full policy.
Following this example (with exported histories in the JACE stations, as shown in Figure 62
), the histories are created in station “Supervisor” as follows:
• WestWing403
Histories are exported using following capacity and fullPolicy (from config rule):
• AuditHistoryLog: unlimited, roll (from Default Rule)
• LogHistory: 500 records, roll (no rule matched, using source history config, as in JACE)
• Meter1: unlimited, roll (from “MetersRule”)
• ZoneTemp1: 500 records, roll (no rule matched, using source history config, as in JACE)
• Meter2: unlimited, roll (from “Meters Rule”)
• ZoneTemp2: 500 records, roll (no rule matched, using source history config, as in JACE)
• EastWing403
Histories are exported using following capacity and fullPolicy (from config rule):
• AuditHistoryLog: unlimited, roll (from “Default Rule”)
• LogHistory: 100,000 records, roll (from “EastWins” rule)
• Meter4: unlimited, roll (from MetersRule)
• ZoneTemp1: 100,000 records, roll (from “EastWins” rule)
• Meter3: unlimited, roll (from Meters Rule)
• ZoneTemp2: 100,000 records, roll (from “EastWins” rule)
Again, note that the rules are processed in priority order. In this example, if the two optional rules were reordered (“EastWins” above “MeterRule”) before the JACE histories were exported, results would differ. “Meter” histories from EastWing403 would have a 100,000 record capacity instead.
Niagara Station Manager notes
The Station Manager is the default view for the Niagara Network. It operates like the Device Manager for most drivers that have online “device discovery” capability. For general information, see
“About the Device Manager” on page 105.
When using the Station Manager, the following notes apply:
•
Station Learn and Discover notes
•
Station Learn and Discover notes
By default, a station discover uses IP address (vs. host name). Typically, this is the recommended
154
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network Niagara Station Manager notes method. However, if Niagara hosts are installed on a network using DNS, you can toggle the discovery method to use host name instead. Do this in the table options menu (click upper right small con-
sort on any column. See
“Manager table features” on page 113 for more details.
Figure 64 Station Manager table options menu
By default, discovered stations list showing address. If a station uses a Fox port other than 1911
(default), address includes the port number appended, for example: 192.168.1.112.1912.
Station Add notes
When you add a NiagaraStation to the database, the Add dialog includes its Fox port, along with
fields for station username and password (required for client connection) as shown in Figure 65 .
Figure 65 Add dialog for NiagaraStation
Typically, you enter a user name and password for a “super user” that exists in the remote station. By convention, this may be a user especially for station-to-station access (for example, a user “m2m”).
See “Multi-station security notes” on page 280 for more details.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
155
About the Niagara Network
Chapter 4 — Driver architecture
NiagaraStation component notes
Note: After you add a station, in the Station Manager’s database pane just double-click it to bring up
the Edit dialog, which provides access to the same properties in the Add dialog ( Figure 65 ).
Or, you can access all client connection properties from the NiagaraStation component’s property sheet (“Client Connection” slot, along with status properties).
Adding a NiagaraStation automatically creates a reciprocal NiagaraStation
in the remote station.
Reciprocal NiagaraStation component. When you add a station under the Niagara Network, that remote station automatically adds a “reciprocal” NiagaraStation component under its own Niagara
Network, representing your local station. However, it is created with its “Enabled” property set to false, and so has a status of “disabled” (gray on gray background). This provides a visual clue for you to edit its client connection username and password to a valid user account in the reciprocal station, and to set Enabled back to true for operation.
NiagaraStation component notes
Explains items unique to Niagara Station components versus other device components.
•
About station status properties
•
About client connection properties
•
About server connection properties
About station status properties
About client connection properties
Client connection properties determine the Fox port used for station and Workbench connections, as well as the user name and password used for station-to-station connections. Many properties are status types, that contain either real-time or historical information.
About server connection properties
Server connection properties are all status properties that provide either real-time or historical information.
156
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network About the Bql Query Builder
About the Bql Query Builder
The Bql Query Builder is the initial dialog you use when you “Discover” proxy points in a station under the Niagara Network. You also use it in discovers in other managers, for example, the Bacnet Export Manager.
This dialog provides extensive Find and Match filters, plus other controls, which are briefly discussed in the following sections:
•
•
•
About Bql Query Save, Load, and Edit
Note that the default point Discover for a NiagaraStation produces a Bql Query Builder dialog with a
Find of (all) “Config,” type “Control Point,” and Match of “All,” as shown in Figure 66 . While this
may be usable, typically you narrow this range, and run multiple point discovers, as needed.
Figure 66 Default Bql Query Builder from NiagaraStation point Discover
About Bql Query Find filters
By default, the Find filter preselects all control points in the target NiagaraStation (Config). Often, you may wish to narrow this range. For example, you may wish to find Boolean proxy points only under a specific driver network (during this particular Discover sequence).
To do this, simply click the Find icon (magnifying glass) which produces the Choose Root dialog, as shown in
.
Figure 67 Choose Root dialog
As needed, expand Config to select the root component of interest and click OK (or simply double-
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
157
About the Niagara Network
Chapter 4 — Driver architecture
About the Bql Query Builder click the component of interest). The proxy point Find is now limited to that area of the station.
To change the type of component, click the “Of type” drop-down and make a selection ( Figure 68 ).
Figure 68 Select component type
The proxy point Find is now limited to that class of component.
Note: A basic understanding of the NiagaraAX component class structure is helpful when making
type selections. For example, selection of Boolean Point (as shown in Figure 68 ) includes all
components that “subclass” from the simple BooleanPoint
. Included are all
as well as many kitControl components ( Logic components, as one example in this case).
If you select type “Component,” you have a “full-width find.” This means that all components are included—this includes everything listed in the “Of type” drop-down, plus extensions and many other items (including kitControl objects not subclassed from Control Points, for example, “NumericConst,” “DegreeDays,” and “LeadLagRuntime,” as a few examples).
About Bql Query Match filters
Use the Match filter when you wish to further limit proxy point candidates. For example, you may wish to filter on object names (this translates to displayNames).
To see the match dialog options, click the plus (“+”) icon in the far right corner of the Bql Query
Builder dialog, and use Match entry fields as needed (
).
158
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network
Figure 69 Expand Match to see fields, use entry fields as needed
About the Bql Query Builder
example above, the Match filter is set to: displayName, like, “Fan*”. This point discover returns components (within the Find parameters) that are named beginning with “Fan”.
This match would include all components named “Fan”, “FanAhu1”, “Fan21”, “Fantastic”, and so on. However, components named “FAN” or “FAN21” would not be included (case-sensitivity), nor would components named “AhuFan” or “BFan” be included—no leading wildcard (“*”) was used.
Note: You can click the Match plus (“+”) icon multiple times to add multiple match lines, and configure each match line differently, as needed. Click the minus “–” icon to remove a match line.
If you have multiple match lines, note the drop-down selection beside Match (“All”, “Any”) becomes important, and works as follows:
•
All
— Works as “AND” logic, where a match must occur as specified on every match line.
•
Any
— Works as “OR” logic, where a match must occur as specified on any match line.
About Bql Query Save, Load, and Edit
Save the setup of any Bql query by simply clicking the Save query icon (diskette). This produces a Save Query dialog in which you give the query a unique name (
).
Figure 70 Save and name Bql Query
Saving a query allows you to recall it later to either use directly, or to modify further as a “starting point” for another query. You can save as many Bql queries as you need. You can also edit a saved query (meaning rename it or reorder it in your list of saved queries).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
159
About the Niagara Network
Chapter 4 — Driver architecture
About the Bql Query Builder
Note: Saved queries are unique to your Workbench instance, and not to any particular station.
To recall a saved query, click the Load saved query icon (folder), and make a selection, as shown in
.
Figure 71 Load saved Bql Query
This loads that query into the Bql Query Builder dialog, where Find and Match entries automatically change to reflect how that query was constructed.
To edit saved queries, click the Edit saved query icon (note pad). This produces a Save
Query
dialog in which you can rename and/or reorder the queries in the list (
).
Figure 72 Edit saved Bql Queries
Note: If you are interested in the Baja Query Language (BQL), you can learn about queries within the Edit dialog. Make the dialog window wider, and study the syntax of a saved queries. For detailed information about queries, see “BQL” in the Niagara Developer Guide.
160
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network Niagara proxy point notes
Niagara proxy point notes
Niagara proxy points are always read-only types (BooleanPoint, EnumPoint, NumericPoint, and
StringPoint), see “About point types” on page 53. No other types are available.
However, if the source component is a writable point type, any actions (commands) for that component are available in the Niagara proxy point, as shown in
.
Figure 73 Niagara proxy point for writable point includes actions
Other concepts about Niagara proxy points are explained in the following sections:
•
Proxy of a proxy, other candidates
•
Link control and Niagara proxy points
Proxy of a proxy, other candidates
Often, the (remote) source component of a Niagara proxy point is itself a proxy point, typically under the Points extension of device in a field bus driver network (Lonworks, Bacnet, and so on). Or, if the remote station is in a JACE with its own I/O, the source component may be an Ndio proxy point.
Another possibility is for the (remote) source component to be a specific slot of a point extension under a point, for example, the Total property of a NumericTotalizerExt. In other cases, the (remote) source component may be a kitControl type, such as one of the Math or Logic types, or one of the other more complicated types (for example, a LoopPoint or DegreeDays object).
Regardless of the source component, you model all remote Niagara data selecting from the “atomic” model of the four read-only point types. If you need multiple pieces of data from the same source Niagara object, you will need to create that many Niagara proxy points.
Link control and Niagara proxy points
Because Niagara proxy points have no inputs, you cannot link into them from local station logic (even if the remote source component is a writable type). If you need this “inter-station link control,” you must make another Niagara proxy point (in the remote station) that proxies whatever local source component you need for the link.
Consider a Niagara proxy point for a BooleanWritable that controls a fan. You wish to provide link
control from a local And object, controlling at priority level 7. Figure 74 shows these objects.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
161
About the Niagara Network
Figure 74 Local object cannot link into Niagara proxy point
Chapter 4 — Driver architecture
Station Alarms notes
In the example above, you cannot link into the Niagara proxy point “BFanBO_1.”
So in the other (remote) station, you must make a Niagara proxy point for the And object, then link its output to the source point for “BFanBO_1.”
shows the wire sheet views with these objects.
Figure 75 Source control object now a Niagara proxy point in remote station
In a typical Supervisor station (with many Niagara proxy points), usually not much direct link control is needed, so this rarely applies. In addition, the schedule import/export mechanism allows for central scheduling control using local (imported) schedule components.
However, if you are engineering applications between JACE stations that require link control, please understand you must always use Niagara proxy points in this fashion.
Station Alarms notes
To configure alarms in one station to be received in another station, you must add a StationRecipient
StationRecipient. See “About alarm class” on page 204 for more details.
It is not necessary to use the same AlarmClass components in the two stations (although that is one approach). In the receiving station (often, the Supervisor), if desired you can configure all alarms from a remote station to route to a single local AlarmClass. Do this in the Alarms extension under the
NiagaraStation that represents the remote JACE. See “Alarms extension properties” on page 119.
Note: In the receiving station’s AlarmService, if you want the remotely-generated alarms to appear in any alarm consoles, make sure to link the associated AlarmClass components to the necessary AlarmConsole components.
162
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network
Station Schedules import/export notes
Station Schedules import/export notes
You configure sharing of NiagaraAX schedule components between stations from the “receiving
side” station using the Niagara Schedule Import Manager
. After you import each schedule component, a corresponding “schedule export descriptor” is automatically created in the “sending side” sta-
tion. If necessary, you can review and adjust these export descriptors using the Niagara Schedule
dialog.
Under a NiagaraStation device, the Schedule Export Manager works uniquely from other drivers, so it is explained in more detail in the following sections.
•
Niagara schedule import/export default configuration
•
•
“Schedule Import or Export “gang” edits” on page 145
Niagara schedule import/export default configuration
By default, when you import a schedule under a NiagaraStation using the
the import/export setup is initially configured on both sides as follows:
• Receiving (slave) side:
Niagara schedule component with a ScheduleImportExt configured with “Execution Time” of
Manual. The source schedule’s configuration is imported (“pulled”) only once, upon creation. If desired, you can manually Import it again.
• Sending (master) side:
Corresponding schedule export descriptor with an “Execution Time” of Interval, at 5 minute rate.
You can adjust this in the export descriptor using Schedule Export Edit
.
To review all properties of a schedule export descriptor, including status properties, you can view its property sheet—in the Nav tree under Schedules, simply double-click its Export icon.
Note: Default configuration does not mean the same schedule configuration is continuously exported (“pushed”) to the remote schedule at this rate. Instead, the export descriptor keeps a “Subordinate Version” timestamp from the last export. If a configuration change occurs, the export descriptor compares the subordinate version time against the configured interval, and if necessary exports the schedule to the remote station.
The default “master push” configuration is the most efficient (and recommended) way to keep imported schedules synchronized. However, if the stations are installed on a network configured such that this method is not allowed (perhaps firewall issues), you can configure things in reverse. This means configuring receiving side ScheduleImportExts with “Interval” execution times (to periodically “re-pull” schedule configuration), and set corresponding schedule export descriptors to be disabled.
Schedule Export Edit
In the Schedule Export Manager , you adjust any schedule export descriptor(s) shown by selecting
(highlighting) it and clicking the Edit
button at the bottom of the view (or on the toolbar).
Note: Unlike in other Manager views, a double-click on a descriptor is not the same as
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
163
About the Niagara Network
Chapter 4 — Driver architecture
Station Schedules import/export notes double-click provides the Scheduler view for that exported schedule component. This can be useful to review and if necessary, make changes to its configuration. For more details, see
“Schedule component views” on page 294.
Edit. The Edit dialog appears with the schedule export descriptor listed (
).
Figure 76 Edit dialog in History Export Manager
Note: The Edit dialog shows some configuration properties of the schedule export descriptor.
To access all properties, (including all status properties) go to its property sheet. Note that if you double-click the Nav tree icon for an export descriptor, its property sheet displays.
The following related topics also apply:
•
Niagara Schedule Export properties
•
Niagara schedule import/export default configuration
•
“Manager table features” on page 113
Niagara Schedule Export properties. Properties in the Edit dialog of a schedule export descriptor are:
• Enabled
By default true. While set to false (export descriptor disabled), export connections are not attempted to update the remote (imported) schedule.
• Execution Time
Determines when an export update is made to the remote (imported) schedule, providing that a
configuration change occurred in the local schedule that requires synchronization (export). For related details, see
“Niagara schedule import/export default configuration” on page 163.
Options are either Daily, Interval (default), or Manual. If Manual, the following properties are unavailable:
•
Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
•
Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds and this interval is added to the Time of Day. May prevent “server flood” issues if too many schedule exports are executed at the same time. Default is zero (no randomization).
•
Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
•
Interval (Interval)
164
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 4 — Driver architecture
About the Niagara Network Station Schedules import/export notes
Specifies repeating interval for export execution. Default is every 15 minutes.
•
Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
165
About the Niagara Network
Chapter 4 — Driver architecture
Station Schedules import/export notes
166
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 5 — Field Bus Integrations
Common field bus concepts
Field Bus Integrations
Driver architecture framework
For purposes here, a field bus integration is any NiagaraAX driver besides the niagaraDriver (Niagara
Network). All Niagara AX drivers resemble each other in basic architecture, including the Niagara
Network. For more details, see “About Network architecture” on page 90, and
However, field bus integrations such as Bacnet, Lon, Modbus, and others each have unique characteristics and features. This section provides an overview of topics related to these drivers.
Common field bus concepts
Field bus drivers associate with one or more communications ports and use a specific communications protocol.
Driver architecture framework
Network architecture” on page 90.
Learn versus New devices and points
Many, if not most, drivers provide the ability to “learn” devices and data points while connected to that particular field bus. Exceptions include drivers where the field bus protocol does not provide the ability for this, for example, any of the Modbus drivers.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
167
Common field bus concepts
Chapter 5 — Field Bus Integrations
Learn versus New devices and points
168
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
About Histories
In Niagara, a data log is referred to as a history. Histories are ordered collections of timestamped records that are stored in a persistent database in real time - not in flash memory. A single “history” is a collection of specific data values from a component within any station - local or remote. Histories are organized by their source station (device).
The following topics are relevant to understanding histories:
• History Services
The History Service, the Audit History service and the Log History service provide support for logging data in a Niagara station. In order to provide database support for histories in a Niagara station, the station must contain the History Service. Refer to
“About the history service” on
“About the log history service” on page 173 for information about those services.
• History ORD scheme
Once you have a history service running, you can access histories that you create in the database using the “history” ORD scheme. The unique history scheme name “history” and each unique history ID provide identification for the individual histories. All history collections are identified by this unique id. For information on using the ORD scheme to access individual histories, refer to
• History space
History space provides a means for viewing and working with history files in the history database. History space is visually represented in Workbench as a node in the nav tree and may be accessed by using the nav tree or by using the Open ORD dialog box. Views on the History space include the following: History Chart Builder, Database Maintenance, Nav Container View. For more information about history space and history space views, refer to
“Types of history space views” on page 174.
• History views
History views present the history information in various formats for both analysis and editing.
Refer to
“Types of history views” on page 178.
• History logging process
Using histories involves a process of collecting, storing and archiving data. You can configure the history collection process to collect the data that you need and store the history records where you
• History Configuration
History configuration includes working with parameters such as ID, history source, timezone, record type, and more. For more details on configuration, refer to
“Configure history extensions” on page 185.
• History data editing
You can edit and filter the history data in workbench using the history editor view (described in
“About the history editor view” on page 182). The editing process is described in more detail in
“About editing history data” on page 189.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
169
Types of History Services
Types of History Services
History services are available in the History Palette, as shown in
.
Figure 1 History services in the history palette
Chapter 6 — About Histories
Each service is described in the following sections:
•
“About the history service” on page 170
•
“About the audit history service” on page 172
•
“About the log history service” on page 173
About the history service
To use histories, each station must contain a single history service that provides http access to all of the histories in a station. This service is responsible for creating the history database, as well as enabling the collection and storage of histories in the database. If you do not have the history service in your active station, you can add it by dragging and dropping a copy from the History Palette, as shown in
.
Figure 2 Adding the history service
The history service manages histories in ways that are not always visible to the user, including the following:
• identifies histories
when the service is started (normally this is whenever the station is started) all existing histories are added to the service.
• life cycle management
handles history management functions, such as creation and deletion of individual histories.
• namespace
maintains the naming convention (namespace) for all histories.
170
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Types of History Services
• configuration
maintains a global default configuration for the histories.
The history extension manager and the history property sheet are two views of the history service that provide ways to work with history extensions. Refer to the following sections for more information about these views:
•
About the history extension manager
•
About history service property sheet
About the history extension manager
As the default view of the history service, the history extension manager shows all history extensions in the station and displays their current status. Using this view as both a management and navigational tool, you can double-click on any point, extension, or history name to go directly to that object in the station. You can also Enable, Disable, or Rename any collection from here by using the right-click command on any extension. If a history is disabled, its row is purple. If a history is not collecting, its row is orange. See
“history-HistoryExtManager” on page 424 for more information about the history
extension manager.
Figure 3 History extension manager
About history service property sheet
The history service property sheet, shown in
, includes the following property:
• Max Open Time
this is an editable parameter for setting the amount of time that the history database may remain open without being accessed before it is subject to being closed by the Close Unused His-
tories
action. If the history is accessed more frequently than the Max Open Time, it is not closed when Close Unused Histories action is invoked.
Figure 4 History service properties
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
171
Chapter 6 — About Histories
Types of History Services
History service actions
History service actions are available from the popup menu when you right-click the HistoryService node in the nav side bar pane. Available actions include:
• Save Db
this action initiates a save of all histories to the history database.
• Close unused histories
this action closes any histories that have not been accessed within the Max Open Time (this time is set in the history service property sheet).
About the audit history service
The Audit History Service keeps a history of the changes that are made by users. If this service is enabled, it registers itself as the auditor for the system when the service is started. The easiest way to add the audit history service (if not already present) is through a simple drag and drop method from the History Palette (under the HistoryService) to the services area of the nav side bar pane, as shown
Figure 5 Adding audit history service
When enabled, the Audit History Service logs all property changes and all actions taken on a component, such as the following:
• Property changed
• Property added
• Property removed
• Property renamed
• Properties reordered
• Action invoked
You can view the Audit History Service properties, enable or disable the Audit History Service, and
set record capacity parameters from the Audit History Service Property Sheet, as shown in Figure 6
.
172
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Figure 6 Audit history service properties
Types of History Services
Refer to
“About user audits” on page 278 for more details.
About the log history service
The Log History Service keeps a History of Niagara log records when it is enabled. This service maintains a buffered history (“LogHistory”) of some of the messages seen in the station’s standard output. This can be very helpful when you are troubleshooting problems with a station. If a station has
Log History Service enabled, you can check the log history for recent error messages. Refer to the
Platform Guide section “Station output” for more information about output messages.
The Log History Service is available in the History Module. The easiest way to add this service (if not already present) is through a simple drag and drop from the History Palette (under the HistorySer-
vice) onto the services area of the nav side bar pane, as shown in Figure 7 .
Figure 7 Adding log history service
You can edit the Log History Service properties and set configuration properties in the property sheet,
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
173
Types of history space views
Figure 8 Log history service properties
Chapter 6 — About Histories
In addition to the standard HistoryConfig properties, the following properties are available for editing:
• Enabled select the true option to enable or the false option to disable the Log History Service.
• Minimum Severity you can choose the level of output that you want to record by setting the log level Minimum
Severity property. This property is the lowest-level station output message that you want to log.
The default log level for Minimum Severity is Error. You can change this to Warning., Trace, or Message.
Types of history space views
The three history space views shown in Figure 9 and listed below are particularly helpful in working
with multiple histories:
Figure 9 History space views
• Chart builder view
• Database maintenance view
• Nav container view
Use this view to display all histories in the station. See
“About the nav container view” on page 177
174
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Types of history space views
About the chart builder view
want to use to create a chart.
Figure 10 Chart builder view
The left side of this view contains the available history window. This window displays all histories that are available in your local station or any station histories that you import by means of the Niagara network or other network driver (for example, BacnetNetwork). Histories are grouped under the station by station name.
Note: The available histories are the same histories that are displayed under the history space node in the nav sidebar.
The right side of the view contains the following fields and options for configuring the chart that you want to build:
• Time Range
Select a time parameter option from the list, including an option that allows you to set a specific time range using the Edit Time Range dialog box.
• Title
Type a title for your chart in this text field.
• Show Grid Lines
Select yes or no to show or hide grid lines on the history chart.
• Selected histories target area
Drag and drop any available history (from the available history window on the left) onto this area.
• Build button
Click this button to build the chart using the histories that are in the selected histories target area.
• Clear button
Click this button to remove histories from the selected histories target area.
Figure 11 shows an example of chart that displays two histories.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
175
Types of history space views
Figure 11 History chart using chart builder view
Chapter 6 — About Histories
About the database maintenance view
The database maintenance view is shown in Figure 12 . Using this view, you can clear records and
delete complete histories from your history database. Select the database maintenance view by selecting the history space node in the nav sidebar and using the view selector menu or the popup menu to choose the database maintenance menu item.
Figure 12 Database maintenance view
The left side of the histories area contains the available histories window. This window displays all histories that are available in your local station or any station histories that you import by means of the Niagara network or other network driver (for example, BacnetNetwork). Histories are grouped under the station by station name.
Note: The available histories are the same histories that are displayed under the history space node in the nav sidebar.
The right side of the histories area contains the targeted histories window. This window displays the histories that are affected when you click the Run Maintenance button. Move the histories that you want manage into this window using the control buttons, as described below:
Controls and options for the database maintenance view are described in the following list:
• Add history button (right arrow)
Click this button to move histories that are selected in the available histories window to the targeted histories window.
• Remove history button (left arrow)
176
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Types of history space views
Click this button to move histories that are selected in the targeted histories window to the available histories window.
• Clear Old Records option
Select this option and use the Before date selector to remove records, based on date, from the histories that are in the targeted histories window.
• Before date field
Use this field with the Clear old records option to set the year, month, day, and time parameters that you want to use for removing old records.
• Clear all records
Select this option to delete all records from the selected history database.
• Delete Histories
Select this option to delete all histories that are in the targeted histories window.
• Run Maintenance button
Click this button to execute the option that you have selected on the histories in the targeted
histories
window.
About the nav container view
sented in the history space. You can double-click on any of the station icons to display the individual histories that are children to the station that is represented in the Name column of the nav container view. Double click on a history in this view to display the history in the History Chart view.
Figure 13 Nav container view
In this view you can select any history and switch to any other view of that history (see
rename histories, using the popup menu.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
177
Chapter 6 — About Histories
Types of history views
Types of history views
You can view histories in different ways in Workbench. Figure 14 shows a menu of views that are
available using either the Workbench view selector or a view popup menu. These views are listed and described in the following sections.
Figure 14 History views available from popup menu
• History Chart
• Collection Table
shows a tabular view of any data (in this case history data) that you can export and view in the following formats: PDF, CSV, Text. Use the Table Options menu in the top right corner of the collection table to modify the table view or to export the data in the view, as desired.
• History Table
shows a tabular view of history data that you can export and view in the following formats: PDF,
CSV, Text. In addition, you can modify the tabular view of history data by choosing to show or hide columns and by filtering the data based on date and time. Use the Table Options menu in the top right corner of the history table to modify the history table view or to export the data in the view, as desired.
• History Summary
shows a summary of the history’s status and configuration properties.
• History Editor
allows you to actually edit data and filter histories.
About the history chart view
An example of the history chart view is shown in
. This is the default view of the history, so if you double-click on a history in the nav sidebar, the history chart view will appear.
178
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Figure 15 History chart view
Types of history views
The history chart view contains the following:
• Time Range options
this option list is located in the top left corner of the history chart view. You can select one of the pre-defined times or select the Time Range option that allows you to set a specific time range using the Edit Time Range dialog box.
• Title
The title appears at the top of the view with the history name for your chart in this text field. If you rename the history the history chart title will update to display the new name when you refresh the screen.
• x and y axes
History values are displayed along the y axis and time is displayed along the x axis of the history chart view.
About the collection table view
An example of the collection table view is shown in
.
Figure 16 Collection table view
In addition to a title bar that displays the number of rows in the table, the collection table has the following four columns:
• Timestamp
indicates the time the recorded value occurred.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
179
Chapter 6 — About Histories
Types of history views
• Trend Flags
displays trend flag information about the recorded data - for trend record types. These flags provide extra context information about the record data. For example: “Start”, “OutofOrder”, “Hidden”, “Modified”, and “Interpolated” are some of the possible trend flags.
• Status
displays the status of the history’s parent component; for example, “OK” or “null”.
• Value
displays the record value.
About the history table view
The history table view displays history records with up to four columns of data that you can custom-
.
Figure 17 History table view
In addition to a title bar that displays the history name and number of records in the table, the history table has the following four columns:
• Timestamp
indicates the time the recorded value occurred.
• Trend Flags
displays trend flag information about the recorded data - for trend record types. These flags provide extra context information about the record data. For example: “Start”, “OutofOrder”, “Hidden”, “Modified”, and “Interpolated” are possible trend flags.
• Status
displays the status of the history’s parent component; for example, “OK” or “null”.
• Value
displays the record value.
Use the Table Options menu in the top right corner of the history table to modify the history table view or to export the data in the view, as desired. The history table options menu includes the following items:
•
Reset column widths
sets all columns in the table to the default widths.
180
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
Types of history views
•
Export
opens the Export dialog box for exporting table records to PDF, text, or CSV formats.
•
Timestamp
toggles the Timestamp column on or off.
•
Trend Flags
toggles the Trend Flags column on or off.
•
Status
toggles the Status column on or off.
•
Value
toggles the Value column or off.
About the history summary view
The history summary view is shown in
Figure 18 . This view displays the details of the history’s status
and configuration properties in two groups, as follows:
Figure 18 History summary view
• Status parameters
these parameters display data that is updated as of the time you select the history summary view.
• Record count this is the current number of total records, as of the Last Timestamp.
• First Timestamp this is the date, time and timezone information for the initial history record.
• Last Timestamp this is the date, time and timezone information for the latest recorded history record.
• Configuration parameters
these parameters display data that identifies and characterizes the specific history that.
• Id this parameter is comprised of two parts: <deviceName> and <historyName>. For example, the following string: “myStation/myHistory”. This Id is unique for each history.
• Time Zone this parameter displays the time zone that is assigned to the history.
• Record Type displays the type of data stored in this history. For example, “NumericTrendRecord”, “Bool-
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
181
Chapter 6 — About Histories
Types of history views eanTrendRecord”, “LogRecord”.
• Capacity displays the maximum number of records that are allowed to be stored in the history database.
• Full Policy displays what is done when the capacity is reached. For example, “Stop” or “Roll”.
• Interval displays the amount of time between the records in a history. If the history is collected at a regular interval, this field will display “regular” with the time regular interval time. If not, as in the case of a Change of Value (COV) setting, this field will display the word “irregular” only.
About the history editor view
An example of the history editor view is shown in
. The history editor view allows you to edit data and filter histories. This view also allows batch editing (selecting multiple rows and using the popup menu or the Edit menu).
Figure 19 History editor view
The history editor view is comprised of the following main areas:
• Title bar
this area displays the history name and number of records in the history.
• Toolbar icons
• Time range options
this menu is located in the top left corner of the history editor view. You can select one of the predefined times or select the Time Range option that allows you to set a specific time range using the Edit Time Range dialog box.
• Table options menu
Use the Table Options menu in the top right corner of the history editor view to change which columns are displayed or to export the data in the view, as desired. The history table
options
menu includes the following items:
• Table columns
The history editor table has the following four columns:
182
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
About the history process
• Timestamp indicates the time the recorded value occurred.
• Trend Flags displays trend flag information about the recorded data - for trend record types. These flags provide extra context information about the record data. For example: “Start”, “OutofOrder”,
“Hidden”, “Modified”, and “Interpolated” are possible trend flags.
• Status displays the status of the history’s parent component; for example, “OK” or “null”.
• Value displays the record value.
• Control buttons
The following two control buttons are used to initiate record editing in the history editor view:
•
Edit
this button is available when one or more records are selected in the history editor table. When you click this button, the Edit Records dialog box appears.
•
Select Outliers
this button is available when the outlier configuration parameters are active (when the option box is selected in the Configure Outliers dialog box). When you click this button, the
Configure Outliers
dialog box appears.
Use the Table Options menu in the top right corner of the history table to modify the history table view or to export the data in the view, as desired. The history table options menu includes the following items:
•
Reset column widths
sets all columns in the table to the default widths.
•
Export
opens the Export dialog box for exporting table records to PDF, text, or CSV formats.
•
Timestamp
toggles the Timestamp column on or off.
•
Trend Flags
toggles the Trend Flags column on or off.
•
Status
toggles the Status column on or off.
•
Value
toggles the Value column or off.
About the history process
There are essentially three steps in the “history logging” life cycle, as shown in Figure 20 :
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
183
Chapter 6 — About Histories
About the history process
Figure 20 Simplified history process
• collect
involves defining the parameters that specify what data will be recorded and when (or how often) it will be recorded. For example, you can collect data whenever a change of value occurs - or at a regular time interval that you specify.
To collect history information you need to:
• Add history extensions to a component (refer to
“Add history extensions to a component”
)
•
Configure the extensions (refer to “Configure history extensions” on page 185)
•
Use a valid history name (part of configuration, see, “About history names” on page 187)
Refer to
“Add history extensions to a component” on page 185 for more details.
• store
involves defining the parameters of the history database file. For example, you can customize the name of the database file, define the maximum number of records to save, and choose metadata to
add to the records. Refer to “Configure history extensions” on page 185 for more details.
• archive (transfer)
includes importing and exporting records from one station to another station. For example, you can limit your local station records to a small number that you specify and archive all records to
another station. Refer to “Archiving” on page 188 for more details.
You can add extensions to a component’s property sheet in order to extend the functionality of the component. By adding a history extension, the real-time value or status of the component’s output can be collected as a time-stamped entry in the associated history table. History extenstions are available in the history palette, as shown in
Figure 21 . The history table is not stored as part of the component’s
data but is a separate collection of data simply referred to as the history.
Figure 21 History extensions
184
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
About the history process
Add history extensions to a component
Extensions come in different types to match the data type of the component and the collection method desired. You can add history extensions by dragging them onto your property sheet or into your nav side bar pane from the history palette (see
Figure 22 History extensions in Workbench history palette
For more details about history extensions, refer to “About history extensions” on page 67.
Extension types include:
• BooleanChangeOfValue
used to collect boolean values whenever those values change.
• BooleanInterval
used to collect boolean values at specified time intervals.
• NumericChangeOfValue
used to collect numeric values whenever those values change.
• NumericInterval
used to collect numeric values at specified time intervals.
• EnumChangeOfValue
used to collect integer values (enumerations) whenever those values change.
• EnumInterval
used to collect integer values (enumerations) at specified time intervals.
• StringChangeOfValue
used to collect a string of characters whenever the characters change.
• StringInterval
used to collect a string of characters at specified time intervals.
For more details about extension types, refer to “Types of history extensions” on page 67.
Configure history extensions
When a history extension is first added to a component, it is set to be disabled by default. All that is really necessary to enable collection is to change the 'Enable' property to 'true.' Of course, you may desire some other property changes to better configure the collection to suit your actual needs.
Some configuration properties are common among all history extension types. A few properties are unique to the data type or the collection type. Following, is a list of all the properties available.
• Status
read-only field that tells the user the current status.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
185
Chapter 6 — About Histories
About the history process
• Fault Cause
read-only field that displays a reason that the extension is not working.
• Enabled
set either 'true' or 'false' to disable or enable the history extension.
• Active Period
specifies the days of the week as well as start and end times for record collection.
• Active
read - only value that indicates whether or not (true or false) the history collection is active (as defined by the Active Period parameters.
• History Name
is a formatting convention used to provide a way to consistently name histories using a standardized formatting pattern.
The history name format field provides a way to automatically name histories any time a new history is created. The format %parent.name% is the default history name format and this will
create a name based on the parent object. Refer to “About history names” on page 187 for more
details about naming histories.
• Change Tolerance
for COV based collections, the monitored variable has to change at least this much to be logged as a changed value.
• Interval
for Interval-based collection, the cycle time, or how often the history parameters are checked.
Any time you change this parameter, a new history is created (or “split-off”) from the original history because histories with different intervals are not compatible.
• History Config
These properties set up the attributes of the History record.
• Id a unique identification for each history. The id value is the name that was automatically created by the History Name Format or the manually created in the name field or rename dialog box.
Figure 23 History Id
• Source a read-only field that displays the ORD of the active history extension.
• Time Zone a read-only field that displays the time zone of the active history extension.
• Record Type displays the data that the record holds in terms of: extension type (history) and data type:(BooleanTrendRecord, NumericTrendRecord, and so on).
• Capacity allows you to set a finite number of records to collect or to choose to collect an unlimited number of records. If you choose the Record Count option, an additional “records” field displays. In the “records” field, type in the maximum number of records that you want to save in the history database.
• Full Policy - (Roll or Stop) allows you to choose what to do when the Capacity number is reached. The Roll option drops
186
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
About the history process off the oldest record to make room for the newest record. The Stop option simply causes the history to stop recording.
• Interval a read-only field that displays the selected collection type: regular on interval.
• valueFacets allows you to use the Edit Facets dialog box to choose how you want to display the logged data.
About history names
By default, when a history extension is added to a component, a history format default string is set to the following: “%parent.name%”. This string automatically names any histories with the name of the parent component and appends a sequential number to additional names, as necessary. For example, a NumericWritable component will automatically be named “NumericWritable1” - then if that component is duplicated, the name for the history will be duplicated and incremented to
“NumericWritable2”. You may add a literal name in front of, or after, the “%parent.name%” string to customize it without losing the automatic naming feature.
Note: If you use a literal name and not a script to name a history, you lose the automatic incrementing feature that the script provides. Duplicating extensions that have a literal name duplicates the exact literal name and therefore creates an invalid (non-unique) name. In this case, you must rename each duplicated history manually to create a unique name and avoid a fault condition.
As described in “Configure history extensions” on page 185, and illustrated in
names are part of the unique history extension property “Id”. When you rename a history at the history extension, you are renaming the history at its “source”. Therefore, the history configuration and
the history Id both change. This concept is illustrated in Figure 24 .
Figure 24 Renaming a history in the history extension
If, however, you rename a history in a “history space” view, such as under the history space node in the nav sidebar, or in the nav container view, you are changing the name of the history as it has been saved in the history space–not at the configuration (or origination) level. Therefore, the history Id is not changed and the history extension continues to produce records under the original history name as long as that history extension is active and enabled. This results in a history “split”; the newly-named history is no longer updated, as of the time of the renaming, but it contains all the records up to that time. In this scenario, a history under the original name begins with the first record after the renaming
and continues recording as configured. This concept is illustrated in Figure 25 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
187
Chapter 6 — About Histories
About the history process
Figure 25 Renaming a history in the history space
Following, is a list of history renaming locations and how they affect history naming.
• rename a history in the property sheet view
here you edit the actual history extension. The history Id is changed and there is no history split.
• rename a history in the history nav sidebar view
here you are editing the history in the history space and not actually changing the history ID.
Renaming here causes a history to split.
• rename a history in the history extension manager view
here you edit the actual history extension. The history Id is changed and there is no history split.
• rename a history in the history nav container view
here you are editing the history in the history space view and not actually changing the history ID.
Renaming here causes a history to split.
Archiving
Archiving is the process of saving a history out to a different location (station) from where it was originated. There are two general methods (or directions) for archiving, as described below:
• Pushing data (exporting histories)
is the process of exporting history data and is done using the history export manager, shown in
. For details about exporting histories, refer to “History Export Manager” on page 137.
Figure 26 Niagara history export manager
• Pulling data (importing histories)
188
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 6 — About Histories
About editing history data is the process of importing history data and is done using the history import manager, shown in
. For details about importing histories, refer to
“Schedule Import Manager” on page 143.
Figure 27 Niagara history import manager
About editing history data
The history editor view, as described in
“About the history editor view” on page 182, provides the
ability to review and modify the history data that you have collected.
In some cases, you may want to search through the history data and look for unusual data or “outliers.” An “outlier” is a data value that is far apart from the rest of the data; an extreme value that is either much lower or much higher than the rest of the values in the data set. Outliers are known to skew means or averages, so it may be helpful to identify and edit or hide this data. This doesn’t mean that the data point is necessarily bad – but in most cases the information is more helpful without the inclusion of this “unusual” data.
Caution: It is possible to alter good data and miss filtering some bad data points using the history editor view.
Workbench provides the ability to find and edit outliers based on parameters that you specify. The
Configure Outliers
dialog box, shown in
Figure 28 , appears when you click the Configure
Outliers
icon in the toolbar menu. Refer to
“History editor toolbar icons” on page 476 for a list of
toolbar icons specific to the history editor view.
Figure 28 Configure Outliers dialog box
•
Configure Outliers
check box
Outlier filtering is disabled by default. Select the check box to enable the outlier filtering feature and use the parameters that are displayed in the dialog box. Clear the check box to disable outlier data filtering. When outlier parameters are enabled, the Window and the Percent of Std
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
189
Chapter 6 — About Histories
About editing history data
Deviation
fields are available and allow you to specify the “intensity” of the search for outliers in the data.
• Window
Enter an integer in the Window field to define the number of surrounding data points to consider when determining whether a given point is an outlier. For example, if you use the default value of
“4”, it will look at the two points before and after the point under investigation (PUI). This is a surrounding “window” of 4 points–from which a standard deviation will be calculated and used with the percentage parameter, as described, below.
• Percentage
Enter a value in this field to specify the percent of standard deviation (calculated from the window of points) to apply for identifying whether or not the PUI should be considered a valid value (not an outlier). If the PUI falls outside of this valid range, then it is considered to be an outlier and its value is replaced by the linear interpolation of the surrounding 2 valid points. If the PUI falls within the range, then the data point is used and considered valid.
190
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Overview of the alarming process
About alarms
• Alarm
Used to indicate that some value is not within an appropriate or expected range. For example, the normal operating temperature range of a device may be 70 to 100 degrees F. You can set the “out of range” parameters to generate an “alarm” if the operating temperature exceeds the upper limit or goes below the lower limit of this range.
• Alert
This is an alarm that does not have a “normal” state. For example, a motor may require lubrication after every 400 hours of operation (this is not an “out of range” condition). Using the alarming function in Workbench, you can configure an extension to send an email alert to you when the
400 hours runtime has accumulated on the motor.
Each alarm is a single record in the database that changes throughout its life cycle. An alarm has four general states that it may be in:
• new alarm
is the initial state of an alarm and this state remains in effect until that alarm is acknowledged.
• acknowledged alarm
is an alarm that has been acknowledged by the recipient. Acknowledged alarms may be normal alarms.
• normal alarm
is an alarm that has a current status of “normal”.
• acknowledged normal alarm
is a normal alarm that has been acknowledged.
Note: An “Open Alarm” is an alarm that is not acknowledged and in normal status (or acknowledged and in alert status).
Overview of the alarming process
NiagaraAX alarming is comprised of three primary actions:
•
Creating alarms (for more details refer to “About alarm sources” on page 192)
•
Routing alarms (for more details refer to “About the alarm service” on page 196)
•
Managing alarms (for more details refer to “About alarm database maintenance” on page 201
Figure 1 Simplified alarm process
Under these three processes NiagaraAX provides highly specific and flexible alarming life cycle management, including the following alarming functions:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
191
About alarm sources
Chapter 7 — About alarms
About alarm extensions and components
• creating alarms
values are outside of “normal” range. Those alarms are then handled by the alarm service (refer to
“About the alarm service” on page 196).
• routing alarms
alarms are handled by the alarm service which, in addition to allowing you to specify routing destinations (including archiving destinations), provides notification and acknowledgement parameters.
• notification
Alarms are routed to one or more recipients based on their alarm class. This includes notification by email, at the alarm console, a lineprinter, or at remote stations.
• acknowledgment alarms may require a response from those who are notified.
• managing alarms
alarms are archived in records that are managed by the alarm database management interface.
The following list outlines the basic steps in the alarming process:
• add alarm extensions to components
Choose alarm extensions to match the component data type.
• configure alarm extensions
Configure the alarm parameters to define when a component is in an alarmed state.
• route alarms
Configure the alarm parameters to define where an alarm record is sent.
• manage the alarm archive
Use the alarm archive management tools to manage the storage of all alarms.
About alarm sources
The parameters that are set in a point’s “alarm point extension” determine when that point is in an
“alarmable” condition. The alarm extension indicates routing options, issues alarms to the alarm service, and updates the alarm to reflect a status change when the parent point goes back to a normal state. The extension also notifies the point that an acknowledgement has been received. To set up the alarm source on an object you need to:
•
add a proper alarm extension to the component (see About alarm extensions and components
)
•
configure the alarm extension to meet your needs (see About alarm extensions
)
About alarm extensions and components
To set up alarming on a component you need to add an alarm extension to the component’s property sheet. Refer to
“About alarm extensions” on page 65 for more details about the alarm extensions.
Alarm extension types must match their parent component type. For example, an OutOfRangeAlarm-
Ext goes with a Numeric point type and a BooleanChangeOfStateAlarmExt goes with a Boolean
192
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
About alarm sources About alarm extension properties point type. For a list of alarm extensions types and their associated point types, refer to
“Types of alarm extensions” on page 66.
Alarm extensions are contained in the alarm Palette, as shown in
.
Figure 2 Alarm extensions in alarm palette
alarming requirements. Refer to “About alarm extension properties” on page 193 for descriptions of
alarm property extensions.
About alarm extension properties
Each alarm extension has a set of configurable properties that allow you to specify the alarming conditions and certain routing options. The following list illustrates and describes each extension as it appears in a component property sheet.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
193
About alarm sources
Figure 3 Alarm extension properties
Chapter 7 — About alarms
About alarm extension properties
Following, are the alarm extension properties descriptions:
• Alarm Inhibit
a true value in this field prevents the creation of an alarm due to any transition or state change.
If an Inhibit Time is set (in the following property field) the inhibit is active for the amount of time set in that field. For example, if an Offnormal value is reached, a “toOffNormal” status will not be communicated unless there is an inhibit time set and that inhibit time is exceeded. When the state returns to Normal, a “toNormal” status will not be communicated. A false value in this field will prevent alarms from being inhibited. A difference between Alarm Inhibit and Alarm
Delay, is that the Alarm Inhibit is a boolean value (true/false) and may be controlled by another device (for example, an ON/OFF value of a fan).
• Inhibit Time
this time specifies the length of time that alarm generation is inhibited when the alarm inhibit property (see previous description) is set to true.
• Alarm State
this field displays the current alarm state of the component.
• Time Delay
alarm generation is inhibited for the duration of the time entered in this field. If a component remains in an alarm state for a time greater than the time delay, the alarm will be generated.
• Alarm Enable
select any of the options to individually enable the generation of alarms when the following transitions occur:
194
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
About alarm sources About alarm extension properties
• toOffnormal
• toFault
• toAlert
Note: No alarms will be generated unless an Alarm Enable option is selected.
• To Offnormal Times
displays the time that the component status changed to Offnormal.
• To Fault Times
displays the time that the component transitioned to a fault state.
• To Normal Times
displays the time that the component transitioned to a normal state.
• Time in Current State
displays the elapsed time since the component transitioned to the current state.
• Source Name
displays the name of the alarm source. If you use the default script setting %parent.displayName%, the source name field will show the “display name” of the alarm extension parent.
You can edit this script or type in a literal string to display.
• To Fault Text
enter the text that you would like to display when the component is in a fault state.
• To Offnormal Text
enter the text that you would like to display when the component is in a Offnormal state.
• To Normal Text
enter the text that you would like to display when the component is in a Normal state.
• Hyperlink Ord
enter or choose an Ord, a BQL Query or a path to a component that you would like to associate with an alarm status on the component you are configuring. When an alarm is reported in the console, the Hyperlink button is active and uses this path.
• Sound File
enter or choose the path to a sound file that will execute when the current component is in an alarm state.
• Alarm Icon
enter or choose the path to a graphic file that will display in the “timestamp” column of the alarm table in the Console Recipient view.
• Fault Algorithm
when available, displays fault parameters.
• Offnormal Algorithm
enter high and low limit parameters for numeric components and select the alarm value (on or off) to designate the alarm state for a boolean component.
• Alarm Class
select an alarm class to choose the alarm routing options for this component. Refer to
“About alarm class” on page 204 for details about alarm class.
• Meta Data
enter new facets using the meta data property. See
“About point facets” on page 58 for details
about facets.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
195
Chapter 7 — About alarms
About alarm extension properties About the alarm service
About the alarm service
Note: In addition to the standard file-based alarm service, described in this section, there is a memory alarm service available. These two services should not run in the same station. Refer to
“About memory alarm service” on page 197 for details about the memory alarm service.
Each station may contain a single alarm service that coordinates the routing of alarms within the NiagaraAX framework and maintains the alarm database. The alarm service is available in the alarm pal-
Figure 4 Alarm service in the alarm palette
If you do not have the alarm service in your active station, you can add it by dragging and dropping a
copy from the alarm palette, as shown in Figure 5 .
Figure 5 Adding the alarm service
The alarm service may contain one or more alarm classes (refer to
information about alarm class). An alarm class may route alarms to one or more alarm recipient types
(refer to
“Types of alarm recipients” on page 208 for more information about alarm recipient).
The routing process includes getting alarm acknowledgements from the recipients back to the source, and alarm notifications from the source to the recipients. The default view (wire sheet view) of the alarm service makes it easy to visualize the relationships between the alarm class and the alarm recipient. These relationships are created by linking the alarm class to the alarm recipient, as described in
“About alarm class” on page 204. In addition to the wire sheet and property sheet views, there are
several views of the alarm service. See
“Types of alarm service views” on page 198 for a description
of the alarm service views.
196
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
About memory alarm service
About memory alarm service
About alarm extension properties
Note: MemoryAlarmService is an alarm service that provides an alternative to the standard filebased AlarmService. A station should have only one alarm service. Do not install both the standard AlarmService and MemoryAlarmService on the same station.
Each station may contain a single alarm service that coordinates the routing of alarms within the Nia-
garaAX framework. The memory alarm service is available in the alarm palette, as shown in Figure 6 .
Figure 6 Memory alarm service in the alarm palette
If you do not have the memory alarm service in your active station, you can add it by dragging and
dropping a copy from the alarm palette, as shown in Figure 5 .
Figure 7 Adding the alarm service
Like the alarm service, the memory alarm service may contain one or more alarm classes (refer to
“About alarm class” for more information about alarm class). An alarm class may route alarms to one
or more alarm recipient types (refer to
“Types of alarm recipients” on page 208 for more information
about alarm recipient).
The routing process for the memory alarm service is the same as the standard file-based alarm service and includes alarm acknowledgements from the recipients back to the source, and alarm notifications from the source to the recipients. The default view (wire sheet view) of the alarm service makes it easy to visualize the relationships between the alarm class and the alarm recipient. These relation-
service. See “Types of alarm service views” on page 198 for a description of these views.
The main distinction of MemoryAlarmService is that when you use this service, alarms are not stored persistently on the station host (typically a Jace) as they are with the standard file-based alarm service. Choosing MemoryAlarmService might be appropriate for situations where you do not want to
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
197
Types of alarm service views
Chapter 7 — About alarms
About alarm service property sheet keep a large store of alarms on your host and are looking primarily for immediate alarm notifications.
Alarm records are stored in memory and therefore they are lost in the case of a power failure.
Types of alarm service views
You can view the alarm service in different ways in Workbench.
Figure 8 shows a menu of views that
are available using either the Workbench view selector or a popup menu.
Figure 8 Alarm service views available from popup menu
In addition to the standard Workbench views (Wire Sheet, Property Sheet, Category Sheet, Slot Sheet,
Link Sheet) there are several views specific to the alarm service, including the following:
• Alarm Service Property Sheet
The alarm service property sheet is a typical Workbench property sheet view that shows all the
alarm service slots. See “About alarm service property sheet”
for details.
• Alarm Extension Manager
The alarm extension manager is a view of the alarm service that provides a record of information about each alarm extension. See
“About alarm extension manager” on page 199 for details.
• Alarm Class Summary
The alarm class summary view provides a concise list of information relative to each alarm class.
Refer to
“About the alarm class summary view” on page 203
• Alarm Database Maintenance
“About alarm database maintenance” on page 201
About alarm service property sheet
alarm service displays all the recipients that are part of the alarm service and also has a capacity property that is visible and editable. The alarm service capacity property limits the number of records that are stored in the alarm service database. When the capacity is reached, the alarm records “roll”.
This means that the newer records overwrite the oldest records.
198
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm service views
Figure 9 Alarm service property sheet
About alarm extension manager
to “About alarm extension manager” on page 199.
About alarm extension manager
An example of the alarm extension manager is shown in
. The alarm extension manager view presents alarm extensions in a table with columns that can be added or deleted.
Figure 10 Alarm extension manager
The view has the following displays and features:
• Toolbar icon
the export toolbar icon is available on the toolbar when the alarm extension manager view is displayed.
• Title bar
appears in the top left corner of the view and displays the alarm extension manager view title.
• Extension total
appears in the top right corner of the view and displays the number of extensions that are in the view.
• Table options menu
Use the table options menu in the top right corner of the view to change which columns are displayed or to export the data in the view, as desired. The table options menu includes the following items:
•
Reset column widths
sets all columns in the table to the default widths.
•
Export
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
199
Types of alarm service views
Chapter 7 — About alarms
About alarm extension manager opens the Export dialog box for exporting table records to PDF, text, or CSV formats.
•
Point
indicates the point that is the parent of the listed alarm extension.
•
Extension
identifies the type of extension that is listed (for example: “OutOfRangeAlarmExt”, StatusAlarmExt”, or others).
•
Alarm State
displays the status of the listed alarm extension; for example, “High Limit” or “Normal”.
•
toOffnormal Enabled
indicates (as True or False) if the toOffnormal parameter of the extension is enabled (true) or not (false).
•
toFault Enabled
indicates (as True or False) if the toFault parameter of the extension is enabled (true) or not
(false).
•
Alarm Class
identifies the name of the alarm class that the extension is assigned to (defaultAlarmClass or other class).
• Color coding
a colored background on a row in the alarm extension manager table indicates that the alarm state of the parent component is not Normal.
• Hyperlinking
double-click on any row in the Alarm Ext Manager view and the view will change to the property sheet view of the alarm extension that you clicked on.
• Alarm extension editing (and batch editing)
select one or more (for batch editing) alarm extensions and use the popup menu (shown in
) to edit the extension(s).
Figure 11 Alarm extension manager popup menu
Edit alarm extensions from the alarm extension manager in the following ways:
•
toOffnormal Enabled
and toFault Enabled settings
You can toggle ON and OFF the toOffnormal Enabled and toFault Enabled parameters of each selected alarm extension using the popup menu.
• Edit Alarm Class
You can change the alarm class assignment of the alarm extensions. Select single or multiple
(for batch editing) and from the popup menu select the Edit Alarm Class menu item.
Choose the desired alarm class from the option menu and click the OK button to change the alarm class setting for the selected alarm extension(s).
200
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm service views
About alarm database maintenance
About alarm database maintenance
An example of the Alarm Db Maintenance view is shown in Figure 12 .
Alarms are presented in a tabular view with columns that can be added or deleted using the menu in the top right corner of the column title bar.
Figure 12 Alarm Db maintenance view
For more details about alarm service, refer to “About the alarm service” on page 196). The view has
the following displays and features.
• Toolbar icon
the filter icon and the notes icon appear on the toolbar when the alarm database maintenance view is displayed. See
for a illustration of the alarms filter dialog box.
• Time range options
this menu is located in the top left corner of the alarm database maintenance view. You can select one of the pre-defined times or select the Time Range option that allows you to set a specific time range using the Edit Time Range dialog box.
• Title bar
appears in the top left corner of the view and displays the alarm class summary view title.
• Alarms total
appears in the top right corner of the view and displays the number of alarms that are in the view.
• Table options menu
Use the table options menu in the top right corner of the view to change which columns are displayed or to export the data in the view, as desired. The table options menu includes the following items:
•
Reset column widths
sets all columns in the table to the default widths.
•
Export
opens the Export dialog box for exporting table records to PDF, text, or CSV formats.
•
Timestamp
displays the time of the alarm
•
UUID
displays the unique universal identifier (UUID) of the alarm record.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
201
Types of alarm service views
Chapter 7 — About alarms
About alarm database maintenance
•
Source State
displays the status of the listed alarm source; for example, “High Limit” or “Normal”.
•
Ack State
displays either “Acked” or “Unacked” to indicate whether the alarm has been acknowledged or not.
•
Ack Required
displays either “True” or “False” to indicate whether or not an acknowledgement is required for this alarm.
•
Source
displays the alarm source name.
•
Alarm Class
identifies the name of the alarm class that the extension is assigned to (defaultAlarmClass or other class).
•
Priority
displays the priority number of the alarm.
•
Normal Time
displays the time that the alarm went to normal (if applicable)
•
Ack Time
displays the time that the alarm was acknowledged (if applicable)
•
User
identifies the name of the user associated with this alarm (if known).
•
Alarm Data
presents a detailed list of alarm data.
•
Alarm Transition
displays the last transition type of the alarm.
•
Last Update
displays the time of the last alarm update.
• Color coding
a red alarm icon in the table indicates that the current alarm state of the parent component is not normal and is not acknowledged.
a green alarm icon in the table indicates that the current alarm state of the parent component is normal and is not acknowledged.
an orange alarm icon in the table indicates that the current alarm state of the parent component is not normal but is acknowledged.
• Hyperlinking
double-click on any row in the table and the Alarm Details dialog box appears, as shown in Figure
.
202
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm service views
Figure 13 Alarm details
About the alarm class summary view
• Alarm database maintenance
The database maintenance view allows you to perform the following database maintenance actions on the alarms, using the controls located at the bottom of the view:
• Clear Old Records allows you to clear alarm records before a certain date and time. The Before field is provided to allow you to set the date and time for removing old records.
• Clear All Before Selected Record allows you to delete all records that have a timestamp earlier than the timestamp of the record that is currently highlighted in the table.
• Clear All Records allows you to delete all records, regardless of the date.
About the alarm class summary view
The alarm class summary view provides a tabular presentation of data associated with all alarm classes that are assigned to the alarm service. An example of the alarm class summary view is shown
Figure 14 Alarm class summary view
The view has the following displays and features:
• Toolbar icon
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
203
About alarm class
Chapter 7 — About alarms
About the alarm class summary view the export toolbar icon is available on the toolbar when the alarm extension manager view is displayed.
• Title bar
appears in the top left corner of the view and displays the alarm class summary view title.
• Alarm class total
appears in the top right corner of the view and displays the number of alarm classes that are associated with the alarm service.
• Table options menu
Use the table options menu in the top right corner of the view to change which columns are displayed or to export the data in the view, as desired. The table options menu includes the following items:
•
Reset column widths
sets all columns in the table to the default widths.
•
Export
opens the Export dialog box for exporting table records to PDF, text, or CSV formats.
•
Name
displays the alarm class name.
•
Open
displays the total number of open alarms associated with the alarm class.
•
In Alarm
displays the total number of alarms (points currently in alarm) associated with the alarm class.
•
UnAcked
displays the total number of unacknowledged alarms associated with the alarm class.
•
Last Alarm
displays the timestamp of the last alarm associated with the alarm class.
•
alarm.Class.priority
lists the priority of each alarm transition type. For example, “toOffnormal=1”, “toFault=60”,
“toNormal=220”, and so on.
•
To Path String
identifies (as a string value) the path to the alarm class.
• Hyperlinking
double-click on any row in the view and the view will change to the property sheet view of the alarm class that you clicked on. You can also use the popup menu to select a view.
About alarm class
The alarm class is maintained by the alarm extension and all alarm classes available to the system are maintained as slots on the alarm service. The alarm class routes alarms with some similar set of properties along common routes and they serve as channels for like data. Alarm class manages the persistence of the alarms as needed via the alarm archive, but otherwise merely chains alarms from the
204
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
About alarm class About alarm class properties alarm source via a topic. The alarm class also manages which alarms require acknowledgement and is the basis for visual grouping in the alarm console.
Figure 15 Alarm class in nav side bar
You can set up multiple alarm classes in order to have a variety of alarming and routing options available for selection from the alarm extension properties. For example, you may set up an alarm class that routes to the console recipient and station recipient, while you may use another alarm class that
routes alarms only to an email recipient, as shown in Figure 16 .
Figure 16 Alarm classes and linked alarm recipients
For more information about alarm recipients, refer to “Types of alarm recipients” on page 208. For
information about configuring alarm classes, refer to
“About alarm class properties” on page 205.
About alarm class properties
Figure 17 Alarm class properties
The alarm class property sheet is shown in
and described in the following list:
Note: Remember that these alarm class properties are specific to their parent alarm class and therefore, the properties do not contain values that are assigned to other alarm classes.
• Ack Required
any alarm assigned to this alarm class is required to have the selected alarm transitions acknowledged when the associated option is selected (toOffnormal, toFault, toNormal, toAlert). If no option is selected, then no ack is required.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
205
About alarm class
Chapter 7 — About alarms
About alarm class mapping
• Priority
these fields allow for custom entry of priority levels for each alarm transition type. The priority levels are associated with the alarms and are indicated graphically by colors that you can set in the
alarm options dialog box. Refer to “Alarm console options” on page 46 for details about setting
priority colors.
• Total Alarm Count
displays the total number of alarms that have been assigned to the alarm class from all sources.
• Open Alarm Count
displays the current total number of open alarms.
Note: An alarm is considered “open” if it is not acknowledged and in normal status (or acknowledged and in alert status).
• In Alarm Count
displays the total number of alarm conditions.
• Unacked Alarm Count
displays the total number of unacknowledged alarms.
• Time of Last Alarm
displays the time that the last alarm (assigned to this alarm class) was generated.
About alarm class mapping
Alarm class mapping is available using the alarm class mapper dialog box. This dialog box, shown in
, provides a way for you to assign one or more alarm classes to a common set of alarm-handling parameters. One benefit of this type of mapping is that you can import alarms from a variety of alarm classes and have them display, link, or sound in a common manner. You do this by creating a alarm class definitions and then “mapping” existing alarm classes to these definitions.
Open the alarm class mapper dialog box by choosing Alarm Class Mapping... from the Alarm menu. You can also open this dialog box in the Alarm Console window inside the
Workbench Options dialog box.
206
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
About alarm class
Figure 18 Alarm class mapper
About alarm class mapping
Note: The Alarm menu is available when you are in the alarm console view.
The alarm class mapper dialog box has two primary windows, as shown in
and described below:
• Alarm Class Definitions window
This window is located at the top of the alarm class mapper dialog box. You can create, delete, or edit alarm mapper definitions in this window and then assign any existing alarm classes to these definitions, as shown in
. Click on the Edit button to display the Edit dialog
box (shown in Figure 19 ) where you can configure the mapper alarm definition.
Figure 19 Editing a mapper alarm class
Note: The icons, hyperlinks, and sounds in the alarm mapper definition do not override those that are assigned in the alarm extension itself. If these parameters are assigned in both the alarm extension and in the alarm class mapper definition, the alarm class mapper definition parameters are ignored.
• Alarm Class Definitions Mapping window
This window is located at the bottom of the alarm class mapper dialog box. You can map any existing alarm classes to alarm mapper definitions. To do this, click the Add Mapping but-
ton to display the Map Alarm Class dialog box, as shown in Figure 20 . Choose an available
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
207
Types of alarm recipients
Chapter 7 — About alarms
About the console recipient alarm class in the upper option box and assign it to the mapper alarm class definition in the lower option box. Click the OK button to complete the assignment. The mapping appears in the lower window. Remove mapping assignments by selecting the mapping in the lower window and clicking the Remove Mapping button.
Figure 20 Alarm class definitions mapping
Types of alarm recipients
Alarm recipients are linked to an alarm class (from the alarm topic on the alarm class to the routeAlarm action on AlarmRecipient), as shown in
. Recipients may be configured to receive alarms at certain times of the day, certain days of the week, and to receive alarms of only specified transitions. There are several subclasses of the alarm recipient, as listed below:
• console recipient (refer to
“About the console recipient” on page 208)
• station recipient (refer to
“About the station recipient” on page 211)
• email recipient (refer to
“About the email recipient” on page 212)
• lineprinter recipient (refer to
“About the lineprinter recipient” on page 213)
About the console recipient
The console recipient manages the transfer of alarms between the alarm history and the alarm console. For example, the console recipient gets unacknowledged alarms from the alarm history and updates the history when they are actually acknowledged. Console recipient properties are displayed and edited in the console recipient property sheet, as shown in
.
208
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm recipients
Figure 21 Console recipient properties
About the alarm console
Console recipient properties are described in the following list:
• Time Range
allows you to set a limited period of time during a day for collection of alarms, using the following parameters:
• Start Time a time of day to begin alarm collection, defined by hour, minute and second.
• End Time a time of day to end alarm collection, defined by hour, minute and second.
• Days Of Week
option boxes allow selection of specific days to collect alarms.
• Transitions
option boxes allow selection of specific alarm transitions to display in the console. Only those transitions that are selected will be displayed in the console – even though the alarms are still saved into the alarm history.
The default view of the console recipient is the alarm console view (for details about the console
view, see About the alarm console ).
About the alarm console
The alarm console is a view of the console recipient. It allows you to see all the alarms that have been routed to the alarm console. Alarms are presented in a tabular view with columns that can be added or deleted using the drop–down menu in the top right corner of the column title bar.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
209
Types of alarm recipients
Figure 22 Alarm console
Chapter 7 — About alarms
About the alarm console
The alarm console manages alarms on a per–point basis. Each row in the alarm console is the most recent alarm from a point. To view all the current alarms or to get more details about a particular alarm from that point, use the following alarm details views:
• open alarm sources dialog box
Figure 23 Open alarm sources dialog box
To view all the current alarms from a particular point, double click the row. The alarm details dia-
log box appears, as shown in Figure 23 . To acknowledge an alarm, select the desired alarm and
click the Acknowledge button. An alarm is cleared from the alarm console when both of the following conditions exist:
• alarm is acknowledged
• the point is in a “normal” state
• alarm record dialog box
This window shows (see
) additional detailed information about a specific point alarm.
It also allows you to:
• acknowledge an alarm using the Acknowledge button.
• jump directly to a point using the Hyperlink button.
• add notes to the alarm record using the notes dialog box (use the Notes button).
210
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm recipients
Figure 24 Alarm record dialog box
About the station recipient
• alarm filter dialog box
This window displays parameters, as shown in
, that you can use to include or exclude alarms from the alarm console.
Figure 25 Alarm filter dialog box
About the station recipient
The station recipient manages the transfer of alarms between the alarm service and a remote station.
For example, a station may send alarm notifications to a “supervisor” station – or any other remote station that is defined under the NiagaraNetwork. The station recipient component provides a place to specify the location and other details about that remote station. Station recipient properties are shown
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
211
Types of alarm recipients
Chapter 7 — About alarms
About the email recipient
well as alarm collection parameters.
Figure 26 Station recipient property sheet
Station recipient properties are described in the following list:
• Time Range
allows you to set a limited period of time during a day for collection of alarms, using the following parameters:
• Start Time a time of day to begin alarm collection, defined by hour, minute and second.
• End Time a time of day to end alarm collection, defined by hour, minute and second.
• Days Of Week
option boxes allow selection of specific days to collect alarms.
• Transitions
option boxes allow selection of specific alarm transitions to display. Only those transitions that are selected will be displayed – even though the alarms are still saved into the alarm history.
• Route Acks
when this parameter is set to true, Acks are routed to this recipient; when set to false, Acks are not routed to the recipient.
• Remote Station
option selection displays eligible remote stations. Stations appear in the option list if there is a valid network connection to the station. Alarms that are sent to a remote station are routed according to the parameters defined in the Alarm class that is selected in the Alarm component under the remote station’s NiagaraNetwork. Refer to
“Station Alarms notes” on page 162 for more informa-
tion about remote station alarm routing.
About the email recipient
The email recipient is like other alarm recipients except that the alarm may be formatted into an email message and delivered to another destination. An example of the email message format is shown in
.
212
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm recipients
Figure 27 Email alarm message
About the lineprinter recipient
sage fields as well as alarm collection parameters.
Figure 28 Email recipient property sheet
About the lineprinter recipient
The LinePrinterRecipient allows you to print alarms to line printers that are attached to a station that is running on a Win32 platform. This recipient can print to local and remote line printers. Alerts may be generated if the printing of an alarm fails, but the lineprinter recipient does not print alarms that it generates itself. An example of the lineprinter recipient property sheet is shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
213
Types of alarm recipients
Figure 29 Lineprinter recipient properties
Chapter 7 — About alarms
About the lineprinter recipient
Lineprinter recipient properties are described in the following list:
• Time Range
allows you to set a limited period of time during a day for collection of alarms, using the following parameters:
• Start Time a time of day to begin alarm collection, defined by hour, minute and second.
• End Time a time of day to end alarm collection, defined by hour, minute and second.
• Days Of Week
option boxes allow selection of specific days to collect alarms.
• Transitions
option boxes allow selection of specific alarm transitions to display in the console. Only those transitions that are selected will be displayed in the console – even though the alarms are still saved into the alarm history.
• Route Acks
when this parameter is set to true, Acks are routed to this recipient; when set to false, only alarms (not Acks) are routed to the recipient.
• Printer
this option list displays printers that are available for selection. Select a valid lineprinter from the list or type in the name of the desired printer.
• Language
this field provides a place to enter the ISO 639 language code for the language associated with the line printer. This is a two letter code (lower-case preferred). Refer to the following link for the complete list of codes: http://www.loc.gov/standards/iso639-2/langcodes.html.
• Print Format
This field has the following editable default parameters.
• Source: %alarmData.sourceName% this parameter sends the source name of the alarm to print on the first line.
• Timestamp: %timestamp% this parameter sends the timestamp of the alarm to print on the second line
214
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 7 — About alarms
Types of alarm recipients About the lineprinter recipient
• State: %sourceState% / %ackState% this parameter sends the alarm state and the acknowledged state to print on the third line
• Priority: %priority% this parameter sends the alarm priority to print on the fourth line
• Alarm Class: %alarmClass%
• Text: %alarmData.msgText%
Note: For more information about how to format data in this field, click on the help icon to the right of the field.
• Alert on Failure
when this parameter is set to true, an alert is generated if the printer fails to print the alarm.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
215
Types of alarm recipients
Chapter 7 — About alarms
About the lineprinter recipient
216
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
About Presentation XML (Px)
This section describes the presentation tools that are available in Niagara AX Workbench. Basic presentation concepts and AX presentation architecture principles are described in
“About presentation” on page 16.
If you plan to visually display the control logic that you develop in Workbench (for operations or for engineering purposes) then you need to understand the basic principles of Px and understand the capabilities and limitations of your different target media. Obviously, graphics and text look different and have greater limitations on a cell phone display, when compared with a computer-based web browser. It is important to develop Px files with the target media types in mind and to test your Px views in the target media types as you develop them.
Usually, it is easier to complete the engineering of your control logic using the wire sheet and other views before beginning to design the presentation of that logic. There are features and tools in the Px
Editor, such as the Make Widget wizard, that allow you to drag and drop components from the nav tree onto various panes in the Px Editor. If you have already built the logic, it should visible in the tree and available for drag and drop.
The general process of creating presentations for control logic can follow many different paths. The three major steps, shown in
, are provided as an example to help illustrate the process.
Figure 1 Simplified presentation process
• Create view
When you create a view, you are creating a relationship between a Px file and a component. The
Px file defines the view and that view may be associated with one or more components of various types, such as folders and points.
Refer to the following sections for information related to Px views:
•
•
•
• Bind data
After creating a view with a Px file, you add graphic visualizations (called widgets) to the file and pass data to these widgets using data binding. The bound data from the control objects animates and updates the widgets.
Refer to the following sections for information related to widgets and data binding:
•
•
•
“Animating Graphics” on page 230
•
“About Px target media” on page 238
•
“About Web Profiles” on page 239
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
217
Chapter 8 — About Presentation XML (Px)
About Px views
•
“About the Make Widget wizard” on page 242
•
“Make Widget wizard: examples” on page 244
• Create a Nav file
In order to easily find and navigate between views, a special file type (“.nav” file) is available for creating a customizable navigation tree. Edit the Nav File using the Nav File Editor and assign a particular Nav File to a user in the user’s profile (using the User Manager view).
Refer to the following sections for information related to the Nav file:
•
“About the Nav file” on page 264
•
“About the Nav File Editor” on page 266
About Px views
A Px view is a custom graphical view that you define in a Px file. The purpose of a Px view is to provide a visualization of information in a rich, dynamic format that is easy to create and to edit. By using the Px Editor to build Px files, you can create the desired visualization of your control logic without having software “programming” skills. When attached to a component, the Px view becomes the default view for the component.
Looking at an object’s Px view in the property sheet (where it may be edited) helps illustrate what a
Px view is. A Px view is comprised of the following parts, as shown in Figure 2 :
• Icon
Assign or change the icon file that appears to the left of the Px view display name. After assigning this icon to the view, it appears in the view selector menu, the nav tree side bar, and in the property sheet view.
Note: Icon graphics must be linked into your view from a module (for example, use the following path to find a “folder” icon: “module://icons/x16/folder.png”). Icon graphics are not supported outside of modules.
• Px File
Assign the Px file that is associated with active Px view. See “About Px files” on page 220 for
more about Px file.
• Required Permissions
Assign or edit the Operator and Admin permissions that are applicable when the view is active:
Read (r), Write (w), Invoke (I).
• Media
Edit the target media of the Px view: workbench or html. See
“About Px target media” on page 238 for details about target media types.
218
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 2 Px view in a component property sheet
About Px views
Px views as slot properties
The Px view is attached to a component as a dynamic slot property of the type “baja:PxView.” One way to create a new Px view is to add it directly to a slot sheet (refer to
“To add a new slot” on page 354, for details about adding new slots).
shows three Px views in a single component slot sheet.
Figure 3 Three Px views as slot properties
The Px view highest on the slot sheet is the default view. You can reorder Px views to change the default Px view of a component. For an active component, all Px views (if any) appear in the view selector, as shown in
.
Figure 4 Three Px views in the view selector
About the New Px View wizard
You can create and delete Px views using the Slot Sheet view, as described in
New Px View
wizard. Start the New Px View wizard by selecting New View from the popup menu or from the View Selector menu.
icon, and target media properties, as described in “About Px views” on page 218. The wizard creates
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
219
Chapter 8 — About Presentation XML (Px)
About Px files a new Px file and assigns it a default name unless you specify a name. You may choose to assign an existing Px file to the view instead of creating a new one.
Figure 5
New Px View
wizard
After completing the fields in the New Px View wizard, click the OK button to finish. The new Px view is displayed in the Px Editor. If you choose to have the wizard create a new Px file, it will be a
simple default file, as shown in Figure 6 on page 220.
About Px files
The Px file defines the content and presentation of a Px view. The Px file is a special XML file that describes the components in a database and can be any collection of components, up to a complete database. All views (wire sheet view, property sheet view, category sheet view, and so on) can be used on components in a Px file. This means that a Px view can be used to provide a complete variety of options in the development of dynamic user interfaces.
simply contains an empty canvas pane nested in a scroll pane.
Figure 6 Basic default Px file in Text Editor View
As you add more objects to the file, (typically using the Px Editor) the file looks more like the snippet shown in
. The graphic components, value bindings, and their container elements and attributes are all referenced in the Px file.
220
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 7 Px file in Text Editor View and in Px Editor View
About Px files
The elements in the Px file are also graphically represented in the Widget Tree side bar pane.
• For information about the Px Editor, refer to
“About Px Editor” on page 223.
•
• For more information about the Text Editor, refer to
“workbench-TextFileEditor” on page 455.
Shared Px files
A single Px file may be used as part of one or more Px views. Since the bindings within a px file are always resolved relative to the current ORD, you can reuse the same Px file across multiple components by specifying bindings with relative ORDs. This allows you to create a single presentation and use it in views that are assigned to components that can use identical graphic layout. The obvious advantage of this file sharing is that you only need to create and edit one Px file for many views, thus saving time and ensuring consistency among similar applications. However, it requires that you understand the following caution:
Caution: Editing a Px file affects all views that use that particular Px file:
• Any time that you view a component in the Px Editor you have its Px file open for editing.
• If the Px file is shared with other Px views, then all of those Px Views are changed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
221
Chapter 8 — About Presentation XML (Px)
About Px viewer
About Px viewer
The Px viewer presents Px in a non-editable display. The Px viewer allows the user (with required permissions) to view information and invoke actions on controls in the display. Any time you select a
Px view from the right-click menu or from the View Selector menu, the Px viewer displays the active
component’s view, as shown in Figure 8 . Use the Px editor to edit the Px file (as described in
Figure 8 Px Viewer
222
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
About Px Editor
About Px Editor
When you select the Px Editor view of a component, or of a Px file, the Px Editor displays the Px file
in the Workbench view pane. Figure 9 shows a Px View of a component with several items selected.
Figure 9 Px Editor
The default view of the Px Editor comprises three main areas:
• Canvas
The largest area of the Px Editor (by default) is the canvas pane. Typically, you place widgets on the canvas and edit them using one or more of the three side bars and additional dialog boxes.
Refer to
“About Widgets” on page 225 for more information about widgets.
• Side bar pane
The Px Editor side bar pane appears on the far right side of the view pane only when the Px Editor
is active. Refer to “About the side bar panes”
for more information about side bar panes. Use the
Px Editor toolbar menu to hide or display individual side bars or to show or hide the Px Editor side bar pane. Refer to
“Types of side bars” on page 28 for more information about individual side
bars.
• Px Editor toolbar
The Px Editor toolbar displays above the view pane when the Px Editor is active. Refer to
Editor toolbar icons” on page 475 for more information about individual Px Editor toolbar icons.
About the Px Editor Canvas
of the graphic page that you produce in the Px Editor. The Canvas is also your work area for previewing the Px file as you develop it using the tools in the Px Editor. The Canvas provides a view of the
widgets (see “About Widgets” on page 225) as you add them and bind data to them. Most of the time,
the Canvas provides a live view of any widgets that are added–without having to return to the Px
Viewer. However, some graphic features may only appear in the Px Viewer. See
“About Px viewer” on page 222 for more information about the Px Viewer.
The Canvas has the following optional work aids:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
223
Chapter 8 — About Presentation XML (Px)
View Source XML dialog box
• Grid
This is a visual aid for graphical alignment. The grid lines display vertical and horizontal lines as well as define the visible area of the page. Toggle the grid on or off using the Px Editor menu.
• Show Hatch
Hatching is an area of light-gray diagonal lines that define the boundaries of items that are placed on the Px Editor Canvas. Toggle the hatching on or off using the Px Editor menu.
• Snap
This feature is an aid to precise placement when you are using the mouse to drag an object to a particular location. Snap pulls the item to the nearest grid line or nearest object for a matching vertical or horizontal alignment. Toggle Snap on or off using the Px Editor menu.
Figure 10 Px Editor Canvas
View Source XML dialog box
The View Source XML dialog box allows you to view the source XML of a Px file in a separate readonly window. Although you cannot edit the Px file in this dialog box, you can copy and paste text from the window into the Text File Editor–or any other text editor, such as Notepad.
The View Source dialog box, shown in
Figure 11 , is a simple window with an OK button that closes
the window when you click it.
224
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 11 View Source XML dialog box
About Widgets
About Widgets
Widgets are components that provide visualization. You can use the Px Editor to work with widget properties in defining user interface functions for control and information display. User widgets can process input in the form of mouse, keyboard, and focus events. User events are grouped into these same event categories. The bajaui module, the kitPx module, and the kitPxHvac module all contain widgets that you can use for building rich user interfaces. You can find these widgets by opening
them under the palette side bar, shown in Figure 12
, or you can find them using the Make Widget wizard.
• refer to
“Using the palette side bar” on page 345
for instructions about using the palette side bar.
• refer to
“About the Make Widget wizard” on page 242 for details about the Make Widget wizard.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
225
About Widgets
Figure 12 Widgets in the bajaui palette
Chapter 8 — About Presentation XML (Px)
The widget tree side bar provides a good illustration of the hierarchy structure of all widgets in a Px
Some complicated widgets have mini-frameworks all to their own, such as the table widget, tree widget, treeTable widget, and textEditor widget. Refer to the “Baja Widget Toolkit” in the NiagaraAX
Developer Guide for more details about these types of widgets and for developer-level information about widgets.
The following sections discuss some of the primary characteristics of widgets, including:
•
•
•
•
•
Widget layout
A tree-type hierarchy of Px elements defines widget relationships and physical layout, in a structure where parent-child relationships exist between components. All widgets occupy a rectangular area that is defined by a position and a size. The position of a widget is defined by its x, y coordinates relative to its parent’s coordinate system and each widget may have a default (or preferred) size. The
widget (C), held by a parent widget (B), that is the child object of a widget (A).
Note: If either of the child objects are positioned outside of the view area of the parent, they will be clipped and not be totally visible.
226
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 13 Scroll pane (A) holds canvas pane (B) with widget (C)
About Widgets
Some widgets are designed specifically to be container widgets that hold other widgets. These wid-
gets are called panes. Figure 14 shows the pane hierarchy in the widget tree and on the Px editor
canas. Refer to
“Types of panes” for a list of commonly used panes.
Figure 14 Pane hierarchy in the widget tree
Types of panes
Widgets that are designed to be containers for child widgets are called panes. Different types of panes provide different functions. The following list is a summary of commonly used panes:
• CanvasPane
used for absolute positioning.
• BorderPane
used to wrap one widget and provide margin, border, and padding similar to the CSS box model.
• EdgePane
supports five potential children: top, bottom, left, right, and center. The top and bottom widgets fill the pane horizontally and use their preferred height. The left and right widgets use their preferred width, and occupy the vertical space between the top and bottom. The center widget gets all
the remaining space. See Figure 15 for an example.
• GridPane
lays out its children as a series of columns and rows. Extra space in the rows and columns is configurable a number of ways using the pane’s properties.
• SplitPane
supports two children with a movable divider between them.
• TabbedPane
supports multiple children - only one is currently selected using a set of tabs.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
227
Chapter 8 — About Presentation XML (Px)
About Widgets
Note: Even though only one tab is visible at a time, all tabs must be loaded on the page, even if they are not visible. If many tabs, with a lot of information, are on a single page, the page may load very slowly.
• ScrollPane
supports a single child that may have a preferred size larger than the available bounds. The scroll pane provides a set of scroll bars for viewing areas of the child widget that go outside of its bounds.
illustrates the edge pane layout using borders and labels.
Figure 15 Edge panes, borders, and labels on a canvas pane
Widget painting
Painting defines how widgets present themselves graphically (using: colors, transparencies, and so on), as well as clipping. Graphics are always translated so that the origin 0,0 is positioned at the top, left corner of the widget. The graphic's clip (visible area) is set to the widget's size. Alpha and transparent pixels blend with the pixels already drawn. Widgets are drawn in property order, the first widget is drawn first (at the bottom), and the last widget drawn last (on the top). Effective z-order is reverse of property order.
Commands
Widgets can have user commands that are commonly used with buttons and menu actions. Toggle commands are commonly used with a checkbox, radio button, and other items. Menu commands are
available and used on fans, coils, and other widgets, as shown in Figure 16 .
228
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 16 Widget commands
About Widgets
For more information about commands, refer to the “Baja Widget Toolkit” in the NiagaraAX Developer Guide.
About widget properties
Widget properties define many of the features, behaviors and appearance characteristics of widgets.
By editing widget properties, you set or change the widget attributes. In the Px Editor, you can edit widget properties using the properties side bar or properties dialog box and their secondary dialog boxes. Many of the properties (those that appear with the ellipsis icon) have these secondary dialog boxes that display when you click a property field. The secondary dialog box provides more detailed property fields and options.
bound label is “bound” to the “slot:temp” value, as shown in the text property field. The binding of this value allows the dynamic presentation of the temperature information in the Px view.
Figure 17 Widget properties
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
229
Chapter 8 — About Presentation XML (Px)
Animating Graphics
Animating Graphics
Animated graphics are graphics that change, or “update”, based on data values that come from object sources that are connected (or “bound”) to them. A “graphic” can be as simple as a single word of text
(“ON”) or a number (“72”), or it can be an animated image (rotating fan). Widgets provide the graphic visualization of data in Workbench, so animated graphics are comprised of one or more widgets assembled in a Px file, available for display using the Workbench display media types. Widgets are animated by binding any widget properties to a legitimate data source. This means that you can connect numeric values to widget properties that use numeric values and you can connect binary values to objects that can use binary values. By animating the properties of a widget, you can control text and image appearance as well as a change a widget’s location on the page and even its visibility.
The following sections describe the different concepts that relate to animating graphics:
•
•
•
•
Relative and absolute bindings
Data binding
All widgets may be bound to data sources using data binding. Bindings are established between a widget and an object using an ORD. A single binding consists of a single widget–object relationship.
A binding’s ORD property identifies the location of the object that updates and animates the widget.
For example, the most common type of binding, the value binding, provides some of the typical functions that are associated with building real-time information for presentation as both text and graphics. This includes support for mouse-over status and right-click actions. Additionally it provides a mechanism to animate any property of its parent widget using converters that convert the target object
into property values. Figure 18 shows a value binding to a fan widget as viewed in the Edit Bind-
ing
dialog box.
Figure 18 Widget data binding
illustrates the object-to-widget property binding concept. In this example, a widget has three separate data bindings. This means that each binding is coming from a different object and therefore each binding has a different ORD that defines its binding. Each binding provides access to an object’s values so that they may be used, as required, to animate the widget properties.
230
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 19 Widget with three bindings
Animating Graphics
Types of bindings
There are different types of bindings that may be used with widgets. Some bindings work with only a certain type of widget (for example, a bound label binding) and other binding types may be used with several types of widgets (for example, a value binding).
shows bindings as they appear in a
Workbench options list.
Figure 20 Types of bindings
Following, is a list and short description of each binding type.
• Action binding
invokes an action on the binding target component when an event is fired by the parent widget.
See “About action bindings” on page 236 for details.
• Bound Label binding
connects a value to a bound label widget. See
“About bound label bindings” on page 233 for
details.
• Field Editor binding
used to bind field editor components to an object. See “About field editor bindings” on page 237
for details.
• Setpoint binding
used to display the current value of a "setpoint" and also to provide the ability to modify it. See
“About spectrum setpoint bindings” on page 236 for details.
• Spectrum binding
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
231
Chapter 8 — About Presentation XML (Px)
Animating Graphics
used to animate a widget's brush (color) property. See “About spectrum bindings” on page 234 for
details.
• Spectrum setpoint binding
• Table binding
used to bind table data in a bound table. See “About table bindings” on page 237 for details.
• Value binding
Types of binding properties
One or more of the following properties are included with all binding types.
• ORD
this property specifies the ORD that is bound to the widget. This field must have a value if you want the widget to be bound.
• Hyperlink
this property provides a link to another object. When the field is completed, the hyperlink is active in the browser or in the Px viewer.
• Increment
this property is a value that can be set to increment (increase) or decrement (decrease) a current value by the assigned amount. A positive number in this property field increments a value; a negative number in this field decrements a value.
• Summary
this property allows you to specify a display name for the widget in text or by means of a script.
• Popup Enable
this property has “true” or “false” options and allows you to specify if you want to allow a secondary window or dialog box to appear when a user clicks on this label from a browser or Px viewer.
• Status Effect
this property provides the following three options for enabeling or disabeling status effects:
• Color choose this option to enable a background color change when the bound value status changes.
• Color and blink choose this option to enable a background color change and a blinking effect when the bound value status changes.
• None choose this option to disable any effects based on bound value status changes.
• Widget Property
this property allows you to specify the property that you are targeting in the binding’s parent widget. For example, you can use a spectrum binding that has a bound label parent to change the background property of that parent label by selecting “background” in the Widget Property options field. Or, you can change the foreground color by choosing “foreground”. You can target
232
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Animating Graphics only one value per binding but you may add additional bindings if you want to target more that one property in the parent widget.
• Low Color
this spectrum binding property specifies the color that is used for the lowest value assignment for a spectrum color binding. The low color displays when the bound target value is less than setpoint-extent/2. As the value bound to this property increases above the minimum value specified, the color approaches the color set by the Mid Color property.
• Mid Color
this spectrum binding property specifies the color that is used for the middle value assignment for a spectrum color binding. This color is displayed when the bound value is exactly at the setpoint.
As the binding value increases above this point, the displayed color approaches the color set by the High Color property. As the bound value decreases below this point, the displayed color approaches the color set by the Low Color property.
• High Color
this spectrum binding property specifies the color that is used for the highest value assignment for a spectrum color binding. The high color displays when the bound target is greater than setpoint+extent/2. As the bound value decreases below the maximum value specified, the color approaches the color set by the Mid Color property.
• Set Point
this binding property specifies the value that is used for displaying the Mid Color. For example, if you set this value to “70”, then the color that you define for Mid Color will be displayed when the bound value is “70”.
• Extent
this spectrum binding property represents the total range of the bound value which maps from low to high.
About bound label bindings
Bound label bindings are used exclusively for connecting a value to a bound label widget. Bound labels, which are located in the kitPx module, have properties that you can edit and access from the
Figure 21 Bound label binding properties
Bound label binding properties include the following:
• ORD
• Hyperlink
• Summary
• Popup Enabled
• Status Effect
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
233
Chapter 8 — About Presentation XML (Px)
Animating Graphics
About value bindings
Value bindings are used to bind to values that are typically under a component. Widget properties may be overridden by creating dynamic slots of the same name with a converter that maps the bound target object into a property value. This capability is what allows animation of any widget property.
Value bindings support features such as real-time graphics, mouse-over, and right-click actions.
The properties pane for the bound label binding is shown in Figure 22 .
Figure 22 Value binding properties
Value binding properties include the following:
• ORD
• Hyperlink
• Summary
• Popup Enabled
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
Refer to
“Types of Converters” for for a list of converter types.
Types of Converters
Converters are used to change data from one type to another so that the data can be used to communicate with a particular widget property value. In most cases, when you animate a property, the correct
data converter appears, by default, at the top of the list, as shown in Figure 23 .
Figure 23 Types of converters
The following types of converters are available when using a value binding:
• Fixed Simple
• I Numeric to I Simple
• I Status to Simple
• Object to String
About spectrum bindings
This binding is used to animate a widget's brush (color) property by mapping a numeric value into a color range defined by lowColor, midColor, and highColor properties. The properties pane for the
234
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px) spectrum binding properties is shown in
.
Figure 24 Spectrum binding properties
Animating Graphics
Spectrum properties include the following:
• ORD
• Widget Property
• Low Color
• Mid Color
• High Color
• Set Point
• Extent
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
About setpoint bindings
This binding is used to display the current value of a "setpoint" and also to provide the ability to modify it. A setpoint is typically a status value property such as fallback. The setpoint binding ORD must resolve down to the specific property that is being manupilated. If it is bound to a component or to a read-only property, then the binding attempts to use a "set" action to save.
The properties pane for the spectrum setpoint binding is shown in Figure 25 .
Figure 25 Setpoint binding properties
Setpoint properties include the following:
• ORD
• Hyperlink
• Summary
• Popup Enabled
• Widget Event
• Widget Property
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
235
Chapter 8 — About Presentation XML (Px)
Animating Graphics
About increment setpoint bindings
This type of setpoint binding is used increment or decrement a numeric value. The properties pane for
the increment setpoint binding is shown in Figure 27 .
Figure 26 Increment setpoint binding properties
Spectrum setpoint properties include the following:
• ORD
• Hyperlink
• Summary
• Popup Enabled
• Widget
• Increment
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
About spectrum setpoint bindings
This binding is used in conjunction with a spectrum binding to animate the midColor properties. The properties pane for the spectrum setpoint binding is shown in
.
Figure 27 Spectrum setpoint binding properties
Spectrum setpoint properties include the following:
• ORD
• Hyperlink
• Summary
• Popup Enabled
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
About action bindings
This type of binding invokes an action on the binding target component when an event is fired by the parent widget. The ORD of an action binding must resolve down to a specific action within a component. Examples of actions include: “active”, “inactive”, “override”, and other commands. The proper-
ties pane for the action binding is shown in Figure 28 .
236
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Animating Graphics
Figure 28 Action binding properties
Action binding properties include the following:
• ORD
• Widget Event
• Action Arg
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
About table bindings
This type of binding is used to bind table data in a bound table. Table bindings can bind to any “collection” using a BQL, SQL, or History ORD binding. For example, a table binding ORD might look like the following: station:|slot:/|bql:select toPathString,toString from control:BooleanPoint
The properties pane for the table binding is shown in
.
Figure 29 Table binding properties
Table binding properties include the following:
• ORD
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
About field editor bindings
Field editor bindings are used to bind field editor components to an object. A field editor is a component that is designed to view and edit an object property. Field editors are designed to be laid out on panes and are built with standard widgets like buttons, text fields, check boxes, and so on.
The properties pane for the field editor binding is shown in Figure 30 .
Figure 30 Field editor binding properties
Field editor binding properties include the following:
• ORD
Refer to
“Types of binding properties” on page 232 for a description of the binding properties.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
237
Chapter 8 — About Presentation XML (Px)
About Px target media
Relative and absolute bindings
Since ORDs can be relative or absolute and widgets are bound to data sources using an ORD, data binding can be relative or absolute, as shown in
.
Figure 31 Absolutely bound ORDs and relatively bound ORDs
This is a particularly important point to remember if you want to design Px files that are used in multiple views on a local station or even possibly for use across different stations. When you use the Px
Editor tools to bind data, the ORD is usually supplied in an absolute format, by default. The ORD is relative to the station, such as: station:|slot:/Logic/HousingUnit/AirHandler/
DamperPosition
. This absolute path ensures that the data always resolves to a single unique component (“DamperPosition”) in the location that is specified by the ORD, regardless of where the Px file or the parent component is located. If the same Px file is attached to a view that belongs to a different component, the ORD will still resolve to the original “DamperPosition” component because of the absolute path. However, if you make data binding relative, then the path will resolve relative to its current parent ORD. This relative path makes the Px file resolve data bindings correctly to identically named components that reside in different locations, thus making one Px file usable in many views.
You can open the Relativize ORDs dialog box from the Bound ORDs palette, as shown in
. This Px Editor tool provides a convenient way to change absolute ORDs to relative ORDs.
Figure 32 Relativizing bound ORDs
About Px target media
When you work in the Px Editor you have two client-side target media technologies to consider.
• Web Workbench
This technology allows the standard Workbench software to run inside a web browser using the
Java Plugin. Web Workbench uses a small applet to download modules as needed to the client machine and to host the Workbench shell. These modules are cached locally on the browser's hard drive.
238
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
About Web Profiles
• Hx
In addition to Web Workbench, a suite of technology called Hx is available. The Hx framework is comprised of a set of server side servlets and a client side JavaScript library. Hx allows a real-time user interface to be built without use of the Java Plugin. It requires only web standards: HTML,
CSS, and JavaScript. If you are developing for a target media that is limited to browsers with
HTML and CSS with no applet plugins available, be sure to test your Px views often in the appropriate browser as you proceed in your development. The goal of Hx is to satisfactorily present your Px views in non-applet browsers, however, due to the difference in display technologies, you should verify that the Px view displays in the browser as you expect it to.
Figure 33 Specifying the target media
This allows the Px Editor to advise you if you use any features in your Px file that are not supported by the target media that you have designated.
About Web Profiles
Note: In Workbench, the concept of Profiles pertains to the different ways that Workbench is displayed while using either the Java plugin or using Hx technology. In this context, it does not refer directly to security settings or personal preferences.
Profiles provide NiagaraAX software engineers with the ability to customize both the desktop Workbench and the Web Workbench interface. Using NiagaraAX, the software engineer can create customized Workbench applications that provide different functionality. Refer to NiagaraAX Developer
Guide for more information about custom user interface development.
Custom user interface design, at the browser level, allows for different views that may include or exclude features such as sidebars, navigation trees and other tools that are provided through the interface. Web profiles are used to identify these different web interfaces. You can assign a single Web profile to each user that is listed in the User Manager. Refer to
“UserService” on page 282 for details
about assigning web profiles to users.
The following standard Web profile options are provided:
•
Includes all Workbench functions (refer to “Default Wb Web Profile” on page 240)
•
Reduced feature set in Workbench interface (refer to “Basic Wb Web Profile” on page 240)
•
No Java plugin (refer to “Default Hx Profile” on page 241)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
239
Chapter 8 — About Presentation XML (Px)
About Web Profiles
•
No Java plugin with reduced feature set interface (refer to
“Basic Hx Profile” on page 242)
Default Wb Web Profile
This profile provides all the features of the Web Workbench, using the full Java plugin download.An
example of the Default Wb Web Profile is show in Figure 34 .
Figure 34 Default Wb Web Profile example
Major features of the Default Wb Web Profile include:
• Dropdown menu list
This menu includes the following submenus: File, Edit, Search, Tools, SideBars, PxEditor. These
menus provide commands that are explained in “Types of menu bar items” on page 460.
• Side Bar
You may show or hide this pane. It may include the nav side bar and the palette side bar. The nav side bar displays the navigation hierarchy that is defined by the nav file.
• Locator Bar
This interactive graphic bar appears across the top of the view area and functions as explained in
“About the locator bar” on page 39.
• Real-Time Data
Data is displayed in real-time using the Java plugin.
• View selector
Provides the same view selection options that are available in the desktop Workbench views.
Refer to
“About the view selector” on page 40 for details.
Basic Wb Web Profile
This profile uses a reduced set of features but provides a rich user interface using the Java plugin download. An example of the Basic Wb Web Profile is show in
.
240
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 35 Basic Wb Web Profile example
About Web Profiles
Major features of the Basic Wb Web Profile include:
• Locator Bar
This graphic bar appears across the top of the view area.
• Real-Time Data
Data supplied in real time using the Java plugin.
Default Hx Profile
This profile uses Hx technology (described in “About Px target media” on page 238) and provides a
real-time user interface without the Java plugin download. An example of the Default Hx Web Profile
Figure 36 Default Hx Profile example
Major features of the Default Hx Profile include:
• Locator Bar
This graphic bar appears across the top of the view area and displays links that are defined by the nav file.
• Real-Time Data
Data is displayed in real time using Hx technology instead of the Java plugin.
• View Selector
This dropdown option list provides a set of alternative views for the active object.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
241
Chapter 8 — About Presentation XML (Px)
Px Editor workflow
Basic Hx Profile
This profile uses Hx technology (described in “About Px target media” on page 238). It provides a
reduced set of features but includes real-time user interface without the Java plugin download. An
example of the Basic Hx Profile is shown in Figure 37 .
Figure 37 Basic Hx Profile example
Major features of the Basic Hx Profile include:
• Locator Bar
This graphic navigation bar appears across the top of the view area and displays links that are defined by the nav file.
• Real-Time Data
Data supplied in real time without using Hx technology instead of the Java plugin.
Px Editor workflow
There are various ways to work with the Px Editor. Some work sequences may depend on the type of control logic you are working with and some may depend on your Px target media. The following sections describe workflow patterns that may be used in some situations but may not be optimal–or even possible with others. The Px Editor tools provide many ways to perform a single task. For example, you can edit widget properties in the Properties side bar, or you may double-click on a widget to display a Properties pane in a separate dialog box. Both means of editing the properties have the same effect.
About the Make Widget wizard
The Make Widget wizard is a convenient aid for quickly adding widgets to the Px file. The Make
Widget wizard is available when Px Editor is the active view. The wizard, shown in Figure 38 , auto-
matically displays when you drag a component onto the Px Editor canvas.
Note: The wizard does not display when you drag a widget object from a palette to the canvas.
242
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 38 Make Widget wizard
About the Make Widget wizard
The following list describes the primary areas of the Make Widget wizard:
• Title Bar
This area displays a reminder that you are creating a widget that has a value that is bound to the
ORD of the object that you just dragged into the Px Editor. Double-click on the ORD area to browse for a different component, if desired.
• ORD
This area displays the ORD of the object that you dragged into the Px Editor.
• Source
This area provides context-sensitive options for choosing the type and source of widget that you want to bind to the ORD. Depending on the type of value that you want to link, the wizard displays a variety of options in this area. For example, the Chart widget option would be available for a History Log object but it would appear dimmed (unavailable) if you dragged a Boolean
Point object onto the canvas.
The Widget Source option that you choose will change the display in the Property Options area and the Property Sheet area.
• Secondary view
The secondary view area changes depending on what option is chosen in the Source area:
• Property Options (Bound Label only)
This area appears when you select Bound Label in the Widget Source options. It provides a set of convenience options that allow you to set some of the commonly used label properties, by selecting a check box. You may also use the property sheet area of the wizard or later use the property fields in the property sheet dialog box or property sheet side bar to edit these properties.
• Module browser
This area appears when you select the From Palette option in the Source view and allows you to browse for the desired widget.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
243
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
• Sheet selector
This area appears when you select the Workbench View option in the Source view and allows you to choose the Workbench view that you want to display for the object you just dragged into the Px Editor.
• Property options
This area appears when you select the Properties option in the Source view and allows you to choose options that relate to the properties of the object that you just dragged into the Px Editor.
Note: The Secondary view does not appear when the Actions option is selected in the Source area.
• Property Sheet
This area provides context-dependent options for you to select from (depending on the object that you drop onto the Px Editor).
• Property Sheet
The complete property sheet view displays when you use the Bound Label, From Palette
, or Workbench View option.
• Properties List
A complete list of component properties (for the component you are dropping on the Px Editor canvas) is listed in this area.
• Actions
A list of available actions is displayed here when you select the Actions option.
Make Widget wizard: examples
There are many ways to use the Make Widget wizard. The following procedures provide examples of
one way to use the Make Widget wizard to perform the following tasks:
•
•
Create a widget using a palette kit module
•
Create a widget with a Workbench view
•
Create a widget using a component properties option
•
•
•
Create a bound label widget
To create a bound label widget using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 39 .
244
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 39 Dropping a component on the Px Editor canvas
Make Widget wizard: examples
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double click the ORD to browse for a different component, if desired.
3. Select the Bound Label option in the Source options list as shown in Figure 40
Figure 40 Selecting Make Widget wizard options
The Secondary view area displays a list of property options that are available.
4. In the Secondary view area, select the options that you want and set their properties, as desired, using the adjacent property options lists, as shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
245
Make Widget wizard: examples
Figure 41 Selecting Make Widget secondary view properties
Chapter 8 — About Presentation XML (Px)
Note: The Make Display Label option creates a separate unbound label that appears directly beside the bound label when the widget displays on the canvas. Edit the display label properties using the properties side bar after completing the Make Widget wizard.
5. In the Properties sheet area, shown in
, edit the bound label properties.
Figure 42 Editing Make Widget properties
Note: Some of the options in the Secondary view area are also editable in the Properties sheet area. It is possible to override an option by changing it in the properties sheet area.
6. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
bound label appears on the Px Editor canvas as shown in Figure 43 .
246
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 43 Completed bound label on Px Editor canvas
Make Widget wizard: examples
7. Toggle the view using the View/Edit Mode toolbar icon to display the widget in the Px Viewer, as shown in
.
Figure 44 Completed (commandable) bound label in Px Viewer
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
247
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create a widget using a palette kit module
To create a palette kit-based widget using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 45 .
Figure 45 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the From Palette option in the Source options list as shown in Figure 46
Figure 46 Selecting Make Widget wizard options
The Secondary view area displays the palette side bar view.
4. All palettes that are currently open in the palette side bar are available under the module option selector arrow. Other palettes may be opened by clicking on the folder icon.
In the Secondary view area, expand the module tree to find and select the desired widget
template, as shown in Figure 47 .
248
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 47 Selecting widget template
Make Widget wizard: examples
5. In the Properties sheet area, shown in
, edit the widget template properties, as desired.
Figure 48 Editing widget template properties
6. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new widget appears on the Px Editor canvas as shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
249
Make Widget wizard: examples
Figure 49 Completed widget on Px Editor canvas
Chapter 8 — About Presentation XML (Px)
7. Toggle the view using the View/Edit Mode toolbar icon to display the widget in the Px
Viewer, as shown in
.
Figure 50 Completed (commandable) widget in Px Viewer
250
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create a widget with a Workbench view
You can create a Px view that duplicates the Workbench view of a component. To create a Workbench view-based widget using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 51 .
Figure 51 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the Workbench View option in the Source options list as shown in
Figure 52 Selecting Make Widget wizard options
The Secondary view area displays a list of view options that are available for the selected component.
4. In the Secondary view area, select the desired component view to add, as shown in Figure 53 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
251
Make Widget wizard: examples
Figure 53 Selecting widget Workbench view
Chapter 8 — About Presentation XML (Px)
The Properties sheet area displays the component properties.
5. In the Properties sheet area, shown in
, edit the widget template properties, as desired.
Figure 54 Editing widget template properties
6. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
widget view appears on the Px Editor canvas as shown in Figure 55 . Use the handles on the wid-
get view to expand the view to the desired size or edit the Layout field in the properties side bar.
Scroll bars will appear if the widget view is larger that the canvas view area.
252
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 55 Completed widget on Px Editor canvas
Make Widget wizard: examples
7. Toggle the view using the View/Edit Mode toolbar icon to display the widget in the Px
Viewer, as shown in
.
Figure 56 Completed (commandable) widget in Px Viewer
The view is fully functional in the Px viewer, where you can edit properties, invoke commands, or make other edits to a component, just as if you are editing in the Workbench view.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
253
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create a widget using a component properties option
To create a widget based on a component property using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 57 .
Figure 57 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the Properties option in the Source options list as shown in
Figure 58 Selecting Make Widget wizard properties option
The Secondary view area displays options that are available for creating the new widget.
4. In the Secondary view area, select one or more options from the list, as shown in Figure 59 .
254
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 59 Selecting Make Widget secondary view properties
Make Widget wizard: examples
• Make Display Name Labels
Choosing this option displays a separate unbound label that appears directly beside the bound label when the widget displays on the canvas. Edit the display label properties using the properties side bar after completing the Make Widget wizard
• Make Field Editors
Choosing this option displays an area that allows you to edit the property in the Px viewer (or in a browser).
• Make from palette
This option displays the palette side bar view in the wizard and allows you to find and use a suitable widget template from any available palette.
• Ord and Property Layout options (By Row or By Column)
These options affect how the fields will be arranged on the canvas when you complete the wizard. Your choice of layout is optional and you may rearrange the layout after you place the items on the canvas.
5. In the Properties sheet area, select the properties that you want to bind to the widget. Hold down the Ctrl key to select more than one property, as shown in
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
255
Make Widget wizard: examples
Figure 60 Editing Make Widget properties
Chapter 8 — About Presentation XML (Px)
6. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
property widgets appear on the Px Editor canvas as shown in Figure 61 .
Figure 61 Completed bound label and field editor widgets on Px Editor canvas
7. Toggle the view using the View/Edit Mode toolbar icon to display the widgets in the Px Viewer,
Figure 62 Completed bound label and field editor widgets in Px Viewer
256
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create an action widget
To add an action widget to a Px File using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 63 .
Figure 63 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the Action option in the Source options list as shown in Figure 64 .
Figure 64 Selecting Make Widget wizard action option
The Properties view area displays actions that are available for creating the new widget.
4. In the Secondary view area, select one or more actions from the list, as shown in Figure 65 .
Figure 65 Selecting Make Widget action properties
5. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
property widgets appear on the Px Editor canvas as shown in Figure 61 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
257
Make Widget wizard: examples
Figure 66 Completed action widgets on Px Editor canvas
Chapter 8 — About Presentation XML (Px)
6. Toggle the view using the View/Edit Mode toolbar icon to display the widgets in the Px Viewer,
Figure 67 Using completed action widgets in Px Viewer
258
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create a Time Plot widget
To add a time plot widget to a Px File using the Make Widget wizard, do the following:
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 68 .
Figure 68 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the Time Plot option in the Source options list as shown in
.
Figure 69 Selecting Make Widget wizard Time Plot option
The Secondary view area displays Minimum Value and Maximum Value fields.
4. In the Secondary view area enter the desired minimum and maximum values that you want to
display in the Time Plot widget, as shown in Figure 70 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
259
Make Widget wizard: examples
Figure 70 Entering Minimum and Maximum Time Plot Values
Chapter 8 — About Presentation XML (Px)
5. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
Time Plot widget appears on the Px Editor canvas as shown in Figure 71 .
Figure 71 Completed Time Plot widget on Px Editor canvas
6. Edit the widget, if desired, by doing one or both of the following:
• Resize the widget, as desired to allow the plot to display completely.
• Edit the Time Plot widget properties (header, lines, fonts, and so on) using the Widget Tree and
Properties palettes, as shown in
.
Figure 72 Editing Time Plot widget properties in the Px Editor
260
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
7. Toggle the view using the View/Edit Mode toolbar icon to display the widgets in the Px Viewer,
Figure 73 Completed Time Plot widget in Px Viewer
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
261
Chapter 8 — About Presentation XML (Px)
Make Widget wizard: examples
Create a Chart widget
1. Open the nav side bar and expand the tree to locate the component that you want to add to the Px
Editor canvas.
2. Drag and drop the desired component onto the canvas, as shown in Figure 74 .
Figure 74 Dropping a component on the Px Editor canvas
The Make Widget wizard displays, as shown in
Note: The ORD for the selected component displays in the ORD area. Double-click the ORD to browse for a different component, if desired.
3. Select the Chart option in the Source options list as shown in
Figure 75 Selecting the Make Widget wizard chart option
The Secondary view area displays fields that allow you to choose the data for the x and y axes of the chart and the Time Range.
4. In the Secondary view area enter the value source for column 0 and for column 1. Also, choose the desired range from the time range option list, as shown in
.
262
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 76 Entering chart axes values
Make Widget wizard: examples
5. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new
Chart widget appears on the Px Editor canvas as shown in Figure 77 .
Figure 77 Completed Chart widget on Px Editor canvas
6. Edit the widget, if desired, by doing one or both of the following:
• Resize the widget, as desired to allow the plot to display completely.
• Edit the Chart widget properties (header, lines, fonts, and so on) using the Widget Tree and Properties palettes, as shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
263
About the Nav file
Figure 78 Editing Chart widget properties in Px Editor
Chapter 8 — About Presentation XML (Px)
7. Toggle the view using the View/Edit Mode toolbar icon to display the Chart in the Px Viewer, as shown in
.
Figure 79 Completed Chart widget in Px Viewer
About the Nav file
The Nav file is a special xml file that resides on the file system–not in the station database. You can create as many Nav files as you want, however, a client may display only one Nav file at any time.
This means that any time you are viewing a station you can only see one nav file in the nav tree (or locator bar) but since a station may be serving many clients, each client may be using different nav files concurrently – based on their nav file assignment. The Nav file is user-specific, so when a user logs into a station, the Nav file for that user is displayed in the nav tree or locator bar.
You can match a Nav file to a user by using the Workbench User Manager view. Refer to
“UserService” on page 282 for details about the User Manager.
You can reate new nav files using the right-click menu, as shown in
. Refer to “Creating a new Nav file” on page 363 for details about creating a new nav file.
Add details to your nav file and customize the hierarchy of your nav tree using the Nav File Editor, as described in
“About the Nav File Editor” on page 266.
264
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 80 Creating a new Nav file
About the Nav file
shows three Nav files in the nav folder. Notice that the Nav side bar displays a tree hierarchy of links directly under the station node. Each node of the tree has a context-appropriate icon to help the user recognize the target link of each node in the tree. You can specify icons for the tree
nodes, as described in “About the Nav File Editor” on page 266.
Figure 81 Creating a new Nav file
Nav file elements
When you create a new nav file, in addition to the xml declaration, the file includes two default elements, as listed below and illustrated in
:
• <nav> element
a single opening and closing set of <nav> elements hold all the nodes in the tree
• <node> element
the default <node> element includes an ORD path that points to the station root directory: ord='station:|slot:/'
You can edit these nodes directly in the Text Editor or you can use the tools provided in the Nav File
Editor (refer to “Nav File Editor” on page 267).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
265
Chapter 8 — About Presentation XML (Px)
About the Nav File Editor
Figure 82 Default nav file with home node only
shows what the elements in your nav file look like (when viewed in a text editor) once you add a few nodes to your tree.
Figure 83 Simple nav file with home node only
shows what the elements in a nav file look like in the nav tree and in the Nav File Editor once you add a few nodes to your tree.
Figure 84 Nav file viewed in nav tree and in Nav File Editor (Result Tree)
About the Nav File Editor
The Nav File Editor view provides a simple way for you to view and edit Nav files. When you select the Nav File Editor view of a file, the Nav File Editor displays in the Workbench view pane.
The default view of the Nav File Editor comprises three main areas, as shown in
, and described below:
266
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
Figure 85 Nav File Editor
About the Nav File Editor
• Source objects pane
This resizable pane displays in the top half of the Nav File Editor when you toggle ON the Show
Components
button or the Show Files button on the control pane. The pane disappears when you toggle the buttons OFF. Refer to
“Nav File Editor source objects” on page 267 for
details about source objects.
• Result tree pane
This pane displays whenever the Nav File Editor is open. The pane appears in the bottom half of the Nav File Editor when you toggle ON the Show Components button or the Show Files button on the control pane and fills the view (above the control buttons) when the Show Com-
ponents
• Controls
These buttons are always displayed horizontally across the bottom of the Nav File Editor. Refer to
“Nav File Editor buttons” on page 268 for more information about the functions of each Nav File
Editor control button.
Nav File Editor source objects
Nav File source objects are those objects that may be used for creating you nav file. In order to appear in the source object pane, the “source object” must be a Px file or a component with a Px view assigned to it. The source objects populate the pane view based on the position of the Show Compo-
nents
and Show Files buttons, as described in
“Nav File Editor buttons” on page 268.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
267
About the Nav File Editor
Figure 86 Source objects available in the source pane
Chapter 8 — About Presentation XML (Px)
To use the source objects pane for creating the nav file structure, you drag components or files from the source objects pane down to desired tree location in the result tree pane. Refer to
“Nav File Editor result tree” on page 268 for details about the result tree pane.
Nav File Editor result tree
The result tree pane is where you build the nav file structure. You can drag and drop components and files from the source objects pane to create new nodes in your tree. You can also create nodes directly, using the New button or by using the popup menu directly in the result tree pane. Refer to
Nav file in the Nav File Editor” on page 364 for procedures about editing nav files.
Figure 87 Result tree pane
shows an example of a source object being dragged to a specific location in the nav tree.
The result tree shows the exact hierarchy of your nav tree and allows you to set the indent levels by where you drop the component.
Figure 88 Dragging a source object to the result tree pane
Nav File Editor buttons
The Nav File Editor buttons are aligned horizontally across the bottom of the Nav File Editor. They include controls that you use to create, edit, delete, and rearrange nodes in the nav file. The following list describes each of the of the Nav File editor buttons.
268
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 8 — About Presentation XML (Px)
About the Nav File Editor
• New
This button displays the New Node dialog box that allows you to create a new node in the nav file tree by specifying a name, target ORD and icon for the node. The new node is created as a child node to the active point in the tree (the one you have selected).
• Edit
This button is available when you select a node in the Result Tree pane. It displays the Edit
Node
dialog box that allows you to edit the node name, target ORD, and icon.
• Delete
This button deletes a selected node in the Result Tree pane.
• Move Up
This button allows you to move a selected node (or nodes) up in the nav file tree hieracrchy.
• Move Down
This button allows you to move a selected node (or nodes) down in the nav file tree hieracrchy.
• Show Components
This button toggles on and off. Toggle this button ON to display all eligible components in the
Source Objects pane.
• Show Files
This button toggles on and off. Toggle this button ON to display all eligible Px files in the Source
Objects pane.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
269
About the Nav File Editor
Chapter 8 — About Presentation XML (Px)
270
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview
About Security
This section explains security for any NiagaraAX station. Station security means access by a person using either Workbench or a web browser, or station access by another station. Security determines if a station connection is allowed, what can be accessed, and what operations can be performed. In the case of individual users, it also typically determines navigation options and overall appearance.
A station’s security is based upon users and object categories, with each user’s permissions within any category defined with specific permission levels. All configuration is stored in the station database, using services, components, and component views.
Note: Niagara platform security is a different topic altogether. For more details, see the sections
“About a platform connection” and “Update Authentication” in the Platform Guide.
The following main sections provide more station security details:
•
•
•
Security model overview
A station’s security is determined by the combination of categories
Note: In general, you create needed categories first, then assign objects to them. Then create users, to which you assign permissions. However, you can engineer security in any order you want.
Figure 1 Station security includes categories, users, permissions
The following sections explain the various aspects of station security:
•
•
•
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
271
Security model overview
Chapter 9 — About Security
Categories and security
Categories and security
vides a CategoryManager view for you to add, delete, and edit categories, as shown in
Figure 2 CategoryService and CategoryManager view
is really just an index (Category 1, Category 2, and so on), however, you typically
name them to reflect some logical grouping. For example, you could have “Lighting” and “Floor 3” categories, and assign some objects to both, and others to just one category (or neither of these).
Note: By default, a new station (created using the New Station wizard) has no existing categories.
However, category slots (Category 1—8) exist, with all objects defaulting to slot 1.
As shown in Figure 3 , you typically use the
CategoryBrowser (default view of the CategoryService)
to assign objects in the station to different categories. Every object must be assigned to at least one category.
Figure 3 CategoryBrowser (CategoryService default view)
In the CategoryBrowser, you use an expandable tree to navigate to objects of interest, and click in table cells to add or remove category assignments. As an alternative to explicitly assigning one or more categories to an object, you can have it “inherit” the assigned categories of its parent. This affects appearance in the CategoryBrowser, where:
• Yellow rows are objects explicitly assigned into one or more categories.
• Dimmed rows represent objects inheriting their parent’s category or categories.
Note: You can also review and assign components to categories individually at the component level, using any component’s CategorySheet view. Included is a convenience link back to the CategoryBrowser (CategoryService). See
272
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview Users and security
By themselves, categories have little security meaning. Only when you set a user’s
you reference categories. For more details on categories, see “CategoryService” on page 288 and
“Category caveats” on page 290.
Users and security
Users define possible connections to the station. Under the station’s Service container, a UserService provides a default User Manager view (
) for you to add, delete, and edit users.
Figure 4 UserService and default UserManager view
Typically, each user represents a specific person who uses Workbench or a web browser (or both) to connect to the station. Properties for any user include various settings, including several affecting mostly browser access, including Facets, Nav File, and Web Profile, as shown in
.
Figure 5 User properties
However, a user can be for one or more remote NiagaraAX stations to use (for client connection), in
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
273
Security model overview
Chapter 9 — About Security
Users and security order to share data and import/export histories and schedules. If a “station-type” user, in any remote
NiagaraAX station, you reference this user when adding that NiagaraStation device (under its Fox
Client Connection properties).
Two important security aspects are “built-in users,” and the authentication method used by a station.
•
•
For further details on the UserService, including descriptions of service properties and views, as well as properties of child (user) components, see
About built-in users
Any station has two built-in users that you can neither delete nor rename: admin and guest
.
User admin. User “admin” is unique from all other users in that you cannot disable it, set it to expire, or assign permissions (it is always super user, meaning all permissions). This ensures every station always has at least one super user.
When using the New Station Wizard tool to create a station, the wizard prompts for the password for the admin user. In a typical “sandbox” environment, you could simply leave the password fields blank
(no password). However, never deploy any real station this way—that station would be vulnerable to anyone with only a passing knowledge of NiagaraAX.
In general, it may be best to guard the password for the admin user from almost everyone, as well as use it infrequently. If desired, you can duplicate the admin user, then rename, assign password, reassign permissions, and so forth. If each person has their own (unique) user account, this also makes audit information more valuable. See
“About user audits” on page 278 for more details.
User guest. User “guest,” if enabled, provides station access from a browser with no login required
). Initially, any browser pointed to the host sees “home” in the Nav file assigned to guest. The browser operator can then navigate in the normal fashion, providing that guest has read permissions for objects. Access of an object lacking guest permissions produces the login prompt, whereby the operator must login (as a non-guest user) to proceed.
Note: Password assigned to guest (if any) is ignored when accessing the station via a browser. However, if opening the station in Workbench as user guest, password for guest is checked.
login as “guest” is not available (using either browser or Workbench).
About authentication
For a station connection attempt, the user’s login credentials (user name, password) are checked against those users under the station’s UserService. This process is called authentication. The actual process (and authentication mechanism used) can differ, where the three authentication points are:
• Workbench-to-station (FoxService)
The user is always prompted for user name and password. Fox authentication is used, which is configurable via the FoxService (under the NiagaraNetwork) as either basic or digest. Digest (the
274
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview Permissions and security default) is the preferred mechanism, since the password is never passed in clear text. However, if using LDAP, then basic authentication must be configured.
• HTTP browser-to-station (WebService)
Again, the user is prompted for user name and password. The authentication mechanism used is specified under the station’s WebService, as either cookie (the default), or basic. Cookie is required if you have users configured for browser-based Workbench (e.g., Basic Wb Web Profile), and/or are using the
Domain-wide cookies authentication feature.
Note: If the
guest user is enabled, browser access can occur without login (authentication).
• Station-to-station (FoxService)
A preconfigured user name and password is used (stored under NiagaraStation.clientConnection), which must correspond to an existing user—typically, with super user permissions. Again, Fox authentication is used, the same as with a Workbench to station connection.
In general, it is recommended you leave authentication mechanisms (FoxService and WebService) at default settings, unless the station is configured for LDAP (LdapUserService).
Permissions and security
Permissions define what rights a user has within each of the categories
in the station. There are two
Niagara permission levels: operator and admin. Within both levels, separate options exist for read
access, write access, and invoke (action) access. See “About permission levels” on page 276.
When you add a user, a Permissions field is available for you to set that user’s permissions, using a
Permissions popup dialog (permissions map), as shown in Figure 6 .
Figure 6 Permissions in user’s properties
The built-in admin account has all possible rights for every category (super user). When logged in as the admin user (or another “super user”), you can assign super user rights to any other user, using the
Super User checkbox. Or, you can use the Permissions dialog to include specific rights to only certain categories for that user, such as shown in
To review and compare permissions among all users, the UserService provides a PermissionsBrowser
view, as shown in Figure 7 . Typically, you use this view to adjust permissions for any user.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
275
Security model overview
Figure 7 PermissionsBrowser (UserService view)
Chapter 9 — About Security
About permission levels
In the PermissionsBrowser, columns represent individual users
defined in the station. An expandable tree lets you navigate to objects of interest to review current permissions, shown in table cells using
abbreviations (for read, write, and invoke). Operator level is small case; admin level is UPPER case.
Row coloring in the PermissionsBrowser provides the same data as in the CategoryBrowser, where:
• Yellow rows are objects explicitly assigned into one or more categories.
• Dimmed rows represent objects inheriting their parent’s category or categories.
You can double-click in any column to access that user’s permissions map. See “Permissions-
Browser” on page 286 for more details.
About permission levels
Once a user has been authenticated (see “About authentication” on page 274), that user is granted or
denied permissions for each protected object in the system using the user’s “permissions map” (a cat-
egory-based matrix, for an example see Figure 20 on page 288).
Depending on object type, permission meanings vary as follows:
•
•
•
Component permission levels
Note: By design, the UserService component enjoys a special permission scheme. See
“UserService security notes” on page 278 for details.
Each slot in any component is assigned to one of two permission levels, called operator and admin.
This level is determined by whether the “Operator” config flag is set for that slot.
• If set (checked), the slot can be accessed by a user with a minimum of operator-read
• If cleared (unchecked), a user requires at least admin-Read permissions to access the slot.
With admin-Write permissions, you can see and change slot flags from the slot sheet of any compo-
276
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview
Figure 8 Slot is admin level unless Operator flag is set
About permission levels
Permissions. To control user access from a permission level, six permissions are derived, as follows:
• Operator-read — Allows the user to view operator-level information.
• Operator-write — Allows the user to modify operator-level information (if not read-only).
• Operator-invoke — Allows the user to view and invoke operator-level operations (actions).
• Admin-Read — Allows the user to view admin-level information.
• Admin-Write — Allows the user to modify admin-level information (if not read-only).
• Admin-Invoke — Allows the user to view and invoke admin-level operations (actions).
When you assign a user’s permissions, higher-level permissions automatically “include” lower-level ones. For example, as shown in
if you enable admin-level write (W), admin-level read (R) is automatically enabled, as well as operator-level read and write (r and w).
Figure 9 Lower-level permissions include automatically
Ancestor permissions. Often, you may wish to grant a user permissions to components using categories not included in their parent components, such that permissions to a component’s “ancestor tree” are not explicitly granted. In this case, the system automatically grants “Operator-read” access to all
“ancestor” components in the component tree. Otherwise, a user would be unable to navigate to target components in the Nav tree.
This “automatic ancestor permission” assignment is done by the station periodically, but you can force it at any time with a right-click “Update” action on the
File permissions
given to
categories used by files and folders are “operator-keyed,” as follows:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
277
Security model overview
Chapter 9 — About Security
UserService security notes
• Files
Files require operator-read access to view, and operator-write permissions for editing (if applicable). For instance, a user with operator-write permissions to an .html file can modify it using the
Text File Editor
in Workbench.
• Folders
Folders (directories) require operator-read access to list and to copy child files, and operator-write access to create new (or delete existing) child files.
A few views for files require admin-write permissions to access, such as the Nav File Editor
for a “nav file.” There are also other special case file permissions .
Special case file permissions. These additional rules apply to file system access from station access:
• Files in any NiagaraAX module are automatically granted operator-read.
• If a user is not a “super user,” all access outside of the station’s home directory is denied.
History permissions
Currently, histories require only operator-read permission to access all available views (e.g. History
Chart, Collection Table, History Table). In addition, the ability to rename a history is included.
UserService security notes
In order to facilitate user management, a special permissions
scheme applies to the UserService
(only), whereby permissions are inherited by users as follows:
• If a user has only operator-read permissions, they have read-only access to operator-level properties of their own user account (all other users are hidden).
• If a user has operator-write permissions, they have read/write access to operator-level properties of their own user account (all other users are hidden).
• If a user has admin-Read permissions, they have read-only access to all properties of all users.
• If a user has admin-Write permissions, they have read/write access to all properties of all users.
By default, operator properties of
User are Password and Facets (time format and unit conversion).
If needed, from the slot sheet of
User (s) you can edit config flags to change which slots are operator
versus admin. For example, you might change the email slot to operator.
This scheme is useful when you want to let each user reassign their own password, but not have access to other users. In this case, assign the UserService component to a category where all users are given operator-write permissions (only). Remember, any user granted super user permissions has all
access to all objects.
About user audits
An important aspect of station security is an audit trail to record user activity. Any NiagaraAX station can be configured for user audits through use of the AuditHistoryService. While enabled, this service creates a history of user-initiated changes to components in the station.
278
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview About user audits
Note: If this service is not already in your station’s Services container, open the history palette and drag or copy the AuditHistoryService into your station’s Services folder.
The following sections provide more details:
•
AuditHistoryService configuration
•
AuditHistoryService configuration
AuditHistoryService configuration is simplified by having only the following writable properties:
• Enabled
Either true (default) or false (disabled). Typically, you always leave this enabled.
• Capacity
Either: Record Count nnn records (default is 500) or Unlimited. Typically, unlimited is recommended only for Supervisor stations, while JACE stations are set to some finite count. If a
JACE station, the resulting AuditHistory is typically exported to a Supervisor station for archives.
• Full Policy
Either Roll (default) or Stop. In almost all cases, you leave full policy at roll to ensure latest user actions are recorded.
AuditHistory content
The AuditHistory records user-initiated changes to property values, invoked actions, as well as any slots that are added, deleted, reordered, and renamed. Each record appears as a row that includes the timestamp of the change and the operation, plus other details including the responsible station user.
Using standard history views, you can review and resort data columns in the AuditHistory as needed
view (as shown), you can double-click any row for a popup dialog displaying record details.
Figure 10 AuditHistory in station Histories
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
279
Security model overview
Standard fields in an AuditHistory record include the following:
• Timestamp
Timestamp of when the operation on the slot became effective.
• Operation
Type of user operation, which may include one of the following:
• Added — Added a slot (typically a point or extension)
• Changed — Changed a property (slot) value
• Invoked — Issued a command to an action slot
• Removed — Removed a slot (typically a point or extension)
• Reordered — Reordered one or more slots
• Target
Path to the container of affected slot, relative to the station root.
• Slot Name
Name of the affected slot.
• Old Value
Value of slot before a change.
• Value
Value of slot after the change.
• User Name
User name that initiated the operation.
Chapter 9 — About Security
Multi-station security notes
Multi-station security notes
Some installations have multiple stations. Typically, this means a Supervisor station plus one or more
JACE stations. In this scenario, often the same user(s) need to access different stations. In addition, you typically create a special “station-to-station user” in each station for use in the NiagaraNetwork.
Please note the following:
• By convention, a station-to-station user can be named something memorable (perhaps “m2m”), but you should carefully guard its password—as you typically assign it “super user” permissions.
, properties that apply to browser access are inconsequential, for example,
Facets, Nav File, and Web Profile. You reference this user in another station, when adding a NiagaraStation device under a NiagaraNetwork. See
“Station Add notes” on page 155.
• You can copy users under the UserService in one station into the UserService of another station.
Note that the permission map for each user is included—typically, this is ok if you created the same categories (by index number) in each station, and are using the same basic security scheme.
• If you copy categories from station to station, the index property in each copied category is reset to 0, and the category has a disabled status (until you reassign the index).
• Often, a browser user that has already logged in is re-challenged for login (
This can happen when navigating from one station to another station. If your Niagara hosts are installed on a DNS domain, you can configure stations such that the same browser user is authen-
ticated only once (upon initial station connection). See Domain-wide cookies authentication
.
Domain-wide cookies authentication
This feature is available for multi-station jobs where all Niagara hosts are installed on the same DNS
280
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
Security model overview Multi-station security notes domain. It allows for stations that have the same user accounts (matching user credentials) to be accessed by any such user using a “domain-specified” browser connection and a single, initial, login.
To configure domain-wide cookies authentication
Perform the following in any station that may provide the initial browser connection.
To configure domain-wide cookies authentication, do the following:
1. Open the slot sheet of the WebService component (in the station’s Services container).
2. Add a new slot, naming it “cookieDomain”, leaving other fields at defaults (type baja:String).
See “Using the slot sheet” on page 354 for details on adding a slot.
3. Go to the property sheet of the WebService.
In the new cookieDomain property, enter your DNS domain name (see Figure 11
for example).
4. Verify that the WebService’s property Authentication Scheme is set to Cookie.
5. Save this configuration of the WebService.
Figure 11 Example configured WebService
Now, if a user points his or her browser to this Niagara host using the full DNS name (for example: supervisor.metropolis.net), after station login, they can navigate using links to other stations without need for login. The same credentials used in the initial login are used in other station connections.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
281
UserService
Chapter 9 — About Security
UserService properties
UserService
The UserService is found under a station’s Services container. You use a station’s UserService to add,
edit, and delete users. If you have already configured categories
in the station, you can use it to assign users permissions as well.
Note: For an overview of station security and users, see
“Security model overview” on page 271 and
“Users and security” on page 273.
needed in the service, the following UserService views are your primary access to users:
•
•
UserService properties
Right-click the UserService and choose Views > Property Sheet, as shown in Figure 12 .
Figure 12 UserManager property sheet access
UserService configuration properties are described as follows:
• Require Strong Passwords
Either false (default) or true. If enabled (true), any future user additions (or edits of a user’s password) will require entry of a “strong password,” otherwise an “error” popup dialog results.
A strong password must meet these requirements:
• Minimum of 8 characters
• At least 1 character is a numeral (0—9) or special, such as “!”, “@”, “#”, “$”, or “%”.
• Lock Out Enabled
Either false or true (default). If enabled (true), then a number of consecutive authentication fail-
ures will temporarily “lock out” login access to that user account, for the duration of the lock out period (next property). Using lock out makes it difficult to automate guessing of passwords.
Note: Each user also has a “Clear Lock Out” action. See
• Lock Out Period
Default is 10 seconds, adjustable to any duration in hours, minutes, seconds. If lock out is enabled, then this is the period of time a user account is locked out before being reset. While locked out, any login attempt (even a valid one) will be unsuccessful.
282
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
UserService
UserManager
Double-click the UserService for the UserManager (default view), as shown in
UserManager
Figure 13 UserManager is table based view
Rows in the UserManager table represent existing users, where you can edit by either double-clicking a single user, or clicking to select and then clicking the Edit button.
Note: As in other table-based manager views, you can select multiple rows (users) for edit. This can be useful for a mass change to a property like Facets or Web Profile. However, be careful when doing multiple user edits of things like Permissions and Passwords.
To add a new user, click the New button. This produces the New User dialog, as shown in Figure 14 .
Figure 14 New (user) dialog
You can create multiple users by typing in a number in “Number to Add.” When you click OK, the
Add dialog includes that number of user rows in the top table (
).
Figure 15 Adding multiple users
As needed, click to highlight a single user row before entering unique user properties such as User
Name, Full Name, Permissions, and so on. For properties you wish to enter identically for all users
(for example, Facets), hold down Shift and click to select all user rows, then enter property value.
Note: For a listing of all the User properties, see
When you click OK, the user(s) are added with the property values you entered. Users appear as rows in the UserManager, and as child components under the UserService container.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
283
UserService
Chapter 9 — About Security
UserManager
User
All available user properties, as seen in the New or Edit user dialog (
described as follows:
• Name
Unique name of the user, as known to the station. Used in login credentials (along with Pass-
word), also appears in audits of changes made by the user (see “About user audits” on page 278).
• Full Name
Full formal name of the user, or any descriptive name needed.
• Enabled
Either true (default) or false. Determines if the user account is operational. If disabled (false),
login attempts are blocked. By default, user guest
is disabled.
• Expiration
Either “Never Expires” (default) or “Expires on <date>”. After the expiration date, login attempts are blocked.
• Permissions
Either “Super User” (all permissions) or a specific permissions map (click “>>” control). Permis-
sions are category-based. For an overview, see “Permissions and security” on page 275 and also
“About permission levels” on page 276.
• Language
To specify a lexicon (typically two character language code, such as “fr” or “de”), as needed for language support or other customizing.
• Password
Password entered by user in login credentials (along with user Name). Two entry fields are provided, both entries must match. Can be any combination of alphanumeric characters.
Note: If the UserService is configured for strong passwords (property Require Strong Passwords), the password must be a minimum of 8 characters, with at least one character being a numeral (0—9) or any other special character, such as “!”, “@”, “#”, “$”, or “%”.
• Facets
Includes two separate settings, as follows:
•
Time Format
How timestamps are formatted in property sheets, and so on. The default time format is sourced from Baja lexicon.
•
Unit Conversion
Selectable as either None (default), Metric, or English. Primarily affects value display of “out” slots on control points.
• Nav File
To specify a Nav file that provides custom navigation for the user, defining locator bar content and home page. Click the folder control for a File Chooser dialog to navigate to the location of the station’s .nav files (by convention, a “Nav” folder under the station directory). For more details,
see “About the Nav file” on page 264.
Note: If guest is enabled, all browser connections to the host start using this Nav file.
• Web Profile
Includes three separate settings: two for station “auto logoff,” and one to specify the user’s expected type and level of HTTP browser access. The web profile settings are as follows:
284
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
UserService UserManager
•
Auto Logoff Enabled
Either true (default) or false. If true, a browser-connected user will be automatically disconnected from the station after the “auto logoff period” expires, providing that no user activity was detected during that time (changing views, expanding/contracting containers, and so on).
If disabled (false), this browser-connected user is never automatically disconnected.
•
Auto Logoff Period
Any number of hours, minutes, seconds needed (default is 15 minutes). Specifies the time period used by the auto logoff routine (“inactive user time”), if auto logoff is enabled for the user.
•
Type
Specifies the user’s expected type and level of HTTP browser access. For more details on profile types, see
“About Web Profiles” on page 239. Web Profile Type is one of the following:
•
Basic Hx Profile
Lowest level and simplest browser requirements (browser with Java plug-in not required).
•
Default Hx Profile
Provides more navigation controls with simple browser requirements (browser with Java plug-in not required).
•
Basic Wb Web Profile
Requires browser to have Java plug-in. Provides Workbench station access within a browser (Fox connection), but without top menu bar or ability for side bars.
•
Default Wb Web Profile
Requires browser to have Java plug-in. Allows nearly full Workbench station access within a browser (Fox connection), including top menu bar and side bars (palettes and Nav tree).
Note: If the same user might need to access the station differently, that is from a simple browser as well as from Workbench or a browser with Java plug-in support, you should create two user accounts for that person, each with a different Web Profile. For example, create a user with “Default Wb Web Profile” and another user with “Default Hx Profile.”
The simplest way to do this is to duplicate that user, then change the Web Profile type. That person will need to login differently (unique user name) according to their access method.
Lockout notes
If you have lockout enabled in the UserService
, a user will be locked out after several unsuccessful attempts to login (login using their user name, but with incorrect password). A locked-out user is indi-
cated with a red row in the UserManager, as shown in Figure 16
.
Figure 16 Locked out user is indicated by red
component that represents each user has a boolean “Lock Out” slot that provides read-only status of whether that user account is currently locked out (true) or not (false). If
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
285
UserService
Chapter 9 — About Security
PermissionsBrowser needed, you can link it to other logic in the station.
If locked out, a user will be unable to login into the station until the lockout period expires, as specified in the UserService. After that point, the user displays in the UserManager as normal.
As administrator, be aware that each user has an action “Clear Lock Out,” that you can invoke to clear any lockout in progress. Access this command with a right-click on a user, either selected in the Nav tree or in the UserManager, as shown in
Figure 17 Clear lockout action for any user
PermissionsBrowser
, use the view selector to select the PermissionsBrowser, as shown in
three rows in the tree: station (components), file, and history.
As needed, expand and contract the object tree to find objects that have been explicitly assigned into one or more categories, and scroll across to see each user’s permissions for those objects.
Again, displayed row color provides the same data as in the
• Yellow rows are objects explicitly assigned into one or more categories.
• Dimmed rows represent objects inheriting their parent’s category or categories.
You can also use Show Configured to automatically fully expand the tree.
Show Configured
Select Category Browser > Show Configured from the menu, or click the icon, as shown
in Figure 18 . The PermissionsBrowser tree expands to show all explicitly assigned objects.
286
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
UserService
Figure 18 Show Configured in PermissionsBrowser
PermissionsBrowser
In each cell intersecting a user (column) and object (row), that user’s permissions are shown with
abbreviations—see Permissions abbreviations . For any user, you can access permissions
.
Permissions abbreviations
Permissions for each object are shown in each of the user columns using abbreviations (
Figure 19 Permission abbreviations
Full permissions are “rwiRWI”, where the capital RWI is for admin-level Read, Write, Invoke. It is possible for a user to have no permissions for some objects (blank cell), if those objects are assigned
Access permissions
Double-click anywhere in a column to access a user’s permissions. This produces the same Permissions dialog as from the user’s properties, only user name shows in the window title bar (
).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
287
CategoryService
Figure 20 Permissions map from PermissionsManager
Chapter 9 — About Security
PermissionsBrowser
Note: If you double-click on any user with “super user” rights, a popup warning reminds you that you cannot modify permissions, as shown in
.
Figure 21 Super user permissions warning
If you could see the permission map for any super user, it would simply be all possible permissions checked for all possible
As shown in Figure 22 , remember to Save after making any user permissions changes.
Figure 22 Save user permissions changes
CategoryService
The CategoryService is found under a station’s Services container. You use a station’s CategorySer-
and assign objects (components, files, and histories) to those categories.
Note: For an overview of station security including categories, see
“Security model overview” on page 271, and
“Categories and security” on page 272.
Apart from being the container for child categories, the CategoryService has only two slots:
• Update Time
A property that sets the interval at which
are automatically assigned. Default value is one (1) minute. If assigned a zero value, this feature is disabled.
• Update
An action to manually force ancestor permissions to be assigned to objects in the station.
Note: Typically, you leave the service’s update time at default, and use the update action only if needed while testing (while actively assigning categories and/or changing permissions).
288
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
CategoryService CategoryManager
The two views of the CategoryService are:
•
•
The CategoryBrowser is the default view, and typically where you spend more time after initially creating categories.
Note: In the case of components, you can also make category assignments directly from any compo-
nent’s CategorySheet view. See “CategorySheet” on page 292.
CategoryManager
You use the CategoryManager to add, edit, or delete categories. As shown in
you can access the CategoryManager using the view selector from any CategoryService view.
Figure 23 CategoryManager is table based view
Rows in the CategoryManager table ( Figure 23 ) represent existing categories, where you can edit by
double-clicking one. Typically, you edit only the category name, to clarify some logical grouping. All categories must have both a unique name and index.
To add a new category, click the New button. This produces the New dialog, as shown in
Figure 24 New (category) dialog
You can create multiple categories by typing in a number in “Number to Add.” When you click OK,
the Add dialog includes that number of category rows in the top table ( Figure 25 ).
Figure 25 Adding multiple categories
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
289
CategoryService
Chapter 9 — About Security
CategoryBrowser
As needed, click to highlight a single category row before entering a unique Name. For a listing of all
the category properties, see “Category properties” on page 290.
When you click OK, the categories are added with the names you entered, and appear as rows in the
CategoryManager and as child components under the CategoryService container.
Note: While in theory unlimited categories could be created, in general it is recommended to limit the number of categories to as few logical divisions as needed. Included are performance rea-
sons, as well as other considerations. See “Category caveats” on page 290.
Category properties
• Index
Unique index number for the category, as it is known to the station.
• Name
Any descriptive name needed, typically to reflect some logical grouping.
Category caveats
Please note the following about using categories:
• Performance-wise, too many categories can consume excess station memory, as each object must maintain a bitmap for category membership. With the default 8 categories, this is only 1 byte, but increments another byte for each additional 8 categories added (9—16, then 17—24, and so on).
Therefore, you should limit categories to the fewest needed, and keep them indexed contiguously.
•
If you delete a category (using the CategoryManager
), you may notice it still appears listed in users’ permission maps, with default “Category n” name instead of its former user-assigned name.
This underscores that categories are simply indices to the station. Each category Name is simply
“metadata” (data about data).
Moreover, when you assign an component to one or more categories (e.g. using the Category-
Browser ), that component’s category bitmap is updated—as part of its configuration. If you copy
that component to another station or save it in a bog for reuse, please note that its category bitmap
(to category indices) is included.
CategoryBrowser
The CategoryBrowser is the default view of the
CategoryService . By default, this view shows the
three object types collapsed into just three rows in the tree: station (components), file, and history. In this view, the columns represent
Again, displayed row color provides the same data as in the
• Yellow rows are objects explicitly assigned into one or more categories.
• Dimmed rows represent objects inheriting their parent’s category or categories.
To automatically fully expand the tree, use Show Configured .
290
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 9 — About Security
CategoryService CategoryBrowser
Show Configured
Select Category Browser > Show Configured from the menu, or click the icon, as shown
in Figure 18 . The tree expands to show all objects explicitly assigned into one or more categories.
Figure 26 Show Configured in CategoryBrowser
Objects in dimmed rows have a check mark in the first column (Inherit), meaning that they inherit the category/ies of their parent container. As needed, in any object row, click either:
• In any category column to explicitly assign an object to a category, or again (toggle) to remove the object from that category.
• In the Inherit column to return category assignments to match the object’s parent.
Note: With the exception of the three “root” objects (station, files, history), each object must either belong to at least one category or inherit its parent’s category assignments. The three root objects cannot inherit—they must belong to one or more categories.
As shown in Figure 27 , remember to Save after making any needed category assignment changes.
Figure 27 Save category assignment changes
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
291
CategoryService
Chapter 9 — About Security
CategorySheet
CategorySheet
Included for every component in the station database is a CategorySheet view, which you can access using the right-click View menu (
Figure 28 ) or by using the view selector.
Figure 28 Accessing CategorySheet view
This view lists all categories in the station, and shows a check mark beside any that are assigned to this component.
In addition, the view’s right side offers various controls, as follows:
• Inherit (checkbox)
Click to toggle. While checked, this component inherits category assignments from its parent component. While cleared, you can make explicit category assignments for this component.
• Select All
Effective if Inherit is cleared. Click to assign component to all categories in the station.
• Deselect All
Effective if Inherit is cleared. Click to remove all category assignments for this component.
Note: Either click again to assign the component to at least one category, or else click Inherit.
Otherwise, you receive an error when you try to Save (must be assigned to one category).
• Category Service
Click to go to the CategoryBrowser view. See “CategoryBrowser” on page 290.
Note: Remember to click Save after making any needed category assignment changes.
292
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About the scheduling model
About Scheduling
Schedule component categories
Schedules in NiagaraAX are done using schedule components, as found in the schedule palette
(
). You place these components in a station, configure, and link as needed to provide scheduling control of other components. Each schedule component has a “scheduler” view, which you use to define events.
Figure 1 schedule palette
The following main sections provide more details:
•
•
•
About calendar schedules (holidays)
•
•
(schedule-related tasks)
About the scheduling model
NiagaraAX scheduling is summarized in the following sections:
•
•
•
•
•
Schedule exports and imports (master/slave)
Schedule component categories
The three categories of schedule components are as follows:
• Weekly schedules
These schedules define regular, repeating, events by “time-of-day” and “day-of-week.” Also, any number of “special events” are configurable. Typically, these are the most used schedule components. Four different types vary by data category (Boolean, Numeric, Enum, and String). Each is identical except for input/output. For more details, see
“About weekly schedules” on page 297.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
293
About the scheduling model
Chapter 10 — About Scheduling
Schedule component views
• Calendar schedule
A CalendarSchedule component is available to define specific days. Typically, you use them to define days with scheduling exceptions (e.g. holidays), and reference them in the “special events”
setup of weekly schedules. For details, see “About calendar schedules (holidays)” on page 309.
• Trigger schedule
A TriggerSchedule component is used to schedule the firing of topics. As needed, you typically link its output to an action of a control point or extension. For more details, see
“About trigger schedules” on page 315.
Schedule component views
The default view for any schedule component is its “scheduler” view, where you define related days and events.
•
The Weekly Scheduler view for any weekly schedule component provides four tabs, as follows:
• Weekly Schedule — Specifies Sunday-through-Saturday (weekly) event times/values.
• Special Events — All exceptions to the defined weekly schedule, as special events.
• Properties — Important properties such as default output, schedule effective times, special event cleanup operation, and schedule facets.
• Summary — For any selected day, provides summary of all schedule events, with source.
In addition, any weekly schedule component provides a “Current Day Summary” view, providing a simple linear 24-hour graph of schedule event times and values for the current day.
•
for a CalendarSchedule provides a “calendar” where you add, edit, or delete calendar days and establish relative priorities.
•
The Trigger Scheduler view for a TriggerSchedule provides a two-part view combining a “day
picker” and an event “time picker” for specifying when topics are fired on those days.
At the bottom of any scheduler view are buttons Refresh
, described as follows:
Refresh
The Refresh button is always available.
When you click Refresh, one of two things happens:
• If the Save button is not available (no unsaved changes), clicking it re-synchronizes the view with the component’s current configuration.
•
If the Save button is available (unsaved changes), clicking it produces a dialog ( Figure 2 ).
Figure 2 Refresh confirmation if unsaved changes
Your refresh confirmation dialog choices are as follows:
• Yes
Save all changes made in the view since last save. Equivalent to clicking
• No
294
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About the scheduling model
Clear all changes made in the view since last save (effective reset).
• Cancel
Cancels refresh, all unsaved changes remain as unsaved.
Schedule component links
Save
The Save button is available only if you have made unsaved changes in the component’s scheduler.
Clicking it downloads your changes to the schedule component’s configuration. Immediately following, the Save button is unavailable again.
Note: For weekly schedules (tabbed
), you typically save while working in each tab, even though any save applies to changes made on all tabs.
Schedule component links
To use weekly schedules and the trigger schedule, you link the component’s “Out” slot (as source) to a slot on another component. The same schedule can be linked this way to many target components.
•
•
Typically, you do not link a CalendarSchedule. Instead, you reference one or more CalendarSchedules from a weekly schedule, in its “special events” setup. This allows global editing of day definitions.
Weekly schedule links
Typically, you link a weekly schedule to one or more “writable” control points. For some examples, you could link the Out slot of weekly schedule types as follows:
• BooleanSchedule to a BooleanWritable that is a proxy point for a Binary Output object in a BACnet device.
• NumericSchedule to a NumericWritable that is a proxy point for setpoint NVI in a LON device.
By convention, when linking to a target writable point (with 16-level priority array), you select “In16” among its different priority array inputs. However, you are free to select any available input level.
In a few cases, you may wish to “chain” weekly schedules from “Out” slot to “In” slot. This technique is typically useful only if one of the chained schedules is “effective” during any period in time.
Trigger schedule links
Typically, you link a trigger schedule to an action of a control point or perhaps even more often, an action of a point extension. For example, you could link a TriggerSchedule to the “ResetElapsedActiveTime” action of a DiscreteTotalizerExt, a point extension for a BooleanPoint used to accumulate runtime. If the trigger schedule was configured to fire only on the first day of every month (at
12:00am) that extension could be used to hold the current month’s runtime.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
295
About the scheduling model
Chapter 10 — About Scheduling
Schedule special events
Schedule special events
Special events apply to weekly schedules only, and are considered any exception to the (normal) weekly schedule. Special events can be “one-time” only event changes or recurring event changes, such as holidays. Configuration includes both day(s) of occurrence and related time-of-day events.
In the time-of-day event definitions of special events, you can have them “intermingle” with regular weekly events, or completely override the weekly schedule. In addition, you visually prioritize special events, via list order. This allows any overlapping special events to occur in an ordered fashion.
Each weekly schedule component has its own special events, configured on a Special Events
tab in its scheduler view. Event times (and values) entered for any special event apply to that schedule only.
However, if the special event is a “reference” type, days of its occurrence are specified in the CalendarSchedule component that is referenced. This allows you to globally change the days that special events occur in weekly schedules, by editing one or more referenced CalendarSchedules. For more
details, see “CalendarSchedule Usage” on page 309.
Schedule exports and imports (master/slave)
Using the NiagaraAX driver architecture, you can create “master/slave” schedules in order to share schedule configuration between devices. This allows you to globally update the configuration of any slave schedule by simply making changes to its master schedule.
The typical application of this is in a multi-station Niagara network, where you:
• Import a schedule component from another station. Typically, you do this in a JACE station, importing a schedule component that resides in a Supervisor station. This creates a local copy that you can use and link into control logic, but cannot otherwise configure (change events, and so on).
When you import a NiagaraAX schedule, a “schedule export descriptor” is automatically created on the sending (master) station, under the NiagaraStation component that represents the receiving side.
This allows for “sending-side” management of configuration synchronization. For more details, see
“Station Schedules import/export notes” on page 163.
If using the Bacnet driver, the same basic architecture is available. You can import BACnet Schedule and Calendar objects from a BACnet device, and model them as NiagaraAX schedule components.
For more details, see the following topics in the
section:
•
“About the Schedules extension” on page 120.
•
“About Schedules extension views” on page 142.
Note: The Bacnet driver lets you export NiagaraAX schedules from the station to existing BACnet
Schedule and Calendar objects in a BACnet device, acting as the “master” source. Also, you can expose Niagara schedule components as BACnet Schedule or Calendar objects for access by any networked BACnet device. You do this through configuration of the “Export Table” under the BacnetNetwork’s “Local Device.” For more details, see the Bacnet Users Guide.
296
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules
About weekly schedules
Types of weekly schedule components
The following sections explain weekly schedule concepts:
•
Types of weekly schedule components
•
Weekly schedule output processing
•
Types of weekly schedule components
Each component type varies only by data value category, meaning its
(generally called “out-
component type, for example, StatusBoolean if a BooleanSchedule, StatusEnum if an EnumSchedule.
The four weekly schedule component types are:
•
•
•
•
In typical use, only outputs of schedules are linked to other components for scheduling control, such as “writable” points of the same type.
shows a BooleanSchedule and NumericSchedule, each
linked to two writable points. See “Schedule component links” on page 295 for more details.
Figure 3 Schedules linked to writable points
About the BooleanSchedule
The BooleanSchedule is typically the most used weekly schedule. Use it directly for schedule control of BooleanWritable points (typically proxy points). If needed, it also has application for linkage to slots in extensions. For example, using an intermediate kitControl object (say, a “Not” logic-type object) use a BooleanSchedule for linkage to the Enabled slot of an alarm extension.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
297
About weekly schedules
Chapter 10 — About Scheduling
Weekly schedule output processing
About the EnumSchedule
The EnumSchedule allows schedule control of EnumWritable points (typically proxy points). For example, link it to an EnumWritable that proxies a BACnet Multistate Output object, or to an Enum-
Writable that proxies a LON NVI (using an enumerated SNVT).
To properly use an EnumSchedule, first define its Facets to match those in linked EnumWritable(s).
About the NumericSchedule
The NumericSchedule allows schedule control of NumericWritable points (typically proxy points), which may represent setpoints, limits, or any number of other variables.
About the StringSchedule
The StringSchedule allows schedule control of StringWritable points (possibly proxy points).
Weekly schedule output processing
For any weekly schedule (
EnumSchedule , NumericSchedule , StringSchedule
), output recalculation occurs upon any of the following:
• any saved change to its configuration
• any change at its input
• station startup
• any change to the system clock
Each component has an Out slot and an Out Source slot . In addition,
Next Time and Next Value slots
are available. By default, all of these slots are “pinned” on the component’s shape on the wire sheet,
as shown in Figure 3 . Upon any output change, all of these slots are updated.
Out slot
A schedule’s output value is determined by the following, in highest-to-lowest priority:
1. To any “non-null” value at its In slot (if linked)
This value is immediately passed to its output. Otherwise (if null), processing continues.
2. If the schedule is not effective, the output goes to the
value.
If the schedule is effective, the output goes to the (highest priority) active special event (if any).
3. To the active weekly schedule event (if any).
4. To the
value.
For more details on effective schedules, see “Effective Period” on page 306.
Out Source slot
Out Source provides a string “source description” of the current output, as one of the following:
•
Input
298
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules Weekly Scheduler view
•
Special Event: <SpecialEventName>
•
Week: <day_of_week>
•
Default Output
Examples might appear as “
Week: monday
” or “
Special Event: Christmas Break
”
Next Time and Next Value slots
These slots provide “look-ahead” data: the next known schedule output value, and its time of change.
• Next Time — Displays in Baja AbsTime format, for example:
03-Feb-05 5:00 PM
• Next Value — The next scheduled output value.
Typical application is for informational display. If needed, slots can be linked into control logic. For example, TimeDifference and CurrentTime objects (kitControl, Timer) provide AbsTime slots too.
Weekly Scheduler view
Double-clicking any weekly schedule in Workbench produces its Scheduler view ( Figure 4 ).
Figure 4 Scheduler view for weekly schedule
There are four tabs:
, and
apply to all tabs in the Scheduler view (not just the one displayed).
Weekly Schedule
Use this tab in the Weekly Scheduler view to enter regular schedule events, that is “normal schedule
events” that repeat from week to week, based on the day of the week and the time of day. By default, any existing events appear as greenish blocks, while unscheduled (default output) time appears in white.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
299
About weekly schedules
Chapter 10 — About Scheduling
Weekly Scheduler view
Use is mostly straightforward, to add a new event simply click in a day at the approximate event start time, and drag down to define the start and finish time (
). The event remains selected (by default, dark blue) when you release the mouse button.
Note: If an EnumSchedule, you should define its range facet from the Scheduler’s
before adding events. See
“Facets” on page 306 for more details.
Figure 5 Click and drag to enter weekly events
As needed, click again and drag on the event’s top or bottom to change its start or finish time (in broad increments).
Additional details about the Weekly Schedule tab are as follows:
•
•
•
Event time “tuning”. With any event selected, “fine tune” its start and finish time using the controls,
selecting the hours portion or minutes portion ( Figure 6 ). Or, click and type values in directly.
Figure 6 Define start and finish time
Note: For any event, start time is inclusive, and the event extends to (but is exclusive of) the end time. In other words, there is no output “blip” between adjacent events, even if across days.
For example, if a Monday event ends at midnight, then a Tuesday event starts at midnight, the schedule output is continuous (providing both events have the same
).
Output value. For any event, you can select the “null” checkbox (the schedule’s calculated value is null for that event). However, you typically select or type a value instead, as follows:
•
If a Boolean or EnumSchedule select the event value in the output field, see Figure 7 , left.
Note: If an EnumSchedule, first specify its facets (on
Properties tab) before entering values. This
allows selection of possible values.
300
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules Weekly Scheduler view
• If a NumericSchedule or StringSchedule, you type the value in the output field, then press Enter
to register it in the event block, as shown in Figure 7 , right.
Figure 7 Select (Boolean, Enum) or type (Numeric, String) output value
Right-click menus. Right-click in the weekly schedule area for an event menu. If you have any event
selected, this menu provides the most commands, as shown in
.
Figure 8 Right-click menu with event selected
Event menu options are straightforward, and may include the following:
• Delete Event — Deletes the selected event.
• Paste Day — Appears only if copy day option was used first. Copies all events into selected day.
• All Day Event — Makes currently selected (or last entered) event extend to entire day.
• Apply M-F — Copies all events in the selected day to Mon, Tue, Wed, Thu, and Fri (and over-
writes any existing events on those days).
• Copy Day — Copies all events in the selected day, to use with paste day option.
• Clear Day — Clears all events in the selected day.
• Clear Week — Clears all events in the entire weekly schedule.
Special Events
Use this
tab to enter all exceptions to the schedule’s weekly schedule, broadly
called “special events.” For general information, see “Schedule special events” on page 296.
As shown in Figure 9 , existing special events (if any) are listed in the table by name and summary.
When you select a special event, its day(s) of occurrence are highlighted in the monthly calendars at the top of the view, and its associated event actions are displayed in the right-side column.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
301
About weekly schedules
Figure 9 Special Events tab in weekly Scheduler
Chapter 10 — About Scheduling
Weekly Scheduler view
Additional details about the Special Events tab are as follows:
•
•
•
•
Right-click menus and other controls
Adding special events. Click the Add button to add a new special event. An Add dialog appears, as shown in
.
Figure 10 Special Events Add dialog
Dialog options are described as follows:
• Name — Your descriptive name for special event, perhaps “Christmas_Break” or “Half_Day.”
The default value is simply “Event.” You can change this later, if needed.
• Type — Determines selection criteria for day or days, with the following choices:
• Date — (default) By various combinations of weekday, numerical date, month or month combinations, and year.
• Date Range — By start and end range, using for each a combination of day, month, year.
• Week and Day — By combination of day of week, week in month, month.
302
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules Weekly Scheduler view
• Custom — By various combinations of day, month, weekdays, and year.
• Reference — By reference to a specific CalendarSchedule component in the station.
For details on most Type selections, see
“Calendar day selections” on page 312. If you select type
dars) available in the station, by slot path. Select any one for the day(s) portion of this special event.
Figure 11 Reference special event Add dialog
After you have a name and type selected (and defined as needed), click OK to add it to this schedule’s special events. It remains selected for further editing, except for type.
Event times and output values. A newly-created special event has no events defined. With the special event selected, click in the right-side events column and enter events as necessary. Start, finish,
and output controls work the same as in the Weekly Schedule
tab. See “Event time “tuning”” on page 300 and “Output value” on page 300 for details.
You can also right-click in the column for an event menu, as shown in
Figure 12 . This is useful to add
an all-day event or set the entire day to the schedule’s default value.
Figure 12 Special event schedule actions
Note: You must specify events for any special event to occur. Where nothing is scheduled, the special event relinquishes control back to any lower-priority schedule events, and finally “intermingles” with the weekly schedule. To completely override the weekly schedule, configure a special event for the entire day.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
303
About weekly schedules
Chapter 10 — About Scheduling
Weekly Scheduler view
Special event priorities. All special events take priority over regular weekly events. Among special events, you define relative priorities by the order of listing in the Special Events table, as follows:
• Highest priority is at top of list. Events in this special event, when active, always occur.
• Lowest priority is at bottom of list. Events occur only if not overlapped by other special events active during the same period.
Change a special event’s priority by selecting it and using the priority arrow buttons (
).
Figure 13 Change priority by listing order
Right-click menus and other controls. Right-click in the special events table for a menu. If you have any special event selected, this menu provides the most commands, as shown in
.
Figure 14 Right-click menu with event selected
Special event menu options are straightforward, and may include the following:
• Add — Add a new special event (same as using Add button).
• Edit — Edit day(s) selection criteria (but not changing special event type). Same as Edit button.
• Rename — Rename selected special event (same as using Rename button).
• Priority (up) — Move special event up in priority list (same as using Priority button).
• Priority (down) — Move special event down in priority list (same as using Priority button).
• Delete — Removes selected special event from the schedule component.
Note: When you delete a special event, a confirmation dialog appears as shown in
.
Figure 15 Delete special event confirmation
Click Yes to delete the special event, or No to keep it.
304
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules Weekly Scheduler view
When you first access the Special Events tab, the current day is highlighted in the left-most calendar month at the top of the view. As needed, click on Next Month and Prev Month, or Next Page and Prev Page to traverse the calendar ahead or back in time.
When you select a special event in the table, if it occurs in any currently displayed month, its associ-
ated day or days are highlighted as shown in Figure 16 .
Figure 16 Special event highlights in calendar block
Note: A special event must have at least one defined event action to be highlighted in a calendar.
Return to the current calendar month and day by clicking the Today button.
Properties
As shown in Figure 17 , this tab in
Weekly Scheduler view is where you specify the schedule’s:
•
•
•
•
Figure 17 Properties tab in weekly Scheduler
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
305
About weekly schedules
Chapter 10 — About Scheduling
Weekly Scheduler view
Effective Period. By default, a weekly schedule added from the schedule palette is always effective.
Whenever a schedule component is not effective, its output (Out slot) goes to its
regardless of its weekly schedule or any special events.
In most cases, you leave weekly schedules as always effective. However, if you have an application for a schedule effective only at certain times, use the “start” through “end” range fields to limit the
effective period. When you Save the changes, only effective days in the calendar months are shown
highlighted green.
Default Output. Whenever a schedule event (special or weekly) is not defined, the schedule component’s output (“Out” slot) is this value. The white area labeled “Default” in listed events corresponds to this (
). The default output value is also used whenever the schedule is not effective.
Figure 18 Default output is white area in schedule events
Note that “null” is an available choice—depending on control logic, this may be a valid choice.
As copied from the schedule palette, the default “Default Output” varies by schedule type, as follows:
• BooleanSchedule — false
• EnumSchedule — 0 (no facets defined)
• NumericSchedule — null
• StringSchedule — <blank>
Facets. The schedule component’s facets determine how its output value is formatted for display. For example, instead of “true” and “false” for a BooleanSchedule, you may need “On” and “Off” instead.
Assigned facets appear in scheduler views when adding events, displaying summary data, and so on.
For complete details, see “About point facets” on page 58.
Note: Facets are especially important for
EnumSchedule s. You need to define “range” facets before
you add weekly schedule events (in order to pick an event’s enumerated value). Range facets should match those used in any controlled (output-linked) EnumWritables. For related details,
see “Facets importance for Enum points” on page 59.
In the case of StringSchedules (as for all string-type components) facets have no application.
shows output selections for an EnumSchedule with its range facet defined as “lonworks:LonOccupancyEnum,” one of the available frozen facets.
306
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About weekly schedules
Figure 19 Facets determine event value selections for EnumSchedules
Weekly Scheduler view
By default, facets for schedule components as copied from the schedule palette are as follows:
• BooleanSchedule — trueText: true, falseText: false
• EnumSchedule — range: <not defined>
• NumericSchedule — units: (null), precision: 1
• StringSchedule — (not applicable)
Cleanup Special Events. This property is either true (default) or false.
• If true, “one-time” special events that have occurred (and will not be effective again) are automatically deleted. When a special event is deleted, a message is sent to the schedule log, and that spe-
cial event no longer appears in the Special Events tab.
• If false, “one-time” special events are retained, even though they will not occur again.
Summary
The summary tab in the Weekly Scheduler view shows a summary listing of all scheduled events for
any one selected day in a weekly schedule ( Figure 20
). Events may be from the normal weekly schedule, special events, or a combination of both. Unlike with other tabbed views, this one is read-only.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
307
About weekly schedules
Figure 20 Summary tab shows all events for any selected day
Chapter 10 — About Scheduling
Weekly Scheduler view
In the top calendar month area:
• Days with schedule events are shown highlighted green.
•
Days without schedule events (only default output ) are shown in white.
As needed, click on Next Month and Prev Month, or Next Page and Prev Page to traverse the calendar ahead or back in time.
• Click any day to see its events.
• Click Today (at top) to see the current day’s events.
The table lists each event’s start timestamp, the schedule’s output value, and the event source. See
“Out Source slot” on page 298 for how event source information appears.
308
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About calendar schedules (holidays)
About calendar schedules (holidays)
CalendarSchedule Usage
Calendar schedules (CalendarSchedule component) specify entire days, using the following four types of day event selections:
• Date
• Date Range
• Week and Day
• Custom
You can add as many day events as needed in the same CalendarSchedule. The following sections provide more details:
•
•
•
•
CalendarSchedule slots and other notes
CalendarSchedule Usage
Instead of linking CalendarSchedules, you typically “reference” them from the “special events” configuration of one or more weekly schedules. Each referenced CalendarSchedule defines the “day portion” of a special event. Then, you configure time-of-day events in each special event, as needed.
Figure 21 Example referenced CalendarSchedules
For example, Figure 21 shows a
and a portion of its special events tab, listing five special events. Three of these are “Reference” types, meaning their calendar day(s) are defined
remotely in the configuration of the referenced CalendarSchedules. Although all components are shown here in the same container, quite often CalendarSchedules are located elsewhere in the station.
CalendarSchedule usage by “special event reference” allows global changing of day definitions, where multiple weekly schedules can reference one or more CalendarSchedules. Any edit of a CalendarSchedule affects all weekly schedules containing a special event that references it.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
309
About calendar schedules (holidays)
Chapter 10 — About Scheduling
Calendar Scheduler view
Calendar Scheduler view
Double-click a CalendarSchedule to see its default Calendar Scheduler view, as shown in Figure 22 .
Figure 22 Calendar Scheduler view
As shown in
Figure 22 , existing calendar events (if any) are listed in the table by name and summary.
When you select a calendar event, its day(s) of occurrence are highlighted in green in the monthly calendars at the top of the view.
Additional Calendar Scheduler topics include:
•
•
Right-click menus and other controls
Adding calendar events
Click the Add button to add a new calendar event. An Add dialog appears, as shown in Figure 23 .
Figure 23 Special Events Add dialog
310
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About calendar schedules (holidays) Calendar Scheduler view
Dialog options are described as follows:
• Name — Your descriptive name for the calendar days, perhaps “Thanksgiving_Break” or
“Cleaning_2.” The default value is simply “Event.” You can change this later, if needed.
• Type — Determines selection criteria for day or days, with the following choices:
• Date — (default) By various combinations of weekday, numerical date, month or month combinations, and year.
• Date Range — By start and end range, using for each a combination of day, month, year.
• Week and Day — By combination of day of week, week in month, month.
• Custom — By various combinations of day, month, weekdays, and year.
For details on Type selections, see “Calendar day selections” on page 312.
After you have a name and type selected (and defined as needed), click OK to add it to this calendar’s days. It remains selected for further editing, except for type.
Right-click menus and other controls
Right-click in the calendar events table for a menu. If you have any calendar event selected, this menu provides the most commands, as shown in
.
Figure 24 Right-click menu with event selected
Note: Priority selections (right-click menu or in bottom buttons) only affect the list order for events in a CalendarSchedule—true priority applies only to special events (in weekly schedules).
Calendar event menu options are straightforward, and may include the following:
• Add — Add a new calendar event (same as using Add button).
• Edit — Edit day(s) selection criteria (but not changing calendar type). Same as Edit button.
• Rename — Rename selected calendar event (same as using Rename button).
• Priority (up) — Move calendar event up in display list (same as using Priority button).
• Priority (down) — Move calendar event down in display list (same as using Priority button).
• Delete — Removes selected calendar event from the schedule component.
Note: When you delete a calendar event, a confirmation dialog appears as shown in
.
Figure 25 Delete calendar event confirmation
Click Yes to delete the calendar entry, or No to keep it.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
311
About calendar schedules (holidays)
Chapter 10 — About Scheduling
Calendar day selections
When you first access the Calendar Scheduler, the current day is highlighted in the left-most calendar month at the top of the view. As needed, click on Next Month and Prev Month, or Next Page and Prev Page to traverse the calendar ahead or back in time.
Return to the current calendar month and day by clicking the Today button.
Calendar day selections
When adding calendar days in a CalendarSchedule, a special event in a weekly schedule, or a trigger event in a trigger schedule, the following “Type” selections are available:
•
Date — see “Date selection notes” on page 312
•
Date Range — see “Date range selection notes” on page 312
•
Week and Day — see “Week and day selection notes” on page 313
•
Custom — see “Custom selection notes” on page 314
Date selection notes
As shown in Figure 26 , Date calendar selection has 4 criteria: weekday, day-of-month, month-of-
year, and year.
Figure 26 Calendar selection by date
You can make only one selection in each criteria.
Each criteria offers an “any” selection, in addition to a specific selection (weekday, day-of-month, month-of-year, year). In addition, the month-of-year criteria provides an “every other month” selection, as one of the following:
• Jan-Mar-May-Jul-Sep-Nov
• Feb-Apr-Jun-Aug-Oct-Dec
Result of selections is by “ANDing” all criteria. For example, if you select weekday of Tuesday, day of month as 5, and remaining criteria “any,” the event is specified only on Tuesday, the fifth of any month in any year. If a month does not have Tuesday the fifth, then there is no event that month.
Date range selection notes
As shown in Figure 27 , Date Range calendar selection has a start range and end range, each with 3
criteria: day-of-month, month-of-year, and year.
312
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About calendar schedules (holidays)
Figure 27 Calendar selection by date range
Calendar day selections
You can make only one selection in each criteria.
Each criteria offers an “any” selection, in addition to a specific selection (day-of-month, month-ofyear, year). In addition, the month-of-year criteria provides an “every other month” selection, as one of the following:
• Jan-Mar-May-Jul-Sep-Nov
• Feb-Apr-Jun-Aug-Oct-Dec
In each date range, result is from “ANDing” the criteria. In addition, the start day can be after the end date. For example, as shown in
, the start day can be in December and the end date in
March. This event occurs December, January and February.
Week and day selection notes
As shown in
Figure 28 , Week and Day calendar selection has 3 criteria: weekday, week-in-month, and
month-of-year.
Figure 28 Calendar selection by week and day
You can make only one selection in each criteria.
Each criteria offers an “any” selection, in addition to a specific selection (weekday, week-in-month, month-of-year). In addition, the following criteria offer additional selections, as follows:
• week-in-month: last 7 days
• month-of-year:
• Jan-Mar-May-Jul-Sep-Nov
• Feb-Apr-Jun-Aug-Oct-Dec
The result is from “ANDing” the criteria. For example, as shown in
, if selections are for weekday as Monday, the month as February, and the week as 3, the event occurs only on the third
Monday in February.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
313
About calendar schedules (holidays)
Chapter 10 — About Scheduling
CalendarSchedule slots and other notes
Custom selection notes
As shown in
Figure 29 , Custom calendar selection has 5 criteria: day-of-month, month-of-year, week-
day, week-in-month, and year.
Figure 29 Calendar selection by custom
Unlike with other calendar types, you can make multiple selections within each criteria (except if you select “any,” which allows only that selection). To select multiples, first select something other than
“Any,” then hold down the Ctrl or Shift key while you select more values.
Each criteria offers an “any” selection, in addition to a specific selection. In addition, the following criteria offer additional selections, as follows:
• day-of-month:
• Last Day
• Last 7 Days
• week-in-month: Last 7 Days
Within any criteria, selections are “OR’ed.” The overall result is from “AND’ing” all criteria. For example,
shows a custom selection for U.S. General Election Day, which must be configured as the “first Tuesday after the first Monday in November.”
CalendarSchedule slots and other notes
The CalendarSchedule has a StatusBoolean input and output (slots “In” and “Out”). In most applications they are left unlinked.
• Output is true during any configured calendar day(s), otherwise it is false.
• Input overrides the calendar schedule calculation (if linked). Any non-null input (true or false) is immediately passed to the output.
By default, for any CalendarSchedule copied from the schedule palette, the following additional slots are pinned on the component’s glyph (shape on wire sheet):
• Next Time
Time of next scheduled output change for the CalendarSchedule. If more than a year away, this value is null.
314
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About trigger schedules Trigger Scheduler view
• Next Value
The next scheduled output value, at “Next Time”. Value is meaningless if Next Time is null.
From the CalendarSchedule’s property sheet, you can access and change the following additional slots:
• Cleanup Expired Events
Either true (default) or false.
• If true, calendar events of type “Date” and “Date Range” that have already occurred, and can-
not occur again (as configured), are automatically deleted after they occur. This is recorded in the schedule log, and you no longer see them in the
• If false, all calendar events are retained, even if they cannot occur again (as configured).
• Facets
Facets applied to the input and output, which by default are simply “true” and “false.”
About trigger schedules
TriggerSchedules are special-purpose schedules, providing scheduling control for either linked
actions or topics of other components. Figure 30
shows a simple example of a TriggerSchedule linked to an action slot of a DiscreteTotalizerExt, which was “composited” in the parent BooleanWritable.
Figure 30 Example TriggerSchedule
This schedule is configured to simply fire once at midnight on the first day of every month. The trigger at the “ResetElapsedActiveTime” slot zeroes the runtime accumulated from the previous month.
The following sections provide more TriggerSchedule details:
•
•
TriggerSchedule slots and other notes
Trigger Scheduler view
Double-click a TriggerSchedule to see its default Trigger Scheduler view, as shown in Figure 31 .
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
315
About trigger schedules
Figure 31 Trigger Scheduler view
Chapter 10 — About Scheduling
Trigger Scheduler view
As shown in Figure 31 , the Trigger Scheduler has two sides:
•
Calendar (left) side — where you add events. It operates like the Calendar Scheduler view .
• Time picker (right) side — where you add trigger times for the schedule to fire its trigger output.
Included is the ability to add repeating intervals.
Note: Trigger times, as set in the time picker, apply to all calendar events (if more than one).
Existing trigger events (if any) are listed in the table by name and summary. When you select a trigger event, its day(s) of occurrence are highlighted in green in the monthly calendars at the top of the view.
Trigger times are listed in the time picker area.
Additional Trigger Scheduler topics include:
•
•
Adding trigger events
Click the Add button to add a new trigger event. An Add dialog appears, as shown in Figure 32 .
Figure 32 Trigger Event Add dialog
316
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About trigger schedules Trigger Scheduler view
Dialog options are described as follows:
• Name — Your descriptive name for the trigger events, perhaps “FirstDOM” or “Each_WorkHr.”
The default value is simply “Event.” You can change this later, if needed.
• Type — Determines selection criteria for day or days, with the following choices:
• Date — (default) By various combinations of weekday, numerical date, month or month combinations, and year.
• Date Range — By start and end range, using for each a combination of day, month, year.
• Week and Day — By combination of day of week, week in month, month.
• Custom — By various combinations of day, month, weekdays, and year.
For details on Type selections, see “Calendar day selections” on page 312.
After you have a name and type selected (and defined as needed), click OK to add it to this calendar’s days. It remains selected for further editing, except for type. Typically, you add one or more trigger
event times on the time picker side. See “Adding trigger event times” on page 317.
Adding trigger event times
By default, a single “midnight” trigger time already exists (you can delete it if desired). To add other trigger times, use the controls at the bottom of the time picker side, as shown in
.
Figure 33 Trigger time picker controls
Set the desired time in the hour:minute editor, either by clicking up/down controls or typing in times directly. Click the Add button to add a trigger at that time, which adds it to the list. You can also
enter multiple triggers simultaneously, using the Range option .
Range option. To add multiple triggers that occur at a repeating interval, select the Range checkbox.
This enables the Range End and Range Interval fields for entering values, as shown in
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
317
About trigger schedules
Figure 34 Range option in trigger time picker
Chapter 10 — About Scheduling
Trigger Scheduler view
When a entering trigger range, note that the top (hour:minute) editor acts as the first (or Range
Begin) trigger time. By default, the Range Interval is set to one hour (“
+00001h 00m 00.000s
”).
You can set this to whatever interval is needed.
To delete a trigger time, click to select, then click the Remove button. To select multiple trigger times, hold down the Ctrl or Shift key while you select.
Right-click menus and other controls
The time picker (right side) has no right-click menu—simply use the bottom controls to configure trigger times. The calendar (left side) has an available right-click menu. If you have any calendar
event selected, this menu provides the most commands, as shown in Figure 35 .
Figure 35 Right-click menu with event selected
Note: Priority selections (right-click menu or in bottom buttons) only affect the list order for events in a TriggerSchedule—true priority applies only to special events (in weekly schedules).
Event menu options are straightforward, and may include the following:
• Add — Add a new calendar event (same as using Add button).
• Edit — Edit day(s) selection criteria (but not changing calendar type). Same as Edit button.
• Rename — Rename selected calendar event (same as using Rename button).
• Priority (up) — Move calendar event up in display list (same as using Priority button).
• Priority (down) — Move calendar event down in display list (same as using Priority button).
• Delete — Removes selected calendar event from the schedule component.
318
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
About trigger schedules TriggerSchedule slots and other notes
Note: When you delete a calendar event, a confirmation dialog appears as shown in
.
Figure 36 Delete calendar event confirmation
Click Yes to delete the calendar entry, or No to keep it.
When you first access the Trigger Scheduler, the current day is highlighted in the left-most calendar month at the top of the view. As needed, click on Next Month and Prev Month, or Next Page and Prev Page to traverse the calendar ahead or back in time.
Return to the current calendar month and day by clicking the Today button.
TriggerSchedule slots and other notes
By default, for any TriggerSchedule copied from the schedule palette, the main “Trigger” output slot is pinned on the component’s glyph (shape on wire sheet), as well as the following additional ones:
• Enabled
Either true (default) or false. While false, firing of trigger outputs is disabled. If linking, note that this slot uses simple Boolean, you may need a StatusBooleanToBoolean (kitControl) component.
• Last Trigger
Timestamp of the last firing of the trigger output.
• Next Trigger
Next scheduled trigger firing time.
From the TriggerSchedule’s property sheet, you can access the following additional slots:
• Next Trigger Search Limit
How far into the future to search for the next trigger. It is possible a poorly-configured schedule will never fire a trigger. This setting prevents an infinite search. Default is one year (8760 hours).
• Last Modified
(read only) Timestamp of last configuration change.
• Status
(read only) Status of the schedule component, typically “{ok}.”
Trigger Missed slot
In addition to the “main” Trigger output slot, the TriggerSchedule has “Trigger Missed” slot, also a topic type slot. If the station was not running when a scheduled trigger was to occur (appeared previously in “Next Trigger” property), upon station startup the Trigger Missed slot fires once.
Note: Trigger Missed always fires only once, no matter how many triggers may have been missed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
319
Using schedules
Chapter 10 — About Scheduling
Adding a schedule or calendar
Using schedules
The following main sections provide common tasks for working with schedules in NiagaraAX:
•
•
Configuring schedules and calendars
•
•
Adding a schedule or calendar
In your station, you can copy a default schedule component directly from the schedule palette, or copy a pre-configured schedule component from a saved bog file or other station database.
Note: Once in your station and configured, you can also duplicate schedule components (see
“To duplicate a component (property sheet, nav side bar, or wire sheet view)” on page 351.
To add a component from the schedule palette
You can add (copy) a new schedule component from the schedule palette, dragging onto a container in the Nav tree view or into the wire sheet view.
To add a new schedule component from the schedule palette, do the following:
1. Open the schedule palette. See “Using the palette side bar” on page 345 for general details.
When the palette is open, schedule components are listed, as shown in
2. Drag the component needed from the palette to either:
• In the Nav tree, onto a folder in your station.
• In the view pane, into the wire sheet of a folder in your station.
A Name dialog appears.
3. In the Name dialog, type the desired name and click OK.
The schedule or calendar is now in your station, with default values.
To copy an existing, saved (configured) schedule component
You can add (copy) a new schedule component from one previously configured, dragging onto a container in the Nav tree view or into a folder’s wire sheet view.
To add a new schedule component as a copy of an existing saved component, do the following:
1. In the Nav tree, expand My File System and navigate to the saved bog file or station con-
fig.bog file. See “Editing components” on page 346 for more details.
2. When you locate the desired schedule component, right-click and select Copy.
3. Paste the copied component doing a right-click Paste from either:
• In the Nav tree, on a folder in your station
• In the view pane, in the wire sheet of a folder in your station.
A Name dialog appears.
4. In the Name dialog, type the desired name and click OK.
The schedule or calendar is now in your station, with pre-configured values.
320
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
Using schedules
Configuring schedules and calendars
Configuring schedules and calendars
Typically, you perform most configuration of any schedule component from its default “scheduler”
view. For an overview, see “Schedule component views” on page 294.
•
•
Configuring calendar schedules
•
Configuring weekly schedules
Weekly schedules ( BooleanSchedule
, EnumSchedule , NumericSchedule
, and
) are among the most used schedule components.
To configure a weekly schedule
You use the
to configure a weekly schedule. There are many ways you can approach configuration, the following procedure is only one way.
To configure a weekly schedule, do the following:
1. Double-click the weekly schedule component.
The Weekly Scheduler displays, as shown in Figure 4 on page 299.
2. Configure important properties. See “To configure a weekly schedule’s properties” on page 321.
4. Configure special events, if any. See
“To add and configure special events” on page 322.
5. Review all configuration. See “To review a weekly schedule’s configuration” on page 322.
To configure a weekly schedule’s properties
To configure a weekly schedule’s properties, do the following:
1. In the Weekly Scheduler view
tab, and configure the following:
•
— This is critical if an
EnumSchedule , and optional if a
Schedule . Note that facets do not apply if a StringSchedule .
•
— This is the schedule’s output whenever an event (either weekly or special event) is not active. It is also used whenever the component is “not effective.”
Typically, you leave other properties at default values.
.
To configure the weekly (normal) schedule
To configure the normal weekly schedule, do the following:
1. In the Weekly Scheduler view , click the Weekly Schedule
tab.
2. In the events table, click and drag to add an event, and enter its output value.
For details, see
“Event time “tuning”” on page 300 and “Output value” on page 300.
Note: If a Boolean or EnumSchedule, select output value from the drop-down control.
If a Numeric or StringSchedule, type the output value and press Enter.
3. Right-click the event and use whatever menus are needed.
For details, see
“Right-click menus” on page 301.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
321
Using schedules
Chapter 10 — About Scheduling
Configuring schedules and calendars
4. Continue to add, delete, or adjust events as needed.
5. When the weekly schedule is what you want, click
To add and configure special events
Special events are exceptions to the normal weekly schedule, and typically include recurring holidays
and “one-time” events. For more details, see “Schedule special events” on page 296.
To add and configure special events in a weekly schedule, do the following:
1. In the Weekly Scheduler view
, click the Special Events tab.
2. Click the Add button for a dialog to add a special event.
In the Add dialog, specify:
• Name — Type a unique, identifiable name.
• Type — Select the calendar type, and enter specific day criteria (according to type).
For details, see
“Adding special events” on page 302 and
“Calendar day selections” on page 312.
3. After naming, selecting the event type, and entering the selection criteria, click OK.
The special event is listed in the special events table, with your assigned name.
4. Click the special event to select it.
5. In the right-side events column, you can either:
• Click and drag to enter events that override (yet “intermingle” with) normal weekly events.
• Right-click and select an all-day event or default output value. This negates the normal weekly schedule.
For more details see
“Event times and output values” on page 303.
6. Continue to add, edit, rename, or delete special events as needed. See
“Right-click menus and other controls” on page 304, and “Special event priorities” on page 304.
7. When special events are like you want, click Save
.
To review a weekly schedule’s configuration
Use the read-only Summary tab to review a weekly schedule’s configuration.
To review the configuration of a weekly schedule, do the following:
1. In the Weekly Scheduler view
tab.
The calendar shows the current day with its schedule events, including output and output source.
2. Click any day on any calendar month to see its schedule events.
3. If adjustments are necessary, click the Weekly Schedule
needed, and make changes. Click Save
when done.
Configuring calendar schedules
Calendar schedules let you globally specify holidays and other special days in the system. For details,
see “About calendar schedules (holidays)” on page 309.
To configure a calendar schedule
You use the
to configure a CalendarSchedule.
To configure a calendar schedule, do the following:
1. Double-click the CalendarSchedule component.
The Calendar Scheduler displays, as shown in
322
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
Using schedules Configuring schedules and calendars
2. Click the Add button for a dialog to add a calendar event.
In the Add dialog, specify:
• Name — Type a unique, identifiable name.
• Type — Select the calendar type, and enter specific day criteria (according to type).
For details, see
“Calendar day selections” on page 312.
3. After naming, selecting the event type, and entering the selection criteria, click OK.
The calendar event is listed in the events table, with your assigned name.
4. Continue to add, edit, rename, or delete calendar events as needed. See
“Right-click menus and other controls” on page 311.
5. When calendar events are like you want, click Save
.
Configuring trigger schedules
Trigger schedules provide scheduling control for actions of linked components or their child extensions. For details, see
“About trigger schedules” on page 315.
To configure a trigger schedule
You use the
Trigger Scheduler view to configure a TriggerSchedule.
To configure a trigger schedule, do the following:
1. Double-click the TriggerSchedule component.
The Trigger Scheduler displays, as shown in Figure 31 on page 316.
This view has a calendar side (left) and time picker (right side).
2. Click the Add button for a dialog to add a trigger event.
In the Add dialog, specify:
• Name — Type a unique, identifiable name.
• Type — Select the calendar type, and enter specific day criteria (according to type).
For details, see
“Adding trigger events” on page 316 and
“Calendar day selections” on page 312.
3. After naming, selecting the event type, and entering the selection criteria, click OK.
The event is listed in the (calendar-side) events table, with your assigned name.
4. Click an event to select it.
5. In the right-side time picker area, add one or more triggers, as needed.
Note the following:
• By default, a “midnight” trigger may exist (
00h:00m
); you can delete it if needed.
• Using the
, you can add multiple triggers at some repeating interval.
• Triggers apply to all trigger events (calendar-side entries).
For more details see
“Adding trigger event times” on page 317.
6. Continue to add, edit, rename, or delete trigger events as needed. See
“Right-click menus and other controls” on page 318.
7. When trigger events and triggers are like you want, click Save
.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
323
Using schedules
Chapter 10 — About Scheduling
Linking schedules
Linking schedules
As needed, you link weekly schedules and (if used) trigger schedules to other components to provide scheduling control. For an overview, see
“Schedule component links” on page 295.
•
•
Linking weekly schedules
You can link the output (Out slot) of a weekly schedule to any component with a like “Status<Type>” input. For example, you might link the output of a
BooleanSchedule to a BooleanWritable point.
•
To link a weekly schedule using the wire sheet
•
To link a weekly schedule using the Nav tree
To link a weekly schedule using the wire sheet
To link a weekly schedule to a component in the same wire sheet, do the following:
1. In the wire sheet, mouse over the weekly schedule’s “Out” slot until highlighted.
2. Click and drag the link wire from the weekly schedule to the bottom of the target component, and release the mouse button.
A Link dialog appears. The source (left) side shows the schedule’s Out slot preselected.
3. In the target (right) side of the Link dialog, click on the desired slot of the target component.
Note: By convention, if linking to a priority array input of a writable point, “In16” is used for schedule level control. However, you can select any available level desired.
4. With both source and target sides selected in the Link dialog, click OK.
The target point or component is now linked to the weekly schedule.
To link a weekly schedule using the Nav tree
Often, a weekly schedule is in a different container than the target component. In this case, the easiest way to link is using the Nav tree.
To link a weekly schedule to a component using the Nav tree:
1. Expand the Nav tree to locate the source weekly schedule, noting its name.
2. Right-click the weekly schedule.
From the popup menu select Link Mark.
3. Expand the Nav tree to locate the target component.
4. Right-click the target component.
From the popup menu select Link From “<weekly schedule name>”.
A Link dialog appears.
5. In the source (left) side of the Link dialog, click the schedule’s “Out” slot.
6. In the target (right) side of the Link dialog, click the desired slot of the target component.
Note: By convention, if linking to a priority array input of a writable point, “In16” is used for schedule level control. However, you can select any available level desired.
7. With both source and target sides selected in the Link dialog, click OK.
The target point or component is now linked to the weekly schedule.
324
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 10 — About Scheduling
Using schedules Linking schedules
Linking trigger schedules
You can link the output (Trigger slot) of a TriggerSchedule to an action (or topic) of any component
(point or extension) with such a slot. For example, you might link a trigger schedule to the
“ResetChangeOfStateCount” action of a DiscreteTotalizerExt child of BooleanPoint.
Note: Often, you link trigger schedules to point extensions, not directly to a parent container point or component. In this case, before linking you could first composite the target container component, selecting to expose the extension’s action up in the parent point. Although optional, this
can help reusability and link clarity. For details, see “About composites” on page 83.
Note: Target actions or topics, unlike target property slots, can accept multiple link sources. In some cases, you may wish to link the “Trigger Missed” slot of the trigger schedule to the same target. For details, see
“Trigger Missed slot” on page 319.
You can use either of these methods to link trigger schedules:
•
To link a trigger schedule using the wire sheet
•
To link a trigger schedule using the Nav tree
To link a trigger schedule using the wire sheet
To link a trigger schedule to a component in the same wire sheet, do the following:
1. In the wire sheet, mouse over the trigger schedule’s “Trigger” slot until highlighted.
2. Click and drag the link wire from the trigger schedule to the bottom of the target component, and release the mouse button.
A Link dialog appears. The source (left) side has the trigger schedule’s Trigger slot preselected
3. In the target (right) side of the Link dialog, click on the desired slot of the target component.
4. With both source and target sides selected in the Link dialog, click OK.
The target component (point or extension) is now linked to the trigger schedule.
To link a trigger schedule using the Nav tree
Often, a trigger schedule is in a different container than the target component. In this case, the easiest way to link is using the Nav tree.
To link a trigger schedule to a component using the Nav tree:
1. Expand the Nav tree to locate the source trigger schedule, noting its name.
2. Right-click the trigger schedule.
From the popup menu select Link Mark.
3. Expand the Nav tree to locate the target component.
(In some cases, the target may be an extension of a point or other component.)
4. Right-click the target component.
From the popup menu select Link From “<target schedule name>”.
A Link dialog appears.
5. In the source (left) side of the Link dialog, click the trigger schedule’s “Trigger” slot.
6. In the target (right) side of the Link dialog, click the desired action of the target component.
7. With both source and target sides selected in the Link dialog, click OK.
The target component (point or extension) is now linked to the trigger schedule.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
325
Using schedules
Chapter 10 — About Scheduling
Importing schedules
Importing schedules
If the station is part of a multi-station NiagaraAX network, you can import NiagaraAX schedule com-
ponents between stations. You do this using the NiagaraAX Driver architecture
, specifically, views of the Schedules extension under a NiagaraStation (device-level) component.
If the Bacnet driver is used, you can also import BACnet Schedules and Calendars (as NiagaraAX schedule components) from a BACnet device. The same basic architecture and methods are used.
Note: Under a BacnetNetwork, you can also export NiagaraAX schedules to a specific BACnet device (to configure existing BACnet Schedules and Calendar objects).
For a brief overview, see
“Schedule exports and imports (master/slave)” on page 296. For more com-
plete details, see “About the Schedules extension” on page 120, and
“Station Schedules import/export notes” on page 163.
Importing NiagaraAX schedules or Bacnet Schedules
Often, you import a NiagaraAX schedule when working in a JACE station, where the source (master) schedule resides in a remote Supervisor station. BACnet Schedules and Calendars are also typically imported into a JACE station (unless a BACnet Supervisor).
To import a NiagaraAX schedule or BACnet Schedule or Calendar
To import a NiagaraAX schedule or BACnet Schedule or Calendar, do the following:
1. In the Nav tree, expand the Drivers folder of the station to receive the imported schedule.
2. Expand the network, either NiagaraNetwork or BacnetNetwork.
3. Expand the device that contains the source schedule (NiagaraStation or BacnetDevice).
In the Nav tree, the device’s children include: Points, Histories, Alarms, and Schedules.
4. Double-click Schedules.
The Niagara or Bacnet
Schedule Import Manager displays.
Any existing schedules (already imported) from this device are listed.
.
The manager view splits into two panes and a schedule discovery job is started. When complete, schedules available for import appear in the top pane.
6. In the top pane, click to select one or more schedules, then click Add
.
An Add dialog allows you to edit the name of the schedule (as it appears in this station) and sev-
eral other properties. See “Schedule Import properties” on page 144 for details.
7. After editing name and properties to suit, click OK.
NiagaraAX schedule components are created for the selected items, reside under that device’s
Schedules extension. You can link into station logic like any other schedules, but cannot configure these imported schedules (add, delete, or change events or other properties).
326
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 11 — Types of Workbench tools
Alarm portal
Types of Workbench tools
This section describes the standard tools available in Workbench. These tools represent Workbench interfaces that are designed to facilitate specific tasks – from managing credentials to monitoring alarms. All of the tools described in this section are available from the Tools menu.
•
Explains the options that appear in the alarm portal. Refer to
•
“Lexicon Installer” on page 21.
•
•
Explains the options that appear in the credentials manager. Refer to
“Credentials manager” on page 331.
•
Explains how to modify the the attributes of a new module. Refer to
“New module wizard” on page 332.
•
Explains the options in the new station wizard how to change the default attributes of a new station. Refer to
“New station wizard” on page 333.
•
Explains the options that appear in the license request dialog box. Refer to
“License request dialog box” on page 333.
•
Alarm portal
The alarm portal tool allows you to view and acknowledge alarms from many different stations using
a single viewer (portal). The alarm portal, shown in Figure 1 , is divided into two resizable panes,
above a set of buttons along the bottom of the alarm portal window:
From the Alarm Portal, double click on any alarm listed in the alarm sources pane to see the alarm
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
327
Alarm portal
Figure 1 Alarm portal
Chapter 11 — Types of Workbench tools
• Alarm Console Monitor
This pane displays information about the consoles that are being monitored and contains the following information areas:
• Title bar
Displays “Alarm Console Monitor” title on the left and the number of consoles that are connected to the alarm portal on the right side of the title bar.
• Column headings
Displays the title of each of the columns that are displayed in the alarm console monitor.
• Alarm console list
Each row in the alarm console listing contains information about alarm consoles that are currently listed as available to monitor from the alarm console. Station identity information is displayed, as well connection status (connected or disconnected) and connect and disconnect times.
• Open Alarm Sources
• Title bar
Displays “Open Alarm Sources” title on the left and the total number of points that are displayed in the list on the right side of the title bar.
• Column headings (click column heads to sort)
Displays the title of each of the columns in the open alarm sources list, as follows:
• Timestamp displays the latest time that the point generated an alarm.
• Source State displays the current state of the point (for example, Normal or Offnormal).
• Ack State displays how many alarms have been generated at the point and how many of those alarms have been acknowledged.
• Ack Required displays “true” or “false” indicating that an acknowledgement is or is not required for that alarm.
328
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 11 — Types of Workbench tools
Bacnet service
• Source displays the path to the point that is generating the alarm.
• Alarm portal buttons
• Acknowledge All
Acknowledges all alarms at the selected source when an alarm is selected in the alarm source pane.
• Hyperlink
• Notes displays a dialog box that allows you to add notes to an alarm record (see
“About the console recipient” on page 208 for more details about alarm record notes).
• Silence when clicked, this button quiets the alarm sound for the selected point.
• Filter
• Stop/Start/AutoStart provides starting and stopping options for the alarm portal.
Bacnet service
Figure 2 Bacnet service property sheet view
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
329
Lexicon editor
Chapter 11 — Types of Workbench tools
Lexicon Report
Lexicon editor
The lexicon editor tool provides two related views, as follows:
•
•
For general information on lexicons, see “About lexicons” on page 23. For details on installing
(edited) lexicons in remote JACE platforms, see the Platform Guide section “Lexicon Installer” .
Lexicon Report
When selecting the lexicon editor from the Tools menu, the default view is the “Lexicon Report,” as shown in
. The left side of this view lists all lexicons installed on your PC. As needed, you click a lexicon to select it.
Figure 3 Lexicon report
Selecting a lexicon in report view shows various status parameters about each lexicon file (by module) in columns on the right side. These status parameters include the following:
• module — The Niagara module translated by the lexicon file (moduleName.lexicon)
• module last modified — Timestamp of when the module lexicon was last modified
• missing — Number of keys that are missing values (from the lexicon for that module)
• lexicon last modified — Timestamp of when the lexicon was last modified
Note: Checkboxes at the top of report view allow you to “hide” values that could affect “missing” status counts, as follows:
• Hide Ref Values — If enabled, it filters reference-type entries starting with “/”, such as icons.
• Hide Accelerators — If enabled, it filters entries that define keyboard accelerators.
From this view you can also add (new) lexicons or delete unwanted lexicons. In addition, you can launch the
by clicking any module row, which shows that lexicon file.
330
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 11 — Types of Workbench tools
Lonworks service manager Lexicon Editor
Lexicon Editor
The lexicon editor lets you view and edit the contents of an individual lexicon file installed on your
Workbench PC. Typically, you access the editor from the Lexicon Report view with a lexicon
selected, by double-clicking a selected row on the right side.
Figure 4 Lexicon editor
A lexicon in the lexicon editor shows a table listing all defined keys for that module, with columns for mapping to a localized value, as follows:
• Key — Niagara interface entity, constant in that module from lexicon to lexicon
• Default — Default character value, used if no value is defined for that key (English equivalent).
• Value — Localized character value
Note: Checkboxes at the top of report view allow you to “hide” keys that may not require localization, as follows:
• Hide Ref Values — If enabled, it filters reference-type keys starting with “/”, such as icons.
• Hide Accelerators — If enabled, it filters keys that define keyboard accelerators.
As needed, you can resort columns to find information needed, and simply click any row to select that key. At the bottom of the editor, a Value edit field allows modifying (or adding) a value to the currently selected key.
Lonworks service manager
Credentials manager
The Manage Credentials tool, or “Credentials Manager” provides a dialog to access and open
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
331
New module wizard
Chapter 11 — Types of Workbench tools
Lexicon Editor any previously “remembered” (cached) connection from your Workbench, including both platform and station connections.
Figure 5 Manage Credentials dialog (credentials manager)
.
You can also remove or reset any cached credentials. Note that your credentials cache is populated whenever you have the login (Authentication) dialog option “Remember these credentials”
(checkbox) enabled, as shown in Figure 6
. For any initial platform or station connection, this option is enabled by default.
Figure 6 Authentication defaults (Remember credentials)
The default caching of credentials is a convienience feature, such that you can simply open the platform or station later by entering only the IP address, or simply clicking on that host’s ghosted platform or station in the Nav tree of Workbench, or going to the credentials manager. Then, the login authentication dialog (
) has the cached credentials already entered, and you simply click OK.
If you want tighter security for any platform or station connection from your Workbench PC, you should clear this checkbox whenever opening (logging on) a platform or station. Furthermore, you
should remove any related entries using the credentials manager ( Figure 5
). This way, that platform or station connection always requires full entry of both user name and password.
New module wizard
332
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 11 — Types of Workbench tools
New station wizard
New station wizard
License request dialog box
Workbench service manager
Lexicon Editor
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
333
New station wizard
Chapter 11 — Types of Workbench tools
Lexicon Editor
334
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Starting and exiting Workbench
Performing Workbench tasks
Workbench provides a complete user interface to the Niagara Framework. It can directly access a station and perform any action that the system supports. You can view and control any component using any of the supported views.
Common Workbench tasks include the following:
•
Starting and exiting Workbench
•
•
•
•
•
•
•
•
•
•
•
Starting and exiting Workbench
Tasks involved with starting and exiting Workbench, include the following:
•
•
•
•
To start Workbench
To start Workbench do one of the following:
• From the Windows Start menu, choose Programs > Niagara 3.0.xx > Work-
bench
.
The Workbench GUI will appear.
• From a console command line, type wb.
Note: If you use a DOS command line, instead of the Niagara command line, you must type the full path to the workbench directory.
To close a Workbench window
Note: Closing all Workbench windows will exit the Workbench GUI.
To close a Workbench window do one of the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
335
Chapter 12 — Performing Workbench tasks
Getting started with stations
• From the File menu, select the Close command.
The Workbench window will close.
• From the Niagara Workbench menu (located in the top left corner of the window title bar), select the Close command.
The Workbench window will close.
• Click the close icon (located in the top right corner of the window title bar).
The Workbench window will close.
To exit Workbench
You can exit Workbench by using the Exit command (which will close all Workbench windows) or by closing all Workbench windows.
To exit Workbench, do one of the following:
• From the File menu, select the Exit command.
The Workbench GUI will close.
• Close all Workbench windows.
The Workbench GUI will close when the final Workbench window is closed.
Getting started with stations
In order to communicate with a station, the station must be running and accessible. The following procedures provide information about basic tasks that are required to start, stop, and communicate with stations:
•
To open a platform using Workbench GUI
•
To connect to a platform using Workbench GUI
•
To close a platform using Workbench
•
To disconnect from a platform using Workbench
•
To start a station using Workbench
•
To stop a station using Workbench
•
•
To close a station using Workbench
•
To connect to a station using Workbench
•
To open a platform using Workbench GUI
To open a platform, do the following:
1. From the menu bar, select File > Open > Open Platform.
The Open Platform dialog box appears.
2. Complete the fields in the Open Platform dialog box as follows:
• Host
Select the IP or dialup option and type in the address of the computer that is running the platform that you wish to access.
• Port
Select the IP or dialup option and type in the address of the computer that is running the
336
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Getting started with stations platform that you wish to access.
• Password
Select the IP or dialup option and type in the address of the computer that is running the platform that you wish to access.
• Remember these credentials
Select the IP or dialup option and type in the address of the computer that is running the platform that you wish to access.
3. Click the OK button to accept all settings.
The platform opens with the Nav Container View displaying in the view pane.
To connect to a platform using Workbench GUI
Note: You cannot connect to a platform unless it is “open”. An open platform may be visible in your
Workbench nav side bar, but appear dimmed. If there is no platform icon in the nav side bar,
you need to open the platform before connecting (see “To open a platform using Workbench
To connect to a platform, do the following:
on the platform icon and select the Connect command from the popup menu.
The Authentication dialog box appears.
2. Enter the credentials information as follows:
Note: Be sure to use the correct platform username and password – not the credentials information for the station.
• Username
Enter the username for the platform.
• Password
Enter the password for the platform.
• Remember these credentials option
Select the “Remember these credentials” option if you want to have Workbench remember the platform username and password for this platform.
3. Click OK to accept all settings.
If the platform credentials were correct, the platform is connected, the platform icon appears in the side bar pane and the default Nav Container View appears in the view pane. If the platform credentials were not correct, you are prompted to enter them again.
To close a platform using Workbench
To close a platform, do the following:
on the platform icon and select the Close command from the popup menu.
The Close dialog box appears.
2. In the Close dialog box, click OK to close the platform.
The platform is closed and the platform icon is removed from the nav side bar.
To disconnect from a platform using Workbench
To disconnect from a platform, do the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
337
Chapter 12 — Performing Workbench tasks
Getting started with stations
on the platform icon and select the Disconnect command from the popup menu.
The Disconnect dialog box appears.
2. In the Disconnect dialog box, click OK to disconnect.
The platform is disconnected and the platform icon is dimmed.
To start a station using Workbench
Note: Most station–platform functions can be performed from the Station Director view of a platform, however, you must connect to the platform where a station is hosted before you can perform these tasks.
To start a station using Workbench, do the following:
1. Connect to the station’s platform (see
“To connect to a platform using Workbench GUI” on page 337 for details, if necessary).
2. In the nav side bar, expand the platform node in the nav tree by clicking on the plus sign (+) next to the platform icon in the tree.
The contents of the platform node displays in the tree.
3. In the nav side bar, double click on the station director icon.
The station director view appears in the view pane.
4. In the station director view, select the desired station.
The desired station is highlighted in the table region of the view pane.
5. In the station director view, select the following options, as desired:
• Select the Auto-Start option if you want the station to automatically start any time the station host computer is re–booted. Clear the Auto-Start option to disable auto–start.
• Select the Restart on Failure option if you want the station to automatically attempt a restart any time it fails. Clear the Restart option to disable automatic restart.
6. In the station director view, do one of the following:
• Select the desired station in the station table and click Start.
• Right click the desired station in the station table and select Start from the popup menu.
The station starts.
To stop a station using Workbench
Note: Most station–platform functions can be performed from the Station Director view of a platform, however, you must connect to the platform where a station is hosted before you can perform these tasks.
To stop a station using Workbench, do the following:
1. Connect to the station’s platform (see
“To connect to a platform using Workbench GUI” on page 337 for details, if necessary).
2. In the nav side bar, expand the platform node in the nav tree by clicking on the plus sign (+) next to the platform icon in the tree.
The contents of the platform node displays in the tree.
3. In the nav side bar, double click on the station director icon.
The station director view appears in the view pane.
4. In the station director view, select the desired station.
The desired station is highlighted in the table region of the view pane.
338
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Getting started with stations
5. In the station director view, do one of the following:
• With the desired station selected station table, click Stop.
• Right click the desired station and select Stop from the popup menu.
The station stops.
To open a station
To open a station, do the following:
1. From the File menu, select Open > Open Station (Fox)
The Open Station dialog box appears.
2. Enter the host and credentials information as follows:
Note: Be sure to use the correct station username and password – not the credentials information for the platform.
• Host [connection type]
Select the IP option if you are using an IP connection to connect to the station.
Select the dialup option if you are using a dialup connection to connect to the station.
• Host [ID]
Enter the Host ID (if necessary) or select it from the dropdown menu, if available.
• Port
Enter (or change, if necessary) the Port port number that you will use to connect.
• Username
Enter the username for the station.
• Password
Enter the password for the station.
• Remember these credentials option.
Select the “Remember these credentials” option if you want to have Workbench remember the station username and password.
3. Click OK to accept all settings.
If the station credentials were correct, then the station connects, the station icon appears in the side bar pane and the Nav Container View (or Station Summary View) appears in the view pane.
If the station credentials were not correct, you are prompted to enter them again.
To close a station using Workbench
To close a station, do the following:
on the station icon and select the Close command from the popup menu.
The Close dialog box appears.
2. In the Close dialog box, click OK to close the station.
The station is closed and the station icon is removed from the nav side bar.
To connect to a station using Workbench
To connect to a station, do the following:
Note: You cannot connect to a station unless it is “open”. An open station may be visible in your
Workbench nav side bar, but it appears dimmed. If there is no station icon in the nav side bar,
you need to open the station before connecting (see “To open a station” on page 339).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
339
Chapter 12 — Performing Workbench tasks
Using the side bar pane
To connect to a station, do the following:
on the station icon and select the Connect command from the popup menu.
The Authentication dialog box appears.
2. Enter the credentials information as follows:
Note: Be sure to use the correct station username and password – not the credentials information for the platform.
• Username
Enter the username for the station.
• Password
Enter the password for the station.
• Remember these credentials option
Select the “Remember these credentials” option if you want to have Workbench remember the station username and password for this station.
To disconnect from a station
To disconnect from a station, do the following:
on the station icon and select the Disconnect command from the popup menu.
The Disconnect dialog box appears.
2. In the Disconnect dialog box, click OK to disconnect.
The station is disconnected and the station icon is dimmed.
Using the side bar pane
The side bar pane displays all open side bars. The pane may be shown or hidden by selecting a command from the Windows menu, as described in
“To open the side bar pane” on page 340.
Following, are some facts about the behavior of side bars and the side bar pane:
• If you open a side bar, the side bar pane (if currently closed) will automatically open to display that pane.
• When you open Workbench, the side bar pane returns to its last previous state (displayed or hidden).
• When you show the side bar after all side bar panes have been closed (causing the side bar pane to hide) the side bar pane will be empty
• When you close all side bars, the side bar pane will close
• When you open Workbench, it will display the side bars that were open (if any) when the last session was closed.
• When more than one side bar is open in the side bar pane, side bars may be resized vertically, maximized, or restored to their previous size using the title bar controls.
• Side bars always expand to fill the side bar pane horizontally.
To open the side bar pane
To open the side bar pane, do the following:
340
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using the side bar pane
• From the menu bar, select Window > Side Bars > Show Side Bar command.
The side bar will appear.
To open the bookmarks side bar
To open the bookmarks side bar, do the following:
• From the menu bar, select Window > Side Bars > Bookmarks.
The bookmarks side bar appears in the side bar pane.
To open the help side bar
To open the help side bar, do the following:
• From the menu bar, select Window > Side Bars > Help.
The help side bar appears in the side bar pane.
To open the nav side bar
To open the nav side bar, do the following:
• From the menu bar, select Window > Side Bars > Nav.
The nav side bar appears in the side bar pane.
To open the palette side bar
To open the palette side bar, do the following:
• From the menu bar, select Window > Side Bars > Palette.
The palette side bar appears in the side bar pane.
To close a side bar
To close the side bar pane, do the following:
• From the side bar title bar dropdown menu (left side), select the Close command.
The side bar pane closes.
To close the side bar pane
The side bar pane toggles on or off by selecting or deselecting the Show Side Bar command, as described below. The side bar pane also closes when all palettes are closed.
To close the side bar pane, do the following:
• From the menu bar, select Window > Side Bars > Show Side Bar.
The side bar pane closes.
To vertically resize a side bar
To vertically resize a side bar, do the following:
• Click on the title bar and drag vertically.
The side bar will adjust to any size that fits in the side bar pane.
To restore a side bar to a previous size
To restore a side bar to it’s previous size, do the following:
• Click on the restore icon on the title bar.
The side bar will change to its previous state.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
341
Chapter 12 — Performing Workbench tasks
Using bookmarks
To maximize a side bar:
To maximize a side bar, do the following:
• Click on the restore icon on the title bar.
The side bar will expand to its maximum size in the side bar pane.
Using bookmarks
Bookmarks are simply linked “shortcuts” or “favorites” to help you quickly find views in just a couple of clicks. The bookmark side bar provides a convenient place in the side bar pane to add, manage, edit, and remove bookmarks. You can also do these “bookmarking” tasks using the Bookmarks menu on the menu bar. For an overview of the bookmark side bar, see
“About the bookmark side bar” on page 28.
This section describes the following tasks that are associated with the bookmark feature:
•
•
•
•
To add a bookmark
To add a bookmark, do the following steps:
1. Make sure that the view you want to bookmark is showing in the view pane, and then do one of the following:
• From the menu bar, select Bookmarks: Add to Bookmarks.
• From the popup menu in the palette side bar, select Add to Bookmarks.
2. In the Add to Bookmarks dialog box, type a name for the bookmark, in the Name field.
3. Optional: In the Add to Bookmarks dialog box, click the New Folder button to add a new folder, if desired.
The New Folder dialog box appears. There you can name your new folder and click OK to save it.
4. In the Add to Bookmarks dialog box, select the folder where you want to locate the bookmark and click OK.
The bookmark is added.
To manage bookmarks
To manage your bookmarks, do the following steps:
1. Do one of the following:
• From the menu bar, select Bookmarks: Manage Bookmarks.
• From the popup menu in the palette side bar, select Manage Bookmarks.
2. In the Manage Bookmarks dialog box, click on one of the following buttons:
•
New Folder
buttons
To create new folders to organize your bookmarks
•
New Bookmark
button
To create new bookmarks
342
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using the help side bar
•
Copy to
button
To copy bookmarks to another location
•
Move to
button
To move bookmarks to another location
•
Remove
button
To delete the selected bookmark
•
Edit
button
To rename a selected bookmark
•
Move Up
or Move Down button
To move bookmarks up or down in the bookmark tree view
To edit a bookmark
To edit a bookmark, do the following steps:
1. In the bookmarks side bar, right-click the bookmark that you want to change and select Edit from the popup menu.
The bookmark Edit dialog box will appear.
2. In the Edit dialog box, type the desired name for your bookmark in the Name field.
3. In the Edit dialog box, type the ORD path or scroll Name field.
To remove a bookmark
To remove a bookmark, do the following:
• In the bookmarks side bar, right-click the bookmark that you want to change and select Remove from the popup menu.
The bookmark is deleted from the bookmark list.
Using the help side bar
When you open the help side bar for the first time, the help side bar is empty except for the Load
Help
button. The Load Help button will reappear any time any module's timestamp is changed or when a new module is added or removed. When you click the Load Help button, Workbench searches through all the available modules to create the help directory. The Help Sidebar provides a view of the available Help.
To search for topics in the help side bar:
After you enter one or more words in the Find window, pressing the Search button creates a list of documents that contain one or more occurrences of the words you have entered. The results show those document's containing any of the words, not all of the words. The ranking order is based on how many times any of the words appear in a given document.
To search for topics in the help side bar, do the following steps:
1. In help side bar, click on the Search tab. The search display appears.
2. In the Find field, type the word or phrase that you are looking for and click the Search button.
Topics that match your search word(s) will appear in side bar below the text field.
3. Double-click on a topic to display the topic in the view pane.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
343
Chapter 12 — Performing Workbench tasks
Using the nav side bar (tree)
Using the nav side bar (tree)
The nav side bar provides a hierarchical view of the system in a nav—tree presentation. Components that appear in the tree may be acted on in various ways depending the component type:
The following sections describe how to use Nav side bar actions and the following procedures:
•
To refresh a nav side bar tree node
•
To refresh a nav side bar tree node
Nav side bar actions
• Expand
Click the plus sign next to an icon to expand a branch of the tree and show any child nodes.
• Collapse
Click the minus sign next to an icon to collapse a branch of the tree.
• Select
Click a node in the tree to select it.
• View
Double—click the minus sign next to an icon to collapse a branch of the tree and hide its child nodes.
• Use popup menu
• Use file menu
To refresh a nav side bar tree node
Refreshing a nav side bar tree node, updates the view to reflect any changes to the files of that node.
To refresh a nav side bar tree node, do the following steps:
1. Click the node to select it.
2. Do one of the following:
• From the File menu, select Refresh.
The tree node refreshes.
• From the popup menu, select Refresh Tree Node.
The tree node refreshes.
To Go Into a nav side bar tree node
The Go Into command allows you to re-root the nav tree at any arbitrary node. This will make that node the new root of the tree and give you a new tree in the nav side bar window. You can get back to the original tree by selecting it from the All the nodes you have "gone into" are persistently saved as a special type of Bookmark. Use the pulldown to switch between them. This feature is quite handy when working with multiple Stations or deep File systems and Databases.
To refresh a nav side bar tree node, do the following steps:
1. Click the node to select it.
2. Do one of the following:
344
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
• From the File menu, select Refresh.
The tree node refreshes.
• From the popup menu, select Refresh Tree Node.
The tree node refreshes.
Using the jobs side bar
Using the jobs side bar
The Jobs side bar provides a place to view and manage current jobs. Once a job has completed you are notified via the async notification feature. You can also view job details using the ">>" button.
This section explains how to do the following:
•
•
To cancel a job from the jobs side bar
•
To view job details
To view job details from the jobs side bar, do the following:
• On the desired job, click the details (">>") button.
The job log details dialog box appears.
To cancel a job from the jobs side bar
To cancel a job from the jobs side bar, do the following:
• On the jobs side bar, click the cancel button.
The job is cancelled.
To dismiss a job
Once a job has been completed, you are notified via the async notification feature. You may then dismiss the job from the jobs side bar, if desired.
To dismiss a job, do the following:
• From the Jobs side bar click the close button on the job that you want to dismiss.
The selected job is closed.
Using the palette side bar
The palette side bar provides a place to open, view, and access sets of modules. For an overview of
the palette side bar, see “About the palette side bar” on page 33.
This section explains how to do the following:
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
345
Chapter 12 — Performing Workbench tasks
Using the view pane
To open a palette
You can open palettes in the palette side bar. Refer to
“To open the palette side bar” on page 341 for
details on how to open the palette side bar.
To open a new palette in the palette side bar, follow these steps:
1. On the palette toolbar click the open palette button.
The Open Palette dialog box appears.
2. In the Open Palette dialog box select one or more palettes from the list, as desired.
Note: Hold down the
Ctrl
or
Shift
key to make multiple selections.
3. Click OK.
The new palette opens in the side bar pane.
To close a palette
You can close any of the palettes that are open in the palette side bar. When you close all the palettes, the palette side bar will close.
To close a palette, follow these steps:
1. From the Drop-down palette selector, choose the palette that you want to close.
The selected palette displays in the side bar pane.
2. Click the Close palette button.
The palette closes.
Using the view pane
The view pane can display any component view that you choose (see
an introduction to views). Different views of components can provide different editing options. Most component editing is done in the view pane, however, many editing functions also involve the nav tree pane as well. The following sections describe some of the basic tools provided in Workbench for editing components. These tools are context–sensitive and may be used in several – but not all – views and with several – but not all – types of components.
For more details about viewing components, refer to “Viewing a component” on page 347
Editing components
Editing components in Workbench typically involves:
•
•
•
The following sections describe these tasks.
346
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Editing components
Selecting a component
By selecting an item, you are defining the scope of your actions. In other words, the only components that are directly affected by your edits are those that are “selected” during your edits. Of course, other components may be influenced by the change in a component that communicates with it. It is also important to remember the hierarchical nature of the component tree. If you delete or move a component that contains other components, then you are deleting or moving all items that are contained in that container component.
When items are selected, they appear in one of the following ways:
• In the nav tree view, the component text is changed to a white on purple highlight.
• In the wire sheet view, selected components have a red border with red handles.
• In the wire sheet view, selected links turn red.
For more information about views, refer to
To select a component
To select a component, do one of the following:
• In the nav tree view or the wire sheet view, left–click the desired component.
The component is selected.
• In the nav tree view or the wire sheet view, right-click the desired component.
The component (or link) is selected.
• In the wire sheet view, drag around the desired component.
The component (or link) is selected.
To select multiple components in the nav tree
To select more than one component in the nav tree do the following:
1. Select a single component or link, as described in
2. Hold down the
Shift
key or
Ctrl
key and select additional items.
Multiple components (or links) are selected.
3. Optional: In the wire sheet view, drag around the group of elements that you want to select. Hold down the
Shift
key or
Ctrl
key and select additional items to select or deselect them.
Multiple components (or links) are selected.
To select a multiple components in the wire sheet
To select more than one component in the wire sheet do the following:
1. Select a single component or link, as described in
2. Hold down the
Shift
key or
Ctrl
key and select additional items.
Multiple components (or links) are selected.
Viewing a component
Each component that you select (in a view or in the nav tree) has a “default” view that appears in the view pane. You can select a different view of the component using the view selector or the popup
(right–click) menu. The last view of an object becomes its default view during a Workbench session.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
347
Chapter 12 — Performing Workbench tasks
Editing components
If Workbench is closed and restarted, default views are reset to the original default views.
For details on selecting component views, see
“To select a component view” on page 348.
In addition to having different views, you can edit the way views display information. For details about customizing a view, refer to the following procedures:
“To reorder components (in a component container)” on page 348
“To create a composite view” on page 348
To select a component view
To select a component view, do one of the following:
• Double-click on a component in the nav side bar.
This will display the default view of the component.
• Right–click a component and choose a view from the Views submenu.
• With a component selected, choose a view from the view selector menu
To reorder components (in a component container)
You can reorder the components that are contained in a “container” component using the property sheet view, the nav tree view, or the wire sheet view.
To reorder components, do the following:
1. Right–click the desired component.
The popup menu appears.
2. From the popup menu, select Reorder.
The Reorder dialog box appears.
3. In the Reorder dialog box, use the sort buttons, as follows:
•
Move Up
button
Select one or more items in the component list (use the
Ctrl
or
Shift
key to select multiples) and click this button to move selected item(s) up (one position per click) in the list.
•
Move Down
button
Select one or more items in the component list (use the
Ctrl
or
Shift
key to select multiples) and click this button to move selected item(s) down (one position per click) in the list.
•
Sort by Name
button
Click this button to sort all items in the list in alphabetical order, by name. Each click toggles the sort order between ascending and descending sort order.
•
Sort by Type
button
Click this button to sort all items in the list in order by component type. Each click toggles the sort order between ascending and descending sort order.
•
Reset
button
Click this button to set the components in the list back to the order that they were in when the
Reorder dialog box was opened.
The components are sorted according to button selected.
To create a composite view
Composite views are available in the wire sheet view and in the property sheet view. Creating a composite view of a component allows you to expose one or more child slots (that you designate) at the parent–view level. For more information about composite views, refer to
348
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Editing components
To create a composite view, do the following:
Note: The component that you select in the following step must have a child component to be a legitimate parent component. If no valid child component is available, then there cannot be a composite.
1. In the wire sheet view or in the property sheet view, right–click on the desired parent object.
appears.
The popup menu appears.
2. From the popup menu, select the Composite command.
The Composite Editor appears.
3. In the Composite Editor, expand the tree to find and select the desired points to add to the parent component. Select multiple points (if desired) by holding the
Ctrl
or
Shift
keys when selecting.
4. With the desired point(s) selected, click the Add button to add one or more points to the right column of the Composite Editor.
5. Optional: Use the Composite Editor control buttons to do the following, if desired:
• Reverse
Reverse the chosen side (“in” or “out”) of a point that is being composited.
• Rename
Provide a custom name for the new slot created by composited point.
• Remove
Removes the composited item (slot) from right side of the Composite Editor.
• Move Up
Sort all selected points by moving them up in the Composite Editor (list (one position per click).
• Move Down
Sort all selected points by moving them down in the Composite Editor list (one position per click).
6. Click the OK button.
The component composites are set.
Editing component data
Many component editing functions in Workbench work the same, or similarly, in all component views. However, some editing functions are restricted to particular component views. For information about the standard edit commands (such as cut, copy, and paste, refer to
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
349
Chapter 12 — Performing Workbench tasks
Editing components
To add a new component (property sheet, nav side bar, or wire sheet view)
You can add (create) a new component to a container using the property sheet view, the nav tree view or the wire sheet view. To add a component using the slot sheet view, refer to To add a slot refer to
“To add a new slot” on page 354.
To add a new component, do the following:
1. Right–click in the container where you want to place the new component. This can be a component in the nav tree view, the wire sheet view or the property sheet view.
A popup menu appears.
2. From the popup menu, choose the New command and select the desired type of component:
•
Folder
•
IconFolder
•
TextBlock
•
Boolean
Writable
•
Numeric
Writable
•
Enum
Writable
•
StringWritable
The Name dialog box appears.
3. Type the desired name for the new component in the text field and click the OK button.
The new component appears in the property sheet.
To delete a component (property sheet, nav side bar, or wire sheet view)
You can delete a component from a container, using the property sheet view, the nav tree view or the wire sheet view. To delete a component using the slot sheet view, refer to To delete a slot refer to
“To delete a slot” on page 355.
To delete a component, do the following:
Note: If you delete a component that contains other components, all components in that container component are deleted as well.
1. Right–click the desired component.
A popup menu appears.
2. From the popup menu, select the Delete command.
The component is deleted.
To rename a component (property sheet, nav side bar, or wire sheet view, slot sheet)
You can rename a component in the property sheet view, the nav tree view, the wire sheet view, or the slot sheet view.
To rename a component, do of the following:
1. In the desired view, right–click the component to rename.
The popup menu appears.
2. From the popup menu, select the Rename command.
The Rename dialog box appears.
3. In the Rename dialog box, type the desired name in the text field and click the OK button.
The component is renamed.
350
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Editing components
To duplicate a component (property sheet, nav side bar, or wire sheet view)
You can duplicate a component from the property sheet view, the nav tree view, or the wire sheet view.
To duplicate a component, do of the following:
1. In the desired view, right–click the component to duplicate.
The popup menu appears.
2. From the popup menu, select the Duplicate command.
The Name dialog box appears.
3. In the Name dialog box, type the desired name in the text field (or use the default name) and click the OK button.
The component is duplicated.
To paste a component (property sheet, nav side bar, or wire sheet view)
You can add a component to a container by pasting it to a container displayed the property sheet view, the nav tree view, or the wire sheet view.
To add a component by pasting it, do the following:‘
1. In the desired view, select the desired component and use the Copy (to duplicate) or Cut (to remove) command to copy the component to the clipboard.
Copy
and Cut commands are available on the popup (right–click) menu, the Edit menu, or from the toolbar.
2. Right–click in the container where you want to place the new component. This can be a component in the nav tree view, the wire sheet view or the property sheet view.
The popup menu appears.
3. From the popup menu, select the paste command.
The Name dialog box appears.
4. Type the desired name for the new component in the text field and click the OK button.
The new component is added to the targeted container.
To drag a component to the property sheet, nav side bar, or wire sheet (left–click method)
You can drag a component to the displayed property sheet view, the nav tree view, or the wire sheet view, by using a right–click drag or by using a normal, left–click drag.
Note: A left–click drag always creates a copy of the original.
To drag a component using the left–click drag method, do the following:
1. In the desired view, left–click the component to copy and drag it to the target container.
When you release the mouse button, the Name dialog box appears.
2. Type the desired name for the new component in the text field and click the OK button.
The new component is added to the targeted container.
To drag a component to the property sheet, nav side bar, or wire sheet (right–click method)
You can drag a component to the displayed property sheet by using a right–click drag or by using a normal, left–click drag.
Note: A right–click drag always prompts you to choose a copy, move, or cancel command.
To drag a component to a property sheet by using the right–click drag method, do the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
351
Chapter 12 — Performing Workbench tasks
Editing components
1. In the desired view, right–click the component that you want to move (or copy) and drag it to the property sheet.
When you release the right mouse button, a popup menu appears.
2. From the popup menu, choose one of the following commands:
•
Copy
– this command makes a duplicate of the component to paste onto the property sheet.
The Name dialog box appears.
•
Move
– this command removes the original component and prepares to paste in onto the property sheet.
The Name dialog box appears.
•
Cancel
– this command will stop the process, and the popup menu will disappear.
3. Type the desired name for the new component in the text field and click the OK button.
The new component appears in the property sheet.
Using the property sheet
The property sheet view is displayed in the view pane by selecting Property Sheet from the
view selector
menu (see
“About the view selector” on page 40) or by using one of the other
methods described in “About the view pane” on page 36.
For information about creating new components, deleting components, duplicating components, and
so on, refer to “Editing components” on page 346.
To add an extension to a component property sheet view:
For more information about extensions, refer to
“Extension process overview” on page 62 or “About point extensions” on page 62
Note: The following procedure may also be performed directly in the nav side bar tree (refer to
“Using the nav side bar (tree)” on page 344) for more information.
1. Display the component property sheet view, as follows:
• In the nav pane tree, select the desired component.
• From the right–click popup menu (or from the view selector), select the component property sheet view.
2. Open the desired extensions palette from the palette side bar.
3. Expand the extensions folder to find the extension that matches your data type and collection method.
4. Drag and drop or copy and paste the extension onto the bottom of the properties sheet.
The extension is added. Refer to “Configure history extensions” on page 185
To add a component facet:
For more information about facets, refer to
“About point facets” on page 58.
1. In the property sheet view of a component, click the Edit Facet (>>) button.
The Edit Facets dialog box appears.
2. In the Edit Facets dialog box, click the Add button.
The Add... dialog box appears.
3. From the Key: options menu, select a parameter. Duplicates are not allowed.
352
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Editing components
4. From the Type: options menu, select a parameter.
5. Click the OK button.
The Add... dialog box closes and the Edit Facets dialog box displays the new information.
6. From the Edit Facets dialog box, click the OK button.
The new facet is added.
7. In the property sheet, click the Save button to your save changes.
To remove a component facet:
For more information about facets, refer to
“About point facets” on page 58.
1. In the property sheet view of a component, click the Edit Facet (>>) button.
The Edit Facets dialog box appears.
2. In the Edit Facets dialog box, click the Remove button.
The Remove... dialog box appears.
3. From the Remove... dialog box, choose a parameter(s) that you want to delete by selecting the associated check box(es).
4. Click the OK button.
The Edit Facets dialog box disappears and deleted parameter information does not appear.
5. From the Edit Facets dialog box, click the OK.
The new facet is removed.
6. In the property sheet, click the Save button to save changes.
Using the wire sheet
Using the wire sheet
To pin a slot
By default, some slots are visible in the wire sheet view of the slot. However, you can have any – or all slots visible on the wire sheet by “pinning” open the slot(s).
To pin a slot:
1. In the wire sheet view, right–click on the desired component.
The popup menu appears.
2. From the popup menu, select the Pin Slots command.
The Pin Slots dialog box appears.
3. In the Pin Slots dialog box, click to the left of all slots that you want to pin open.
A pin icon appears next to each icon you click.
4. Click the OK button.
The slots are pinned and appear on the wire sheet with a knob next to the slot name.
To paste a component onto the wire sheet
You can add a component to the displayed property sheet by pasting it onto the property sheet or by dragging it onto the property sheet.
To add a component to a property sheet by pasting it to the property sheet, do the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
353
Chapter 12 — Performing Workbench tasks
Editing components
1. Select the desired component and use the Copy (to duplicate) or Cut (to remove) command to copy the component to the clipboard.
Copy
and Cut commands are available on the popup (right–click) menu, the Edit menu, or from the toolbar.
2. Right–click on the property sheet.
The popup menu appears.
3. From the popup menu, select the paste command.
The Name dialog box appears.
4. Type the desired name for the new component in the text field and click the OK button.
The new component appears in the property sheet.
To drag a component to the wire sheet (left–click method)
You can drag a component to the displayed property sheet by using a right–click drag or by using a normal, left–click drag.
To drag a component to a property sheet by using the left–click drag method, do the following:
1. Select the desired component using a left–click and drag it to the property sheet.
When you release the mouse button, the Name dialog box appears.
2. Type the desired name for the new component in the text field and click the OK button.
The new component appears in the property sheet.
To drag a component to the wire sheet (right–click method)
You can drag a component to the displayed property sheet by using a right–click drag or by using a normal, left–click drag.
To drag a component to a property sheet by using the right–click drag method, do the following:
1. Right–click the desired component and drag it to the property sheet.
When you release the right mouse button, a popup menu appears.
2. From the popup menu, choose one of the following commands:
•
Copy
– this command makes a duplicate of the component to paste onto the property sheet.
The Name dialog box appears.
•
Move
– this command removes the original component and prepares to paste in onto the property sheet.
The Name dialog box appears.
•
Cancel
– this command will stop the process, and the popup menu will disappear.
3. Type the desired name for the new component in the text field and click the OK button.
The new component appears in the property sheet.
Using the slot sheet
To add a new slot
To add a new slot, perform the following steps:
1. In the slot sheet view, right–click in the pane.
The popup menu appears.
2. From the popup menu, select the Add Slot command.
354
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
The Add Slot dialog box appears.
3. In the Add Slot dialog box, enter the following information:
• Name: type in a name for the slot.
• Type: Select the component property type from the drop-down option lists.
• Choose the desired slot options from the Flags field.
4. Click the OK button.
The slot is added to the slot sheet.
To delete a slot
To delete a slot, perform the following steps:
1. In the slot sheet view, right–click on the slot that you want to delete.
The popup menu appears.
2. From the popup menu, select the Delete command.
The slot is deleted.
Editing components
Using the link sheet
The following are common tasks associated with the link sheet
•
To delete a link using the link sheet view
•
To edit a link using the link sheet view
To delete a link using the link sheet view
To delete a link using the link sheet view, perform the following steps:
1. In the link sheet view, right–click on the link that you want to delete.
The popup menu appears.
2. From the popup menu, select the Delete command.
The link is deleted.
To edit a link using the link sheet view
To edit a link using the link sheet view, perform the following steps:
1. In the link sheet view, right–click on the link that you want to delete.
The popup menu appears.
2. From the popup menu, select the Edit command.
The edit dialog box appears.
3. In the edit dialog box, edit the following fields, as desired
• Source Ord
Type in (or browse to) the ORD for the desire source of the link.
• Source Slot Name
Type in a name for the Source.
• Target Slot Name
Type in a name for the Target Slot
• Enabled
Choose True of False from the Enable option list. True enables the link and False disables the link.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
355
Using alarms
4. In the edit dialog box, click the OK button.
The edit dialog box disappears and the edits are saved.
Chapter 12 — Performing Workbench tasks
Using alarms
The following are common tasks associated with setting up and working with alarms in NiagaraAX:
•
•
•
Creating alarms
To create an “alarmable” control point, you must add an appropriate alarm extension to a control point and configure it to define your alarm condition requirements:
To set up alarm conditions for a control point
Note: Just as there are different types of control points (refer to
proper type of extension to match the point, as described in
“Types of alarm extensions” on page 66.
To set up alarm conditions for a control point, do the following:
point type (for example, BooleanChanegOfStateAlarmExt fits with a Boolean Writable point – and a EnumChangeOfStateAlarmExt would not).
Note: The Alarm Enable property options are not selected by default. You must select an
AlarmEnable option in addition to setting your alarm extension properties.
Routing alarms
The alarm service handles the routing of alarms by using alarm classes to coordinate the transfer of messages between alarm sources and alarm recipients. Refer to
“Types of alarm recipients” on page 208 for more information about alarm recipients.
To add an alarm class to the alarm service
For more information about alarm service, refer to “About the alarm service” on page 196. For more
356
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using alarms
information about alarm class, refer to “About alarm class” on page 204.
To add an alarm class to the alarm service, do the following:
1. Right–click the AlarmService node in the nav side bar.
The popup menu appears.
2. From the popup menu, select Views > WireSheet.
The alarm service Wire Sheet view appears.
3. From the alarm palette, drag an AlarmClass component onto the wiresheet.
The Name dialog box appears.
4. Type the desired name for the new alarm class in the text field and click the OK button.
The new alarm class appears in the wiresheet and is ready for configuration.
To add a console recipient to the alarm service
For more information about alarm service, refer to “About the alarm service” on page 196. For more
information about console recipient, refer to “About the console recipient” on page 208.
To add a console recipient to the alarm service, do the following:
1. Right–click the AlarmService node in the nav side bar.
The popup menu appears.
2. From the popup menu, select Views > WireSheet.
The alarm service Wiresheet view appears.
3. From the alarm palette, drag a ConsoleRecipient component onto the wiresheet.
The Name dialog box appears.
4. Type the desired name for the new console recipient in the text field and click the OK button.
The new console recipient appears in the wiresheet and is ready for configuration.
To add a station recipient to the alarm service
For more information about alarm service, refer to “About the alarm service” on page 196. For more
information about station recipient, refer to “About the station recipient” on page 211.
To add a station recipient to the alarm service, do the following:
1. Right–click the AlarmService node in the nav side bar.
The popup menu appears.
2. From the popup menu, select Views > WireSheet.
The alarm service Wiresheet view appears.
3. From the alarm palette, drag a StationRecipient component onto the wiresheet.
The Name dialog box appears.
4. Type the desired name for the new station recipient in the text field and click the OK button.
The new station recipient appears in the wiresheet and is ready for configuration.
To add an email recipient to the alarm service
For more information about alarm service, refer to “About the alarm service” on page 196. For more
information about email recipient, refer to “About the email recipient” on page 212.
To add an email recipient to the alarm service, do the following:
1. Right–click the AlarmService node in the nav side bar.
The popup menu appears.
2. From the popup menu, select Views > WireSheet.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
357
Chapter 12 — Performing Workbench tasks
Using alarms
The alarm service Wiresheet view appears.
3. From the email palette, drag an EmailRecipient component onto the wiresheet.
The Name dialog box appears.
4. Type the desired name for the new email recipient in the text field and click the OK button.
The new email recipient appears in the wiresheet and is ready for configuration.
Managing alarms
To acknowledge alarms from the alarm console view
Note: Alarms are not removed from the alarm console until both the following conditions exist:
• alarm acknowledged
• alarm source is in a normal (not alarm) state
You can acknowledge alarms from the alarm portal as well as from the alarm console. To acknowl-
To acknowledge alarms from the alarm console view, do the following:
1. Right–click on the ConsoleRecipient node in nav side bar pane.
The popup menu displays.
2. From the popup menu, select Views > Alarm Console.
The alarm console view appears with all alarm sources displayed in a tabular view.
3. In the alarm console view, select alarm sources that you want to acknowledge. Select multiple alarms, if desired, using the
Shift
or
Ctrl
key.
Note: Each record that appears in the alarm console table represents one alarm source and one or more alarms from that source. You may acknowledge either the latest (most recent) alarm or acknowledge all alarms that are reported from that source by choosing either the
“Acknowledge” command or the “Acknowledge All” command, as described in the following step.
4. Acknowledge selected alarm(s) by doing one of the following:
• From the Alarm menu, select Acknowledge (to acknowledge the latest alarm only)
The latest alarm from each selected choice is acknowledged.
OR
• From the Alarm menu, select Acknowledge All (to acknowledge all alarms reported from that source). Alternatively, you may click the Acknowledge All button (located at the bottom of the dialog box).
All alarms from each selected alarm source are acknowledged.
To acknowledge alarms from the alarm portal
The alarm portal must be running and configured to include all desired alarm consoles before it can be used to acknowledge alarms. Refer to
“Alarm portal” on page 327 for details about the alarm por-
tal. Refer to
“Alarm portal options” on page 47 for details about alarm portal display options.
Note: Alarms are not removed from the alarm console (or portal) until both the following conditions exist:
358
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using alarms
• alarm acknowledged
• alarm source is in a normal (not alarm) state
You can acknowledge alarms from the alarm console as well as from the alarm portal. To acknowl-
To acknowledge alarms from the alarm portal, do the following:
1. From the Tools menu, select Alarm Portal.
The Alarm Portal view displays in the view pane.
2. If the desired Alarm Console does not appear in the Alarm Console Monitor table (top portion of the Alarm Portal view) right–click in the Alarm Console Monitor area.
The popup menu, appears.
3. Select Add Alarm Console.
The Add Alarm Console wizard appears.
4. Complete the Add Alarm Console wizard by entering the following information:
• Host address information, as needed (IP or dialup)
• Credentials information (username and password)
• Choose the desired console, by Ord (if more than one is present at the host address)
5. Click the Finish button to complete the Add Alarm Console wizard.
The alarm console appears in the Alarm Console Monitor table (top portion of the Alarm
Portal view). Any alarms will appear in the Open Alarm Sources table (bottom portion of the Alarm Portal view).
6. In the Open Alarm Sources table, select alarm sources that you want to acknowledge. Select multiple alarms, if desired, using the
Shift
or
Ctrl
key.
Note: Each record that appears in the Open Alarm Sources table represents one alarm source and one or more alarms from that source. You may acknowledge either the latest
(most recent) alarm or acknowledge all alarms that are reported from that source by choosing either the “Acknowledge” command or the “Acknowledge All” command, as described in the following step.
7. Acknowledge selected alarm(s) by doing one of the following:
• From the Alarm menu, select Acknowledge (to acknowledge the latest alarm only)
The latest alarm from each selected choice is acknowledged.
OR
• From the Alarm menu, select Acknowledge All (to acknowledge all alarms reported from that source). Alternatively, you may click the Acknowledge All button (located at the bottom of the dialog box) or use the popup menu to acknowledge the alarm(s).
All alarms from each selected alarm source are acknowledged.
To delete old alarm records
Note: Just as there are different types of control points (refer to
proper type of extension to match the point, as described in
“Types of alarm extensions” on page 66.
To set up alarm conditions for a control point, do the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
359
Chapter 12 — Performing Workbench tasks
Using the Px Editor
point type (for example, BooleanChanegOfStateAlarmExt fits with a Boolean Writable point – and a EnumChangeOfStateAlarmExt would not).
Note: The Alarm Enable property options are not selected by default. You must select an
AlarmEnable option in addition to setting your alarm extension properties.
Using the Px Editor
The following are common tasks associated with setting up and working with the Px Editor in NiagaraAX:
•
•
•
•
Making widgets
It is possible to make new widgets in several ways:
To make a new widget using the Make New Widget wizard:
Note: For more information about the Make Widget wizard, see the following:
•
• For examples of procedures using the Make Widget Wizard interface, with different types of bindings, refer to
“Make Widget wizard: examples” on page 244.
When you create a widget with the Make Widget Wizard, the wizard dialog box provides fields for creating the widget bindings. To make a new widget using the Make New Widget wizard, do the following:
1. From the nav side bar, drag and drop a widget onto the Px Editor canvas.
The Make Widget Editor appears, with the ORD for the selected component displaying in the
ORD area. You can double-click the ORD to change it, if desired.
2. From the Source options list, select the desired type of binding (choose from: Bound Label,
Properties, Actions, and others).
Note: Binding options that are dimmed indicate that they are not valid options for the selected component.
The Secondary view area displays fields and options that are related to the selected Source option.
360
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using the Px Editor
3. In the Secondary view area, choose a widget template, formatting options for display labels, or views, as appropriate for your Source option.
4. In the Properties sheet area, edit the properties or actions, as desired.
5. Click the OK button to complete the wizard. The Make Widget wizard disappears and the new widget appears on the Px Editor canvas.
6. Toggle the view using the View/Edit Mode toolbar icon to display the widget in the Px
Viewer.
Binding widgets
There are different ways to add a binding to a widget. You can add a binding to a widget using the
Make Widget wizard or you can add a binding to a widget that is already on the Px Editor canvas.
To bind a value to a widget
1. In the Px Editor canvas, select the desired widget.
2. In the Properties side bar, click the Add Binding toolbar icon.
The Add Binding dialog box appears.
3. Select a binding type from the options list and click the OK button.
The binding type properties are added to the “binding” area at the bottom of the widget property sheet.
4. Under the binding type properties, click the ORD property field.
The ORD dialog box appears.
5. In the ORD dialog box, type or browse to the value that you want to bind to the widget and click the OK button.
The ORD is added to the binding area of the widget property sheet.
Editing widget properties
To edit a widget property
To edit a widget, do the following:
1. In the Px Editor canvas, select (or double-click) the desired widget.
The widget properties display in the properties side bar (or in properties dialog box, if you doubleclicked).
2. In the Px Editor properties side bar (or dialog box) edit the widget properties, as desired:
• To edit a widget property: add, change, or remove a property value from the desired property field in the properties side bar.
•
• To animate a widget property, from the palette side bar, right-click in the properties field and select Animate from the popup menu (refer to
“Animating widget properties” for details).
• To delete a binding, click the Close icon (X) in the top right corner of the properties side bar.
3. If you are working in the properties dialog box, click the OK button.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
361
Using the Nav File Editor
The edits are made and the widget properties are changed.
Chapter 12 — Performing Workbench tasks
Animating widget properties
To animate a widget property
“Animating” a property means to link a widget property to a bound data component value, so that the widget can display any change in value, as it happens. For more information about animating graphic views, refer to
“Animating Graphics” on page 230.
Note: Before you can animate a widget property, you must add a binding from the desired component to the target widget. The binding must exist before the property can be animated. Refer to
“Binding widgets” on page 361 for details about adding a binding to a widget.
To animate a widget property, do the following:
1. In the Px Editor canvas, select (or double-click) the desired widget that you want to animate.
The widget properties display in the properties side bar (or in properties dialog box, if you doubleclicked).
2. In the Px Editor properties side bar (or dialog box) right-clickon the properties field of the property that you want to animate and select Animate from the popup menu.
The Animate dialog box appears. If you have more than one binding associated with the widget, all bindings will be available in the Binding options list.
3. From the Binding options list, select the binding that is associated with the component value you want to link to.
4. From the Converter Type options list, select the binding that is associated with the component value you want to link to.
Note: The converter type that is selected by default is based on the component that you have selected and most of the time will be the converter type that you want to use. For more
information about converter types, refer to “Types of Converters” on page 234.
The Animate dialog box displays different fields, based on the type of value (and thus, converter) that you animating.
5. Complete the binding to the value using the controls in the Animate dialog box and click the OK button.
The Animate dialog box disappears and the binding appears in properties side bar (or dialog box).
6. Click the OK button to close the properties dialog box, if necessary.
The property value is animated.
Using the Nav File Editor
The following tasks are commonly associated with setting up and working with the nav files in NiagaraAX:
•
362
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using the Nav File Editor
•
Editing a Nav file in the Nav File Editor
Creating a new Nav file
You may have more than one nav file associated with a station. The nav files must reside on the file system, not in the station database.
Note: For convenience and good organization, it is a good idea to create a “nav” folder on the file system to hold all your nav files.
For more information about nav files, refer to “About the Nav file” on page 264. For information
about using the Nav File Editor, refer to
“About the Nav File Editor” on page 266.
To create a new nav file:
To create a new nav file, do the following:
1. In the nav tree, right-click on (or under) the file system node.
The popup menu appears.
2. From the popup menu, select New > NavFile.nav.
The File Name dialog box appears with a default name.
3. In the File Name dialog box, type the desired name for the new Nav file and click OK.
The File Name dialog box disappears and the new Nav file appears in the nav tree.
To delete nav file (Delete Key):
To delete a nav file using the Delete key, do the following:
1. In the nav tree, select the nav file that you want to delete.
2. On the keyboard, press the
Delete
key.
The nav file is deleted.
To delete nav file (popup menu):
To delete a nav file using the popup menu, do the following:
1. In the nav tree, right-click on the nav file that you want to delete.
The popup menu appears.
2. From the popup menu, select Delete.
The nav file is deleted.
To rename a nav file:
To rename nav file, do the following:
1. In the nav tree, right-click on (or under) the file system node.
The popup menu appears.
2. From the popup menu, select Rename.
The Rename dialog box appears with the current name in the text field.
3. In the Rename dialog box, type the desired name for the nav file in the text field and click OK.
The nav file is renamed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
363
Chapter 12 — Performing Workbench tasks
Using the Nav File Editor
Editing a Nav file in the Nav File Editor
You can edit nav files in the Text Editor or in the Nav File Editor. The following procedure describes how to edit a Nav File in the Nav File Editor.
For more information about nav files, refer to “About the Nav file” on page 264. For information
about the Nav File Editor, refer to “About the Nav File Editor” on page 266.
The following procedures describe tasks involved with editing nav files:
•
To open a nav file in the Nav File Editor:
•
To add nodes to a nav file using the Nav File Editor:
•
To delete nodes from a nav file:
•
To edit the node hierarchy (tree structure) in a nav file:
•
To open a nav file in the Nav File Editor:
To open a nav file in the Nav File Editor, do one of the following:
Note: The nav file resides on the file system, not in the station database. You may keep all station nav files in a “nav” folder to improve or simplify file organization on your station.
1. In the nav side bar, find the nav file that you want to open, and do one of the following:
• Double-click on the desired nav file. OR
• Right-click on the Nav File and select View > Nav File Editor from the popup menu.
The Nav File Editor will open and display the file in the Result Tree pane.
2. Edit the nav file, as desired.
3. Click the Save icon on the toolbar or select File > Save to save changes to the nav file.
To add nodes to a nav file using the Nav File Editor:
There are several ways to add nodes to a nav file using the Nav File Editor.
To add nodes to a nav file do the following:
1. Open the desired nav file in the Nav File Editor (refer to
“To open a nav file in the Nav File Editor:” , if necessary).
2. Add a node to the Result Pane using any of the following methods:
• Copy and paste
Copy a component or Px file from the nav side bar and paste it into the Result Tree pane. The new node appears in the Result Tree as a child node of the node that you target when pasting.
• Drag and drop (from nav side bar)
Drag a component or Px file from the nav side bar and drop it onto the Result Tree pane. A new node appears in the Result Tree as a child node of the node that you target when dropping it.
• Popup menu
Right-click on the component that you want to add and select Copy from the popup menu.
Right-click the desired target area in the Result Tree, and select Paste from the popup menu.
A new node appears in the Result Tree as a child node of the node that you target when pasting.
• New button
Click the New button on the bottom of the Nav File Editor pane. The New Node dialog box appears. Edit the Display Name, Target Ord, and Icon fields, as desired and click the OK button.
A new node appears in the Result Tree as a child node of the node that is selected.
364
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 12 — Performing Workbench tasks
Using the Nav File Editor
• Drag and drop (from Source Tree)
Toggle the Show Components button and the Show Files button to display the desired objects in the Source Tree pane. Drag the desired component or Px file from the Source Tree pane and drop it onto the Result Tree pane at the desired location.
A new node appears in the Result Tree as a child node of the node that you target.
3. Click the Save icon on the toolbar or select File > Save to save changes to the nav file.
To delete nodes from a nav file:
To delete nodes from a nav file, do the following:
1. Open the desired nav file in the Nav File Editor (refer to
“To open a nav file in the Nav File Editor:” , if necessary).
2. In the Result Tree, find the node that you want to delete, and then do one of the following:
• Select the node that you want to delete and click the Delete button. OR
• Select the node that you want to delete and press the
Delete
key on the keyboard. OR
• Right-click on the node that you want to delete and select Delete from the popup menu. OR
The node will disappear from the Result Tree pane.
3. Save changes to the nav file by clicking the Save button on the toolbar or select Save from the
File
menu.
The nav file changes are saved.
4. Click the Save icon on the toolbar or select File > Save to save changes to the nav file.
To edit the node hierarchy (tree structure) in a nav file:
To edit the node hierarchy in a nav file, do the following:
1. Open the desired nav file in the Nav File Editor (refer to
“To open a nav file in the Nav File Editor:” , if necessary).
2. In the nav tree, find the nav file that you want to edit, and then do any of the following:
• Drag and drop the desired tree node from one location to another location in the tree.
• Select one or more tree nodes and use the Move Up or Move Down buttons to raised or lower the node in its parent node.
Note: The Move Up and Move Down buttons will move nodes only within their parent node.
To move a node to a different parent, you must cut and paste the node.
The Nav File Editor displays the new node location in the Result Tree pane.
3. Click the Save icon on the toolbar or select File > Save to save changes to the nav file.
To edit nodes in a nav file:
To edit a new nav file, do the following:
1. Open the desired nav file in the Nav File Editor (refer to
“To open a nav file in the Nav File Editor:” , if necessary).
2. In the nav tree, find the node that you want to edit, and then do one of the following:
• Double-click on the desired node. OR
• Select the desire node and click the Edit button.
• Right-click on the node File and select Edit from the popup menu.
The Edit dialog box will open and display the node properties.
3. In the Edit dialog box, edit the node Display Name, Target Ord, and Icon properties, as desired and click the OK button.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
365
Chapter 12 — Performing Workbench tasks
Using the Nav File Editor
The node properties are changed.
4. Click the Save icon on the toolbar or select File > Save to save changes to the nav file.
366
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Component Reference Summary
Component Guides
These Component Guides provides summary information on common components. In addition, developer bajadoc help is referenced.
Component Reference Summary
Note: For details on kitControl components, see
“Components in kitControl module” section in the
kitControl Guide.
Summary information is provided on components in the following modules:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
367
Components in alarm module
Components in alarm module
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Chapter 13 — Component Guides alarm-AlarmClass
alarm-AlarmClass
An AlarmClass object is used to group Alarms that have the same routing and handling characteristics. The AlarmClass is available in the Alarm Module.
• Refer to
“About alarm class” on page 204 for more details about alarm class.
• Bajadoc is available at BAlarmClass.bajadoc
alarm-AlarmConsoleOptions
The AlarmConsoleOptions component allows you to configure the parameters of the alarm console. The Options dialog box displays when you select the Workbench Tools >
Options
menu item.
• Refer to
“Alarm console options” on page 46 for details about the individual alarm console
options.
• Refer to
for details about the alarm console.
The component is stored under the “/users/{user}/options” directory.
alarm-AlarmPortalOptions
This component allows you to configure the alarm portal parameters . The Options dialog box displays when you select the Workbench Tools > Options menu item.
• Refer to
“Alarm portal options” on page 47 for details about the individual alarm console options.
• Refer to
for details about the alarm console.
The component is stored under the “/users/{user}/options” directory.
368
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in alarm module alarm-AlarmService
alarm-AlarmService
The AlarmService uses AlarmClasses to route all Alarm messages between AlarmSources and
AlarmRecipients. Each Station contains a single AlarmService. The AlarmService is available in the Alarm Module.
• Refer to
“About the alarm service” on page 196 for more details.
• Bajadoc is available at BAlarmService.bajadoc
alarm-AlarmSourceExt
AlarmSourceExt is the abstract superclass of all Baja control Alarming algorithms. The Alarm-
SourceExt is available in the alarm Module Extensions Directory. Some common alarm source extensions include OutOfRangeAlarmExt, BooleanChangeOfStateAlarmExt, BooleanCommandFailureAlarmExt, EnumChangeOfStateAlarmExt and EnumCommandFailureAlarmExt. Bajadoc is available at BAlarmSourceExt.bajadoc
Refer to
“About alarm extensions and components” on page 192 for more details.
AckAlarm
Acknowledge the Alarm matching this ack request.
SilenceAlarm
Silence the Alarm matching this silence request.
alarm-AlarmSourceInfo
AlarmSourceInfo is a container slot on any network component, and also on each child device component. Properties under this slot are used to populate the alarm record when the network or device does not respond to the network’s monitor ping. These properties work in the same fashion as those in an alarm extension for any control point.
See the following links for more information:
•
“About network Alarm Source Info” on page 96
•
“About Monitor” on page 96 for details on the network monitor mechanism
•
“About alarm extension properties” on page 193 for AlarmSourceInfo property descriptions
• Bajadoc is available at BAlarmSourceInfo.bajadoc
alarm-BooleanChangeOfStateAlarmExt
BooleanChangeOfStateAlarmExt implements a change of state alarm detection algorithm for
Boolean objects as described in BACnet Clause 13.3.2. This alarm extension is available in the
Extensions folder of the alarm palette.
See the following links for more information:
•
“Types of alarm extensions” on page 66
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
369
Components in alarm module
Chapter 13 — Component Guides alarm-BooleanCommandFailureAlarmExt
•
“About alarm extensions and components” on page 192
•
“About alarm extension properties” on page 193
•
“About alarm extension manager” on page 199
• Bajadoc is available at BBooleanChangeOfStateAlgorithm.bajadoc
alarm-BooleanCommandFailureAlarmExt
BooleanCommandFailureAlgorithm implements command failure alarm detection algorithm for Boolean objects as described in BACnet. If feedback and output values of the point are not equal for timeDelay duration, an offnormal alarm is generated. This alarm extension is available in the Extensions folder of the alarm palette.
See the following links for more information:
•
“Types of alarm extensions” on page 66
•
“About alarm extensions and components” on page 192
•
“About alarm extension properties” on page 193
•
“About alarm extension manager” on page 199
• Bajadoc is available at BBooleanCommandFailureAlgorithm.bajadoc
alarm-ConsoleRecipient
This component manages the transfer of alarms between the alarm history and the alarm console. The ConsoleRecipient is available in the Alarm Module.
See the following links for more information:
•
“About the console recipient” on page 208
•
“Types of alarm recipients” on page 208
•
“About the alarm service” on page 196
• Bajadoc is available at BConsoleRecipient.bajadoc
Scan Unacked Alarms
Get all unacked Alarms that have been created (and unacked) since "alarmsSince".
Actions
alarm-FaultAlgorithm
FaultAlgorithm is the super-class of all Fault detection mechanisms defined by Niagara. The default implementation will never generate any toFault Alarms. The FaultAlgorithm is available in the alarm Module Extensions Directory. Bajadoc is available at BFaultAlgorithm.bajadoc
370
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in alarm module alarm-EnumChangeOfStateAlarmExt
alarm-EnumChangeOfStateAlarmExt
EnumChangeOfStateAlarmExt implements a change of state alarm detection algorithm for
Enum objects as described in BACnet Clause 13.3.2. Each algorithm instance defines a set of enumerated values that should be considered “offnormal” conditions and therefore generate an alarm.
This alarm extension is available in the Extensions folder of the alarm palette.
See the following links for more information:
•
“Types of alarm extensions” on page 66
•
“About alarm extensions and components” on page 192
•
“About alarm extension properties” on page 193
•
“About alarm extension manager” on page 199
• Bajadoc is available at BalarmEnumChangeOfStateAlarmExt.bajadoc
alarm-EnumCommandFailureAlarmExt
EnumCommandFailureAlarmExt implements command failure alarm detection algorithm for enum objects as described in BACnet. If feedback and output values of the enum point are not equal for more than timeDelay, an offnormal alarm is generated. This alarm extension is available in the Extensions folder of the alarm palette.
See the following links for more information:
•
“Types of alarm extensions” on page 66
•
“About alarm extensions and components” on page 192
•
“About alarm extension properties” on page 193
•
“About alarm extension manager” on page 199
• Bajadoc is available at BEnumCommandFailureAlgorithm.bajadoc
alarm-LinePrinterRecipient
The LinePrinterRecipient component provides the capability to print alarms to line printers that are attached to a station that is running on a Win32 platform. This recipient can print to local and remote line printers. Alerts may be generated if the printing of an alarm fails, but the lineprinter recipient does not print alarms that it generates itself.
See the following links for more information:
•
“About the lineprinter recipient” on page 213
•
“Types of alarm recipients” on page 208
•
“About the alarm service” on page 196
• Bajadoc is available at BLinePrinterRecipient.bajadoc
alarm-MemoryAlarmService
MemoryAlarmService provides an alternative to the standard file-based AlarmService. When you use this service, alarms are not stored persistently on the station host as they are with the standard file-based alarm service. The MemoryAlarmService is available in the Alarm Module.
• Refer to
“About memory alarm service” on page 197 for more details.
• Bajadoc is available at BMemoryAlarmService.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
371
Components in backup module
Chapter 13 — Component Guides alarm-OffnormalAlgorithm
alarm-OffnormalAlgorithm
BOffnormalAlgorithm is a super-class for all algorithms that check for off normal (not Fault) conditions.
• Refer to
“Types of control extensions” on page 64 for more information about “off normal”.
• Bajadoc is available at BOffnormalAlgorithm.bajadoc
alarm-OutOfRangeAlarmExt
OutOfRangeAlarmExt implements a standard out-of-range alarming algorithm, and applies to points with status numeric output. This alarm extension is available in the Extensions folder of the alarm palette.
• Refer to
“Types of control extensions” on page 64 for more information about “out of range”.
• Bajadoc is available at BOutOfRangeAlgorithm.bajadoc
alarm-StationRecipient
Recipient for another station. This class receives Alarms and formats them for another station.
The StationRecipient is available in the Alarm Module.
See the following links for more information:
•
“About the station recipient” on page 211
•
“Types of alarm recipients” on page 208
•
“About the alarm service” on page 196
• Bajadoc is available at BStationRecipient.bajadoc
alarm-StatusAlarmExt
StatusAlarmExt provides alarming based upon any combination of status flags, and applies to all points/objects that accept extensions. This alarm extension is available in the Extensions folder of the alarm palette.
• Refer to
“Types of control extensions” on page 64 for more information about “off normal”.
• Bajadoc is available at BStatusAlarmAlgorithm.bajadoc
Components in backup module
•
backup-BackupService
The BackupService provides for complete configuration backups to a Workbench PC or a browser PC (user with Wb web profile). By default, the BackupService is included when you create a new station using the New Station wizard. The target Niagara host (JACE, Supervisor) must have the backup module installed.
A backup is a dist file (a zipped format) including minimally the station’s config.bog, current station console output (.txt file), and backup.log file. If other station file types and subfolders are not
372
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in baja module backup-BackupService
excluded (in the BackupService configuration ), the backup dist file contains them too—for example,
files of type: px, nav, html, jpg, png, and so forth. Also, the backup dist contains the zipped “nre-config” for that host (including license and certificates files), as well as pointers to the installed “nrecore,” OS, and JVM, each by version. Essentially, a backup dist provides a “configuration snapshot” of the entire JACE platform in zipped “dist” file format. This allows for a complete image restoration.
Note: Not included in a backup is runtime data that is actively managed by the station, such as the alarm and history databases. This data should be “backed up” using standard alarm routing and history archiving to a Supervisor host.
To restore a backup dist from Workbench, you open a platform connection to the JACE, then use the platform Distribution File Installer to install. Restoring from a backup may be necessary if the host hardware was replaced.
The default view of a station’s BackupService is the
BackupManager , which provides a Backup but-
ton to manually initiate a backup. A backup automatically performs a local station save first, and is
. This means each backup provides a progress bar, and upon completion,
a popup notification. Under the station’s JobService
, any backup appears as a “Fox Backup.”
BackupService configuration
Configuration lets you define the file types and/or folders not included in a station backup. The service’s property sheet provides the following properties for configuration:
• Enabled
Either true (default) or false. Currently, this setting makes no difference (manual backup still possible even if service has disabled status).
• Exclude Files
Specifies file types to exclude from the backup dist, either by name or extension (each delimited by “;”). By default, the following files are excluded:
*.hdb;*.adb;*.lock;*backup*;console.*;config.bog.b*;config_backup*
• Exclude Directories
Specifies station subdirectories to exclude from the backup dist, using relative ord syntax. An ord chooser control provides a Directory Chooser dialog in which you can select station subfolders.
By default, the following subfolders are excluded: file:^history, file:^alarm
Components in baja module
•
•
•
•
•
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
373
Components in baja module
Chapter 13 — Component Guides baja-Category
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
baja-Category
Each Category represents a custom logical grouping, and has a unique category index number.
You can assign components, files, and histories to one or more categories. All categorizable components have a CategorySheet view, which shows you that component’s stored category memberships (CategoryMask).
Categories reside under the station’s CategoryService
, which has views CategoryBrowser and CategoryManager. Categories play an integral role in station security, where you can give users permissions for some (or all) categories. For a general review, see
“Security model overview” on page 271.
Bajadoc is available at BCategory.bajadoc
baja-CategoryService
The CategoryService is the station container for all
Category (ies), which represent logical
groupings to which you can assign components, files, and histories. The default view of this ser-
, lets you centrally assign different objects to categories, using an expandable tree view of the station.
The CategoryService also provides a CategoryManager
view, for you to create, edit and delete categories. Categories play an integral role in station security, where you can give users permissions for some (or all) categories. By default, the CategoryService is included when you create a new station using the New Station wizard. For more CategoryService details, see
“CategoryService” on page 288. Bajadoc is available at BCategoryService.bajadoc
baja-Component
Component is the required base class for all Baja component classes. The Component is available in the baja Module. Bajadoc is available at BComponent.bajadoc
374
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in baja module baja-DataFile
Using Containers
•
•
Containers allow you to logically group Components. The current container is the Component that contains the Components in the display window. A container may be selected as the current container by one of the following methods:
• Double-click the Component in the tree view.
• Right-click the Component in the tree view (which brings up the menu) and select a view.
• Right-clicking the Component in WireSheet (which brings up the menu) and select a view.
The Container Components include the following:
Component can be used as a general container for Components. It allows you to place Components and links in a container.
Page is a special Component used to created a map of name/Ref pairs as dynamic slots.
baja-DataFile
DataFile represents a DataFile in the file system of a session. Bajadoc is available at BData-
File.bajadoc
baja-Directory
Directory is used to represent Directories in File space implementations. Bajadoc is available at
BDirectory.bajadoc.
baja-FileSystem
FileSystem is a FileSpace for the local machine's File system. Bajadoc is available at BFileSystem.bajadoc
baja-Folder
Folder is a special Container designed to store objects. The Folder is available in the baja Module. Bajadoc is available at BFolder.bajadoc
baja-Format
Format is used to format Objects into Strings using a standardized formatting pattern language. The format String is normal text with embedded scripts denoted by the the % percent character (use %% to insert a real %). A script is one or more calls chained together using the . dot operator. Calls are mapped to methods using reflections. Given call "foo", the order of reflection mapping is:
• special call (see below)
• getFoo(Context)
• getFoo()
• foo(Context)
• foo()
• get("foo")
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
375
Components in baja module
Chapter 13 — Component Guides baja-IpHost
The following special functions are available to use in a script:
• time() calls Clock.time() to get current time as an AbsTime
• lexicon(module:key) gets the specified lexicon text
Examples of formats:
• "hello world"
• "my name is %displayName%"
• "my parent's name is %parent.displayName%"
• "%value% {%status.flagsToString%} @ %status.priority%"
• "%time().toDateString%"
• "%lexicon(bajaui:dialog.error)%"
Format is available in the baja Module. Bajadoc is available at BFormat.bajadoc
baja-IpHost
IpHost is used to represent a host machine that is identified with an IP address. The hostname of an IpHost is either a a name resolvable via DNS or is a raw IP address. Bajadoc is available at
BIpHost.bajadoc
baja-Job
A Job is used to manage a task that runs asynchronously in the background, but requires user visibility. Some example jobs include:
•
StationSaveJob
— From a station save, either initiated manually or from the auto-save function (see “PlatformServiceContainer configuration parameters” on page 74).
•
FoxBackupJob
— From a station backup (zip) to a remote PC, see
Many drivers also have various job types too. For example, the NiagaraDriver includes a Station-
DiscoveryJob
and NiagaraScheduleLearnJob.
Every job finishes displaying one of the following status descriptors:
•
Success
— Job completed successfully.
•
Canceled
— Job canceled by user.
•
Failure
— Job failed to complete.
•
Completed
— Job completed.
Also, if you have the station open in Workbench, you see a momentary “notification popup” in the lower-right corner of your display.
You can monitor and cancel a job from within the particular view where you initiated it, or centrally from the
view of a station’s JobService
. You can also open a Jobs side bar to see
all jobs in all opened stations (see “Using the jobs side bar” on page 345).
Regardless of how you access jobs, note the following:
• To see details on a job, click the “>>” button next to its status descriptor. A popup Job Log dialog displays all the interim steps about the job, including timestamps and relevant messages.
• To dispose of a job, click the close (“X”) button to remove it from the station.
Note: All jobs in a station are cleared upon a station restart.
Bajadoc is available at BJob.bajadoc
376
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in baja module baja-StationSaveJob
baja-StationSaveJob
This component appears as a child of the job service and displays the following properties relative to the save job:
• Job State
indicates which of the following states the save job is in currently: unknown, running, canceling, canceled, success, failed.
• Progress
indicates a percentage (0-100) of progress toward completing the job.
• Start Time
displays the time that the job started.
• Heart Beat Time
displays the time of the last indication that the job is alive.
• End Time
displays the time that the job ends
For related information, refer to:
•
•
Note: All jobs in a station are cleared upon a station restart.
baja-JobService
The JobService contains
Job s that were executed by different processes in the station. Each job
appears as a child component. By default, the JobService is included when you create a new sta-
tion using the New Station wizard. The default view of the JobService is the JobServiceManager
.
Bajadoc is available at BJobService.bajadoc
Note: All jobs in a station are cleared upon a station restart.
baja-LocalHost
LocalHost represents the root of the Baja local Host namespace. The LocalHost is available in the baja Module. Bajadoc is available at BLocalHost.bajadoc
baja-Module
Module encapsulates a Baja software Module which is packaged and delivered as a JAR file with a "meta-inf/module.xml" description. Modules are the unit of software deployment in the
Baja architecture. Module names must be one to 25 ASCII characters in length and globally unique.
Modules is available in the
ModuleSpace (called Modules under My Computer). Bajadoc is available
at BModule.bajadoc
baja-ModuleSpace
ModuleSpace is the Container for Modules which are keyed by their Module name. The ModuleSpace is available as Modules under My Computer. Bajadoc is available at BMod-
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
377
Components in baja module
Chapter 13 — Component Guides baja-Permissions uleSpace.bajadoc
baja-Permissions
Permissions are a property used to define the permissions given to a user’s
baja-PermissionsMap
Defines the security permissions to grant to a user. Permissions are added as dynamic proper-
ties with the name matching a Category
and the value an instance of permissions. For more
details, see “Permissions and security” on page 275 and
“About permission levels” on page 276. If a
user has been configured as a super user, then all permissions are automatically granted to all categories. Bajadoc is available at BPermissionsMap.bajadoc
baja-PxView
PxView a dynamic view which may be added to Components as a property or by overriding getAgents(). PxViews store the view contents in an XML file with a px extension. The view itself is defined as a tree of bajaui:Widgets. The PxView is available in the baja Module. Bajadoc is available at BPxView.bajadoc
baja-ServiceContainer
ServiceContainer provides a component to store services. The ServiceManager
is its primary view. The ServiceContainer is available in the baja Module. Bajadoc is available at BServiceContainer.bajadoc
baja-Spy
Spy is an Object wrapper for an instance of Spy. Bajadoc is available at BSpy.bajadoc
baja-Station
Station is the component which represents a Station in the Baja framework. See Station in the
Developer Guide for more information. The Station is available in the baja Module. Bajadoc is available at BStation.bajadoc
Station Save
Save the current state of the system to persistent storage. You should regularly backup your station or stations using the Save Action on the station.
baja-UnrestrictedFolder
UnrestrictedFolder is a special container designed to store objects for use on a palette. Normal isParentLegal() checks are not applied to UnrestrictedFolders. The UnrestrictedFolder is avail-
378
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in bajaui module able in the baja Module. Bajadoc is available at BUnrestrictedFolder.bajadoc
baja-User
baja-User
User is the component that represents a station connection, typically a specific person who needs to access the system. Users are children of the station’s
For more details, see the following sections:
•
“Users and security” on page 273
•
“User” on page 284 (all properties)
•
“UserService security notes” on page 278
Also, see “Security model overview” on page 271. Bajadoc is available at BUser.bajadoc
baja-UserService
UserService is the service you use to add, edit, delete, and otherwise manage users of the sta-
tion. The UserManager is its primary view. Also available is a PermissionsBrowser view, in
which you can review and change permissions for any user’s assigned Category (ies). See
“Users and security” on page 273 and
“UserService” on page 282 for more details. The UserService is available
in the baja module. By default, the UserService is included when you create a new station using the
New Station
wizard. Bajadoc is available at BUserService.bajadoc
Note: To facilitate user management, the UserService component has a unique permissions scheme.
See “UserService security notes” on page 278 for details.
baja-Vector
Vector is a dynamic Struct which allows Properties to be added at runtime.
Vector is available in the baja Module. Bajadoc is available at BVector.bajadoc
baja-WsTextBlock
WsTextBlock is a Niagara specific Component used to visualize text blocks on a
.
Bajadoc is available at BWsTextBlock.bajadoc
baja-ZipFile
ZipFile represents a ZipFile in the File system of a session. Bajadoc is available at BZip-
File.bajadoc
Components in bajaui module
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
379
Components in bajaui module
Chapter 13 — Component Guides bajaui-BorderPane
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
bajaui-BorderPane
BorderPane provides a border content for a widget similar to the CSS Box Model. Margin defines the space between the bounds and the border. Padding defines the space between the border and the child bounds. Border defines the look and width of the border around each of the sides.
Bajadoc is available at BBorderPane Bajadoc.
bajaui-Bookmark
Bookmark provides a bookmark. Bajadoc is available at BBookmark Bajadoc.
bajaui-BoundTable
BoundTable is a Table implementation that is ready to use with TableBindings to populate its model. Bajadoc is available at BBoundTable Bajadoc.
bajaui-Button
Button is a control button which fires an action when pushed. Bajadoc is available at BButton
Bajadoc.
380
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in bajaui module bajaui-CanvasPane
bajaui-CanvasPane
CanvasPane is commonly used to provide absolute layout using Layout for most Widgets and
Geom for Shapes. CanvasPane also provides support for scaling and/or aligning its contents.
Bajadoc is available at BCanvasPane Bajadoc.
bajaui-CheckBox
CheckBox is a specialized ToggleButton which displays its label next to a box which can be checked and unchecked. Bajadoc is available at BCheckBox Bajadoc.
bajaui-ConstrainedPane
ConstrainedPane is a pane with a constrained size. It allows the pane to be restricted by minimum width, maximum width, minimum height, and maximum height. Bajadoc is available at
BConstrainedPane Bajadoc.
bajaui-EdgePane
EdgePane is a container with a layout like the java.awt.BorderLayout. It only supports five potential children in the frozen slots top, bottom, left, right, and center. The top and bottom widgets fill the pane horizontally use their preferred height. The left and right widgets use their preferred width, and occupy the vertical space between the top and bottom. The center widget gets all the remainder space. Any of the widgets may be a NullWidget. Bajadoc is available at BEdgePane Bajadoc.
bajaui-Ellipse
Ellipse renders a ellipse geometry. Bajadoc is available at BEllipse Bajadoc.
bajaui-ExpandablePane
ExpandablePane contains two widgets. A summary widget is displayed all the time, with a button to the right used to expand and collapse the pane. When expanded, the expansion widget is displayed under the summary. Bajadoc is available at BExpandablePane Bajadoc.
bajaui-FlowPane
FlowPane lays out its children from left to right and top to bottom fitting as many children as possible in each row. It is based on the java.awt.FlowLayout. Bajadoc is available at BFlowPane
Bajadoc.
bajaui-GridPane
GridPane provides flexible layout based on a grid with a predefined number of columns. Cells are laid out left to right, flowing to the next row based on the columnCount property. Row height is determined by the max preferred height of the widgets in the row. If uniformRowHeight is true then
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
381
Components in bajaui module
Chapter 13 — Component Guides bajaui-HyperlinkLabel all row heights are sized using the max row. Column width is determined by the max preferred width of the widgets in the column. If uniformColumnWidth is true then all column widths are sized using the max column. If rowLayout is set to fill then all widgets in a given row are sized to fill the row height. Otherwise the widgets use their preferred height and are aligned accordingly. If columnLayout is set to fill then all widgets in a given column are sized to fill the column width. Otherwise the widgets use their preferred width and are aligned accordingly. The columnGap field specifies how many pixels to leave between columns. The rowGap field specifies how many pixels to leave been rows. By default if the actual space of the pane is bigger than the preferred size, then the horizontalPaneAlignment and verticalPaneAlignment fields determine where to put the extra space. Or the stretchColumn and stretchRow properties may be used to indicate that a specific column or row should be stretched to fill the additional space. Enabling the stretch feature trumps pane alignment. If the colorRows field is true then alternating rows are shaded to produce a stripped effect. Bajadoc is available at BGrid-
Pane Bajadoc.
bajaui-HyperlinkLabel
The HyperlinkLabel has the same properties as the Label (see
property that allows you to assign an ORD to the label. When an ORD path is supplied for this property, the the HyperlinkLabel causes a mouse cursor to change to a standard link cursor and the component performs a hyperlink when clicked.
bajaui-Label
Label is used to display text and/or an icon. Labels are always transparent, so their background is defined by their parent. Their preferred size is always an exact fit to contain the text and/or icon. Labels may be used by themselves to display information which cannot respond to user input, or they may be embedded in widgets such as Buttons. Bajadoc is available at BLabel Bajadoc.
bajaui-Line
Line renders a line between two points. Bajadoc is available at BLine Bajadoc.
bajaui-RadioButton
RadioButton is a specialized ToggleButton which displays its label next to a circle which can be checked and unchecked. It is used with groups of other RadioButton's to provide an choice which is exclusive of other options. Bajadoc is available at BRadioButton Bajadoc.
bajaui-Rect
Rect renders a rectangle shape. Bajadoc is available at BRect Bajadoc.
bajaui-Path
Defines a general path to draw or fill, using a model and string format based on the SVG path element.
382
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in bajaui module
bajaui-Polygon
Models a closed area defined by a series of line segments, using string format
“x,y,width,height”.
bajaui-Polygon
bajaui-ScrollPane
ScrollPane layouts one child using a viewport which may be scrolled to view the entire child's actual size. Bajadoc is available at BScrollPane Bajadoc.
bajaui-Separator
Separator is used in ToolBars and Menus to provide a visible separator between groups of buttons. Bajadoc is available at BSeparator Bajadoc.
bajaui-Slider
Slider provides a visual slider which is used to select and integer or floating point value between a fixed range. Bajadoc is available at BSlider Bajadoc.
bajaui-SplitPane
SplitPane is a pane with a divider between two child widgets. The children can be laid out horizontally or vertically. Bajadoc is available at BSplitPane Bajadoc.
bajaui-TabbedPane
TabbedPane is a container which displays a set of LabelPane children one at a time using a set of "tabs" to select the currently displayed child. The LabelPane's label is used to label each tab, and the content of the current selection fills the rest of the pane. Bajadoc is available at BTabbedPane
Bajadoc.
bajaui-TextEditorOptions
The TextEditorOptions stores the options used to configure text entry. The Status Colors options allow you to view and change the following (default):
• Show Spaces (false)
• Show Tabs (false)
• Show Newlines (false)
• Tab To Space Conversion (2)
• Show Margin (0)
• Color Coding
• Foreground (00 00 00 black)
• Whitespace (c0 c0 c0 gray)
• Number Literal (80 00 80 purple)
• String Literal (80 00 80 purple)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
383
Components in bajaui module
• Identifier (00 00 00 black)
• Keyword (00 00 ff blue)
• Preprocessor (80 00 00 maroon)
• Bracket (ff 00 00 red)
• Line Comment (00 80 00 green)
• Multi Line Comment (00 80 00 green)
• Non Javadoc Comment (80 80 80 dark gray)
• Key Bindings (with default)
• Move Up Up
• Move Down Down
• Move Left Left
• Move Right Right
• Page Up PageUp
• Page Down PageDown
• Line Start Home
• Line End End
• Document Start Ctrl + Home
• Document End Ctrl + End
• Word Left Ctrl + Left
• Word Right Ctrl + Right
• Cut Ctrl + X
• Copy Ctrl + C
• Paste Ctrl + V
• Undo Ctrl + Z
• Redo Ctrl + Alt + Z
• Delete Delete
• Backspace Backspace
• Cut Line Ctrl + Y
• Delete Word Ctrl + Delete
• Tab Forward Tab
• Tab Back Shift + Tab
• Toggle Slash Slash Esc
• Word Wrap Ctrl + W
• Goto Line Ctrl + G
• Find F5
• Find Next Ctrl + F
• Find Prev Ctrl + Shift + F
• Replace F6
• Reload Macros Ctrl + M
• Select All Ctrl + A
• Undo Navigation (true)
• Match Parens (true)
• Match Braces (true)
• Match Brackets (true)
These are stored under /user/{user}/textEditor.options.
Chapter 13 — Component Guides bajaui-TextEditorOptions
384
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in chart module bajaui-ToggleButton
bajaui-ToggleButton
ToggleButton provides a two-state widget which may be selected and unselected. Bajadoc is available at BToggleButton Bajadoc.
bajaui-ValueBinding
ValueBinding is used to bind to Values typically under a Component. Widget properties may be overridden by creating dynamic slots of the same name with a Converter that maps the bound target to the property value. Bajadoc is available at BValueBinding Bajadoc
Components in chart module
•
•
•
•
•
•
chart-BarChart
One of two chart types available. Bajadoc is available at ?
chart-ChartCanvas
Bajadoc is available at ?
chart-ChartHeader
Bajadoc is available at ?
chart-ChartPane
Bajadoc is available at ?
chart-DefaultChartLegend
Bajadoc is available at ?
chart-LineChart
Bajadoc is available at ?
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
385
Components in control module
Components in control module
•
•
•
•
•
•
•
•
•
•
•
•
Chapter 13 — Component Guides control-BooleanPoint
control-BooleanPoint
BooleanPoint is a basic read-only control point, with default slots: Facets, Out, and ProxyExt.
See “About control points” on page 51 for details. The BooleanPoint is available in the Points
folder of the control palette. Bajadoc is available at BBooleanPoint.bajadoc.
control-BooleanWritable
BooleanWritable extends BooleanPoint
to include 16 levels of command priority control. The highest priority active command is reflected in the out property. Commands at the emergency
and manual levels (1 and 8) are stored persistently. See “About control points” on page 51, and
“About writable points” on page 81 for more details.
The BooleanWritable is available in the Points folder of the control palette. Bajadoc is available at
BBooleanWritable.bajadoc
control-DiscreteTotalizerExt
DiscreteTotalizerExt is a control point extension for accumulating runtime and change of state counts on binary or enum values. Two actions are available to clear (zero) accumulated totals,
ResetChangeOfStateCount and ResetElapsedActiveTime.
The DiscreteTotalizerExt is available in the Extensions folder of the control palette. Bajadoc is available at BDiscreteTotalizerExt.bajadoc
control-EnumPoint
EnumPoint is a basic read-only control point, with default slots: Facets, Out, and ProxyExt. See
“About control points” on page 51 for details. The EnumPoint is available in the Points folder of
the control palette. Bajadoc is available at BEnumPoint.bajadoc
386
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in control module control-EnumWritable
control-EnumWritable
WritableEnumPoint extends EnumPoint to include 16 levels of command priority control. The highest priority active command is reflected in the out property. Commands at the emergency
and manual levels (1 and 8) are stored persistently. See “About control points” on page 51, and
“About writable points” on page 81 for more details.
The EnumWritable is available in the Points folder of the control palette. Bajadoc is available at
BEnumWritable.bajadoc
control-NullProxyExt
NullProxyExt is the default implement AbstractProxyExt used to indicate that a point is not a
Proxy. The NullProxyExt is available in the control Module Extensions Directory. Bajadoc is available at BNullProxyExt.bajadoc
control-NumericPoint
NumericPoint is a basic read-only control point, with default slots: Facets, Out, and ProxyExt.
See “About control points” on page 51 for details. The NumericPoint is available in the Points
folder of the control palette. Bajadoc is available at BNumericPoint.bajadoc
control-NumericTotalizerExt
NumericTotalizerExt is a control point extension used for integrating a numeric point value over time. For example, a totalizer with a minutely totalization interval can convert an instantaneous flow reading in cubic feet per minute (cfm) into a value representing total cubic feet consumed.
An available resetTotal action clears (zeroes) any accumulated total.
The NumericTotalizerExt is available in the Extensions folder of the control palette. Bajadoc is available at BNumericTotalizerExt.bajadoc
control-NumericWritable
NumericWritable extends NumericPoint to include 16 levels of command priority control. The highest priority active command is reflected in the Out property. Commands at the Manual and manual levels (1 and 8) are stored persistently. See
“About control points” on page 51, and
“About writable points” on page 81 for more details.
The NumericWritable is available in the Points folder of the control palette. Bajadoc is available at
BNumericWritable.bajadoc
control-StringPoint
StringPoint is a basic read-only control point, with default slots: Facets, Out, and ProxyExt. See
“About control points” on page 51 for details. The StringPoint is available in the Points folder of
the control palette. Bajadoc Bajadoc is available at BStringPoint.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
387
Components in converters module
Chapter 13 — Component Guides control-StringWritable
control-StringWritable
StringWritable extends StringPoint to include 16 levels of command priority control. The highest priority active command is reflected in the Out property. Commands at the Manual and manual levels (1 and 8) are stored persistently. See
“About control points” on page 51, and
“About writable points” on page 81 for more details.
The StringWritable is available in the Points folder of the control palette. Bajadoc is available at
BStringWritable.bajadoc
control-TimeTrigger
TimeTrigger is a component that fires a topic at configured times. It is available configured as both “Interval” or “Daily” in the Trigger folder of the control palette. Bajadoc is available at
BTimeTrigger.bajadoc
Components in converters module
•
converters-EnumToSimpleMap
EnumToSimpleMap does something. Bajadoc is available at BIEnumToSimpleMap.bajadoc
Components in crypto module
•
•
crypto-CryptoService
CryptoService provides a central location to acquire cryptographic services. The CryptoService is available in the crypto Module. Bajadoc is available at BCryptoService.bajadoc
crypto-SslProvider
Bajadoc is available at BSslProvider.bajadoc.
Components in devkit module
•
devkit-LexiconOptions
The LexiconOptions stores the options used by the LexiconReport and LexiconEditor. The
Lexicon options allow you to change the following:
388
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in driver module
•
•
•
These are stored under /user/{user}/lexicon.options.
Components in driver module
•
•
•
•
•
•
•
•
driver-ConfigRule
driver-ConfigRule
ConfigRule is used to determine the configuration overrides for histories when they are
exported to the station. By default, the parent container HistoryNetworkExt
(History Policies) contains only a single ConfigRule, named “Default Rule.” Default settings are to configure “all” histories exported to the station as “unlimited” capacity. Bajadoc is available at BConfigRule.bajadoc
For more details, see “Config Rules” on page 153 and
“About History Policies” on page 151.
driver-DriverContainer
DriverContainer is used by convention to store all DeviceNetworks in a station database. The
is its primary view. See “About the Driver Manager” on page 93. Bajadoc is
available at BDriverContainer.bajadoc
driver-HistoryNetworkExt
HistoryNetworkExt (History Policies) manages network-level functions for histories that are exported to the station. Its is the container of the rules (
ConfigRule s) that specify how the con-
figuration of the local history (archive) should be set when the history is “pushed” (exported) into the station.
Configuration rules are applied only when the history is created, that is, when first archived to the station. Changing a rule has no effect on existing histories. For more details, see
“About History Policies” on page 151. Bajadoc is available at BBHistoryNetworkExt.bajadoc
driver-PingMonitor
The PingMonitor periodically calls “ping” on all the “pingables” to monitor network and device health. PingMonitor provides built-in support to generate alarms when pingables are
down. The PingMonitor is available in the property sheet of most networks as “Monitor.” See “About
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
389
Components in email module
Chapter 13 — Component Guides driver-SendTimer
Monitor” on page 96 for more details. Bajadoc is available at BPingMonitor.bajadoc
driver-SendTimer
This class file provides support for max and min send time on components implementing the
TimedWrites interface. The sendTimer will identify a SendTimes object in the parent path. The first SendTimes encounter walking up from the immediate parent will be used. If no SendTimes object is found then calls to newChange() will result in an single immediate call to sendWrite() on the parent. The SendTimer is available in the driver Module. Bajadoc is available at BSendTimer.bajadoc
driver-SendTimes
This class file provides the means to configure max and min send times for components implementing the TimedWrites interface and containing SendTimer object. The SendTimes is available in the driver Module. Bajadoc is available at BSendTimes.bajadoc
driver-TuningPolicy
Contains a collection of properties typically used in the driver network’s evaluation of both
write requests (e.g. to writable proxy points) as well as the acceptable “freshness” of read
requests. Also, can associate with one of 3 Poll Rates in the network’s Poll Service.
You can create multiple TuningPolicies under a driver’s TuningPolicyMap
. You can then assign one
or more proxy points to a specific TuningPolicy. See “About Tuning Policies” on page 98 for more
details. Bajadoc is available at BTuningPolicy.bajadoc
driver-TuningPolicyMap
Container for one or more
(ies), found in the property sheet of most network components. You can create multiple TuningPolicies under a network’s TuningPolicyMap. You can
Components in email module
•
•
•
•
•
email-Email
Email represents an email account that communicates periodically with a host email server. A
Email instance should always be a child of a EmailService. The Email is available in the email
Module. Bajadoc is available at BEmail.bajadoc
390
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in file module email-EmailRecipient
email-EmailRecipient
The top-level email Messaging service. This service manages the routing of all email messages from message sources to message recipients. The EmailRecipient is available in the email palette. Bajadoc is available at BEmailRecipient.bajadoc
Actions
Actions include
RouteAlarm
RouteAlarm routes the alarm.
email-EmailService
EmailService manages the life-cycle of Email
is its primary view.
The EmailService is available in the email palette. Bajadoc is available at BEmailService.bajadoc
email-IncomingAccount
that receives mail. A number of properties specify the SMTP host, port, and user credentials to use, as well as other parameters. The IncomingAccount is available in the email palette. Bajadoc is available at BIncomingAccount.bajadoc
email-OutgoingAccount
that sends mail. A number of properties specify the SMTP host, port, and user credentials to use, as well as other parameters. A “Max Sendable Per Day” property can limit the number of station-generated emails, where the default value is 100. The OutgoingAccount is available in the email palette. Bajadoc is available at BOutgoingAccount.bajadoc
Components in file module
•
•
•
•
•
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
391
Components in file module
Chapter 13 — Component Guides file-ApplicationFile
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
file-ApplicationFile
ApplicationFile stores an application file. Bajadoc is available at BApplicationFile.bajadoc
file-AudioFile
AudioFile stores an audio file. Bajadoc is available at BAudioFile.bajadoc
file-BajadocFile
BajadocFile represents Bajadoc documentation. Bajadoc is a special file that can describe
Components in a Database. Bajadoc is available at BBajadocFile.bajadoc
file-BogFile
BogFile represents a BogFile in the file system of a session. A Bog File is a special file that can describe Components in a Database. Bajadoc is available at BBogFile.bajadoc
file-BogScheme
BogScheme represents a BogScheme in the file system of a session. A Bog File is a special file that can describe Components in a Database. Bajadoc is available at BBogScheme.bajadoc
392
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in file module file-BogSpace
file-BogSpace
BogSpace represents a BogSpace in the file system of a session. A Bog File is a special file that can describe Components in a Database. Bajadoc is available at BBogSpace.bajadoc
file-CFile
CFile stores a c source file. Bajadoc is available at BCFile.bajadoc
file-CssFile
CssFile stores a CSS cascading style sheet. Bajadoc is available at BCssFile.bajadoc
file-ExcelFile
ExcelFile stores a Microsoft Excel file. Bajadoc is available at BExcelFile.bajadoc
file-GifFile
GifFile stores a GIF
ℑ. Bajadoc is available at BGifFile.bajadoc
file-HtmlFile
HtmlFile stores HTML markup. Bajadoc is available at BHtmlFile.bajadoc
file-ImageFile
ImageFile stores an
ℑ. Bajadoc is available at BImageFile.bajadoc
file-JavaFile
JavaFile stores a java source file. Bajadoc is available at BJavaFile.bajadoc
file-JpegFile
JpegFile stores a JPEG
ℑ. Bajadoc is available at BJpegFile.bajadoc
file-NavFile
NavFile stores XML nav markup. Bajadoc is available at BNavFile.bajadoc
file-PaletteFile
Palette file is just a Bog File file with a different extension and icon. Bajadoc is available at
BPaletteFile.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
393
Components in fox module
Chapter 13 — Component Guides file-PdfFile
file-PdfFile
PdfFile stores a Adobe PDF file. Bajadoc is available at BPdfFile.bajadoc
file-PngFile
PngFile stores a PNG
ℑ. Bajadoc is available at BPngFile.bajadoc
file-PowerPointFile
PowerPointFile stores a Microsoft PowerPoint file. Bajadoc is available at BPowerPoint-
File.bajadoc
file-PrintFile
PrintFile stores XML Print markup. Bajadoc is available at BPrintFile.bajadoc
file-PxFile
PxFile is just a Bog File file with a different extension and icon. Bajadoc is available at BPx-
File.bajadoc
file-TextFile
TextFile stores plain text. Bajadoc is available at BTextFile.bajadoc
file-VideoFile
VideoFile stores an video file. Bajadoc is available at BVideoFile.bajadoc
file-VisioFile
VisioFile stores a Microsoft Visio file. Bajadoc is available at BVisioFile.bajadoc
file-WordFile
WordFile stores a Microsoft Word file. Bajadoc is available at BWordFile.bajadoc
file-XmlFile
XmlFile stores an xml file. Bajadoc is available at BXmlFile.bajadoc
Components in fox module
•
•
•
394
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in fox module fox-FoxClientConnection
•
•
fox-FoxClientConnection
FoxClientConnection encapsulates a FoxSession connection. You must setup the Address,
Username
and Password in order to access a remote station. The FoxClientConnection is available in the fox Module. Bajadoc is available at BFoxClientConnection.bajadoc
Actions
You can manually force/test a connection using Manual Connect and Manual Disconnect actions.
fox-FoxFileSpace
FoxFileSpace maps "File:" remotely. Bajadoc is available at BFoxFileSpace.bajadoc
fox-FoxServerConnection
FoxServerConnection encapsulates a Fox (client) session connection to the station’s Fox server.
It represents user access (vs. access from another station). Child slots provide the connection state as well as various historical data about last connect and disconnect activity. The FoxServerConnection is available in the fox module. Bajadoc is available at BFoxServerConnection.bajadoc
Actions
Available Action is Force Disconnect.
fox-FoxService
FoxService is the Baja Component wrapper for the FoxServer daemon. It is commonly used within a NiagaraNetwork, but can be used stand alone to provide basic Fox accessibility. Bajadoc is available at BFoxService.bajadoc
fox-FoxSession
FoxSession is a host's session using a fox connection to a specific port. Bajadoc is available at
BFoxSession.bajadoc
fox-ServerConnections
ServerConnections is the container slot to store the current server-side FoxServerConnection
s
from non-station clients. The primary view is the ServerConnectionsSummary
. The ServerConnections is available in the fox module. Bajadoc is available at BServerConnections.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
395
Components in gx module
Chapter 13 — Component Guides gx-Brush
Components in gx module
•
gx-Brush
Brush is used to change presentation. The Brush is available in the gx Module.
Components in help module
•
help-BajadocOptions
The BajadocOptions stores the options used by the BajadocViewer. The Bajadoc options allow you to change the following:
• Show Baja Only
• Flatten Inheritance
These are stored under /user/{user}/bajadoc.options.
Components in history module
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
396
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in history module history-AuditRecord
•
•
history-AuditRecord
The AuditRecord keeps a History of changes made by users. If enabled, it registers itself as the
Auditor for the system when the service is started. The AuditRecord is available in the History
Module under the HistoryService. Bajadoc is available at BAuditRecord.bajadoc
history-AuditHistoryService
The AuditHistoryService keeps a history of changes made by users. If enabled, it registers itself as the auditor for the station when the service is started. The AuditHistoryService is available in the history palette.
One of the important aspects of security is the ability to analyze what has happened after the fact. The
Niagara Component model is designed to audit all property modifications and all Action invocations.
Auditable actions include:
• Property changed
• Property added
• Property removed
• Property renamed
• Properties reordered
• Action invoked
Component modifications are only audited when the modification method is passed a non-null Context with a non-null User. The History Module includes a standard implementation of an audit trail stored to a History Database File. Bajadoc is available at BAuditHistoryService.bajadoc.
history-BooleanCovHistoryExt
BooleanCovHistoryExt is a history extension that is used for recording on change of value for boolean point data. This extension is available in the history Module Extensions Directory.
Refer to
“Types of history extensions” on page 67 for more information about this extension.
history-BooleanIntervalHistoryExt
BooleanIntervalHistoryExt is a history extension that is used for recording on intervals for boolean point data. This extension is available in the history Module Extensions Directory.
Refer to
“Types of history extensions” on page 67 for more information about this extension.
history-ConfigRule
ConfigRule is used to determine the overrides for an existing history configuration. The ConfigRule is available in the history Module. Bajadoc is available at BConfigRule.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
397
Components in history module
Chapter 13 — Component Guides history-ConfigRules
history-ConfigRules
ConfigRules is the container for rules that determine the configuration of histories that are pushed to the local device. Configuration rules are applied when a history is created. Changing a rule has no effect on existing histories. The ConfigRules is available in the history Module. Bajadoc is available at BConfigRules.bajadoc
history-CovAlgorithm
CovAlgorithm determines when to log a point's value according to change of value. The
CovAlgorithm is available in the history Module Extensions Directory under some Change Of
Value extensions as Collector. Bajadoc is available at BCovAlgorithm.bajadoc
history-EnumCovHistoryExt
EnumCovHistoryExt is a history extension used to record on a change of value for Enum point
history-EnumIntervalHistoryExt
EnumIntervalHistoryExt is a history extension used to record on intervals for Enum point data.
This extension is available in the history Module Extensions Directory. Refer to
“Types of history extensions” on page 67 for more information about this extension.
history-FoxHistory
FoxHistory is the implementation of BIHistory that works with the FoxHistorySpace. Bajadoc is available at BFoxHistory.bajadoc
history-FoxHistorySpace
FoxHistorySpace provides access to a History Database using the fox protocol. Bajadoc is available at BFoxHistorySpace.bajadoc
history-HistoryConfig
HistoryConfig is the configuration for a History in the History Database. Bajadoc is available at
BHistoryConfig.bajadoc
history-HistoryDevice
HistoryDevice represents a source device for histories. Bajadoc is available at BHistoryDevice.bajadoc
398
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in history module history-HistoryEditorOptions
history-HistoryEditorOptions
The HistoryEditorOptions stores the options used to configure hisotry options.
These are stored under /user/{user}/textEditor.options.
history-HistoryId
HistoryId is a container for History id. Bajadoc is available at BHistoryId.bajadoc
history-HistoryService
The History service provides http access to all histories in the Station. This service manages the
History lifecycle, including creation and deletion. Additionally, HistoryService maintains the namespace for all Historys. As histories are created, they are added as slots to this service, and removed upon deletion. When the service is started, all existing histories are added to the service.
Additionally, this service maintains global configuration for the histories. Each Station contains a sin-
gle HistoryService. See the HistoryExtManager
for more information on using histories. The History-
Service is available in the History Module. Bajadoc is available at BHistoryService.bajadoc
CloseUnusedHistories
Close all Unused Histories in this service.
FlushHistories
Flush all histories managed by this service.
history-IntervalAlgorithm
IntervalAlgorithm logs a value periodically at a fixed interval. The IntervalAlgorithm is available in the history Module Extensions Directory under some Interval extensions as Collector.
Bajadoc is available at BIntervalAlgorithm.bajadoc
history-LocalDatabaseConfig
LocalDatabaseConfig is the configuration for a LocalHistoryDatabase. Bajadoc is available at
BLocalDatabaseConfig.bajadoc
history-LogHistoryService
The LogHistoryService keeps a History of Niagara log records. If enabled, it registers itself as the LogHandler for the system when the service is started. The LogHistoryService is available in the History Module. Bajadoc is available at BLogHistoryService.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
399
Components in history module
Chapter 13 — Component Guides history-NumericCovAlgorithm
history-NumericCovAlgorithm
NumericCovAlgorithm determines when to log a numeric point's value according to change of value. The NumericCovAlgorithm is available in the history Module Extensions Directory under
NumericChangeOfValue as Collector. Bajadoc is available at BNumericCovAlgorithm.bajadoc
history-NumericCovHistoryExt
NumericCovHistoryExt is a history extension used to record on change of value for numeric point data. This extension is available in the history Module Extensions Directory. Refer to
“Types of history extensions” on page 67 for more information about this extension.
history-NumericIntervalAlgorithm
NumericIntervalAlgorithm logs a numeric point's value according to a schedule. The NumericIntervalAlgorithm is available in the history Module Extensions Directory under NumericInterval as Collector. Bajadoc is available at BNumericIntervalAlgorithm.bajadoc
Actions
Collect
Collect a data point.
CommenceCollection
Start Collection in the algorithm.
history-NumericIntervalHistoryExt
NumericIntervalHistoryExt is a history extension used to record on interval for numeric point
Actions
400
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in kitPx module history-StringCovHistoryExt
Collect
Collect a data point.
CommenceCollection
Start Collection in the algorithm.
history-StringCovHistoryExt
StringCovHistoryExt is a history extension used for collecting a string control value on change of value. This extension is available in the history Module Extensions Directory. Refer to
“Types of history extensions” on page 67 for more information about this extension.
history-StringIntervalHistoryExt
StringIntervalHistoryExt is a history extension for collecting a string control value at intervals.
This extension is available in the history Module Extensions Directory. Refer to
“Types of history extensions” on page 67 for more information about this extension.
Components in kitPx module
•
•
•
•
•
•
•
•
•
•
•
•
kitPx-ActionBinding
kitPx-ActionBinding invokes an action on the binding target component when an event is fired by the parent widget. The ORD of an action binding must resolve down to a specific action within a component.
Addtional information and related topics include:
•
“About action bindings” on page 236
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
401
Components in kitPx module
Chapter 13 — Component Guides kitPx-AnalogMeter
kitPx-AnalogMeter
kitPx-AnalogMeter is a widget that is designed to look and act like a analog meter. This component comes with a value binding that should be bound to a value by an ORD.
Addtional information and related topics include:
•
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-Bargraph
kitPx-Bargraph is a widget that is designed to display a single value in a bar graph. In addition to action bindings, value and setpoint bindings are available.
Addtional information and related topics include:
•
“About value bindings” on page 234
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
To plot more than one value using a single widget (using a line chart), you can use a chart widget, as described in
“Create a Chart widget” on page 262, or for history tables,
“About the history chart view” on page 178.
kitPx-BoundLabelBinding
kitPx-BoundLabelBinding is used exclusively for connecting a value to a bound label widget.
Bound labels, which are located in the kitPx module, have properties that you can edit and access from the Px Editor properties side bar.
Addtional information and related topics include:
•
“About bound label bindings” on page 233
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-BoundLabel
kitPx-BoundLabel is a widget that simply provides a label widget (see
“bajaui-Label” on page 382) with a binding already available.
Addtional information and related topics include:
•
“About bound label bindings” on page 233
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-GenericFieldEditor
kitPx-GenericFieldEditor is a field editor that allows you to edit properties from a graphic view on non-specific fields. It is designed for layout on panes and is comprised of standard widgets like buttons, text fields, and check boxes. Specialized field editor widgets include: SetPointFieldEdi-
402
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in kitPx module
tor (see “kitPx-SetPointFieldEditor” on page 404).
Addtional information and related topics include:
•
“About field editor bindings” on page 237
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-ImageButton
kitPx-ImageButton
kitPx-ImageButton is a button that uses images to display the state of the button. For example, the image button may have three separate images to indicate the normal, mouseOver, and pressed
states. In addition to other properties, the image button includes the following distinctive properties:
• Mouse Over
this property allows you to assign an image that appears when the mouse hovers over the button.
• Normal
this property allows you to assign an image that appears when the button is not in a pressed or mouseOver
state.
• Pressed
this property allows you to assign an image that appears when the button is pressed.
See the following topics for related information about buttons:
•
“kitPx-RefreshButton” on page 403
•
“kitPx-SaveButton” on page 404
•
•
“bajaui-ToggleButton” on page 385
kitPx-IncrementSetPointBinding
kitPx-IncrementSetPointBinding is used to increment (increase) or decrement (decrease) a setpoint value.
Addtional information and related topics include:
•
“About increment setpoint bindings” on page 236
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-RefreshButton
kitPx-RefreshButton is used to issue a refresh command when it is clicked. The “Refresh” text that appears on the button is included by default in the Text property–but, like the other properties, it may be edited, as desired.
See the following topics for related information about buttons:
•
“kitPx-ImageButton” on page 403
•
“kitPx-SaveButton” on page 404
•
•
“bajaui-ToggleButton” on page 385
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
403
Components in ldap module
Chapter 13 — Component Guides kitPx-SaveButton
kitPx-SaveButton
kitPx is used to issue a save command when it is clicked. The “Save” text that appears on the button is included by default in the Save property–but, like the other properties, it may be edited, as desired.
See the following topics for related information about buttons:
•
“kitPx-ImageButton” on page 403
•
“kitPx-RefreshButton” on page 403
•
•
“bajaui-ToggleButton” on page 385
kitPx-SetPointBinding
kitPx-SetPointBinding is used to display the current value of a setpoint and also to provide the ability to modify it. The setpoint binding ORD must resolve down to the specific property that is being manupilated.
Addtional information and related topics include:
•
“About setpoint bindings” on page 235
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
kitPx-SetPointFieldEditor
kitPx-SetPoinFieldEditor is a special field editor that is designed to allow you to edit setpoint values from a graphic view. It is designed for layout on panes and is comprised of standard widgets like buttons, text fields, and check boxes. For editing non-specific properties, use the kitPxGenericFieldEditor (see
“kitPx-GenericFieldEditor” on page 402).
Addtional information and related topics include:
•
“About field editor bindings” on page 237
•
“Types of bindings” on page 231
•
“Types of binding properties” on page 232
Components in ldap module
•
•
•
ldap-LdapClient
LdapClient is a client for Ldap. The LdapClient is available in the ldap Module. Bajadoc is available at BLdapClient.bajadoc
404
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in net module ldap-LdapConfiguration
ldap-LdapConfiguration
LdapConfiguration is a child of the LdapUserService
that contains various properties that define the LDAP attribute and connection methods. LdapConfiguration is available in the ldap palette. Bajadoc is available at BLdapConfiguration.bajadoc
ldap-LdapUserService
LdapUserService allows users to be downloaded from an LDAP server. LDAP users are stored transiently and are hidden. If a non-transient user is found in the service at login, the LDAP
server will not be queried. The primary view is the UserManager
. The LdapUserService is available in the ldap Module. Bajadoc is available at BLdapUserService.bajadoc
Components in net module
•
net-InternetAddress
InternetAddress is ? Bajadoc is available at BInternetAddress.bajadoc
Components in niagaraDriver module
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
niagaraDriver-DistributedQuery
DistributedQuery is the configuration for a distributed query against zero or more remote stations. The DistributedQuery is available in the niagaraDriver Module. Bajadoc is available at
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
405
Components in niagaraDriver module
Chapter 13 — Component Guides niagaraDriver-NiagaraAlarmDeviceExt
BDistributedQuery.bajadoc
niagaraDriver-NiagaraAlarmDeviceExt
NiagaraAlarmDeviceExt is used to map all native Alarms in a device into the Baja Alarm framework. The NiagaraAlarmDeviceExt is available in the niagaraDriver Module. Bajadoc is available at BNiagaraAlarmDeviceExt.bajadoc
niagaraDriver-NiagaraFoxService
NiagaraFoxService is a specialization of FoxService that knows how to map server connections to the NiagaraStation serverConnection slot. NiagaraFoxService typically includes
BNiagaraFoxService.bajadoc
niagaraDriver-NiagaraHistoryDeviceExt
NiagaraHistoryDeviceExt is the Niagara implementation of HistoryDeviceExt. NiagaraHistoryDeviceExt is available in the niagaraDriver Module. Bajadoc is available at BNiagaraHistory-
DeviceExt.bajadoc
niagaraDriver-NiagaraHistoryImport
NiagaraHistoryImport defines the local import parameters for a remote Niagara history, including collection (“pull”) times, current status, local history Id, and config overrides. NiagaraHistoryImports reside under the History extension of a Station in the Niagara Network. Bajadoc is available at BNiagaraHistoryImport.bajadoc
niagaraDriver-NiagaraNetwork
NiagaraNetwork models the list of NiagaraAX devices ( NiagaraStationNiagaraStationNiagaraStation
s) that a given station can communicate with. The primary view is the StationManager .
NiagaraNetwork includes the NiagaraFoxService
. The NiagaraNetwork is available in the niagaraDriver Module. Bajadoc is available at BNiagaraNetwork.bajadoc
niagaraDriver-NiagaraPointDeviceExt
NiagaraPointDeviceExt is the Niagara implementation of PointDeviceExt. The primary view is
. The NiagaraPointDeviceExt is available in the niagaraDriver Module as
Points in Station. Bajadoc is available at BNiagaraPointDeviceExt.bajadoc
niagaraDriver-NiagaraPointFolder
NiagaraPointFolder is the Niagara implementation of a folder under a NiagaraStation’s Points
extension. You add such folders using the New Folder button in the PointManager
view of the
Points extension. Each NiagaraPointFolder has its own
PointManager view. The NiagaraPointFolder
406
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in niagaraDriver module niagaraDriver-NiagaraProxyExt is also available in the niagaraDriver palette. Bajadoc is available at BNiagaraPointFolder.bajadoc
niagaraDriver-NiagaraProxyExt
NiagaraProxyExt is the Niagara implementation of BProxyExt. The NiagaraProxyExt is available in the niagaraDriver Module as Proxy Ext under NiagaraNetwork. Bajadoc is available at
BNiagaraProxyExt.bajadoc
niagaraDriver-NiagaraScheduleDeviceExt
This represents the schedules in a device. The NiagaraSchedule is available in the niagaraDriver Module. Bajadoc is available at BNiagaraScheduleDeviceExt.bajadoc
niagaraDriver-NiagaraScheduleImportExt
NiagaraScheduleImport defines the local import parameters for a remote Niagara schedule.
NiagaraScheduleImportExts reside under the Schedules extension of a
in the
Niagara Network. Bajadoc is available at BNiagaraScheduleImportExt.bajadoc
niagaraDriver-NiagaraStation
NiagaraStation models a platform running a Niagara station including a JACE, NP, or Supervisor. The NiagaraStation name must map to Station.stationName. NiagaraStation typically
includes FoxClientConnection , FoxServerConnection
NiagaraHistoryDeviceExt and NiagaraAlarmDeviceExt . The NiagaraStation is available in
the niagaraDriver Module as Station. Bajadoc is available at BNiagaraStation.bajadoc
Ping
Perform a ping test of the device.
niagaraDriver-NiagaraStationFolder
NiagaraStationFolder is the Niagara implementation of a folder under a NiagaraNetwork. You add such folders using the New Folder button in the
view of the Niagara net-
work. Each NiagaraStationFolder has its own StationManager view. The NiagaraStationFolder is also
available in the niagaraDriver palette. Bajadoc is available at BNiagaraStationFolder.bajadoc
niagaraDriver-PointChannel
PointChannel handles messages used by the
NiagaraPointDeviceExt . Bajadoc is available at
BPointChannel.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
407
Components in program module
Chapter 13 — Component Guides niagaraDriver-QueryService
PushPointEvent
This callback is linked to the various local Component's point properties for subscriptions being pushed to the remote VM.
niagaraDriver-QueryService
doc
QueryService is the service that processes distributed queries for a NiagaraNetwork. The QueryService is available in the niagaraDriver Module. Bajadoc is available at BQueryService.baja-
niagaraDriver-StationDiscoveryTask
StationDiscoveryTask is used to Discover the Stations on the Network. The StationDiscovery-
Task is available in the niagaraDriver Module. Bajadoc is available at BStationDiscovery-
Task.bajadoc
niagaraDriver-StationWorker
StationWorker manages the queue and worker for communication to a specific station. The StationWorker is available in the niagaraDriver Module. Bajadoc is available at BStation-
Worker.bajadoc
Components in program module
•
•
program-Program
Program uses an instance based classfile to implement user defined component logic. The Program can be viewed and edited using the
ProgramEditor . The Program is available in the pro-
gram Module. Bajadoc is available at BProgram.bajadoc
Actions
Actions include Execute.
program-ProgramService
ProgramService is used to launch batch programs. The ProgramService is available in the program Module. Bajadoc is available at BProgramService.bajadoc
408
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in pxeditor module pxeditor-NewPxViewDialog
Actions
Actions include Run Robot.
Components in pxeditor module
•
pxeditor-NewPxViewDialog
NewPxViewDialog allows you to create a new px view.
Components in raster module
•
raster-RasterEditorOptions
RasterOptions wraps all configuration for an the raster editor. The Raster Editor options allow you to view and change Animate Selections. These are stored under /user/{user}/rasterEditor.options.
Components in rdb module
•
•
•
rdb-RdbmsFolder
RdbmsFolder is used to organize databases under an RdbmsNetwork. It is created using the
New Folder button in the DriverManager view for any RdbmsNetwork
. Bajadoc is available at
BRdbmsFolder.bajadoc
rdb-RdbmsNetwork
RdbmsNetwork models a network of BRdbms objects. It is available in the any of the rdb (relational database) palettes, such as rdbDb2, rdbOracle, and rdbSqlServer. Bajadoc is available at
BRdbmsNetwork.bajadoc
rdb-RdbmsWorker
RdbmsWorker manages the queue and worker for asynchronous operations on a single database. It is available under any of the rdb (relational database) types, such as
Db2Database , OracleDatabase , and SqlServerDatabase
. Bajadoc is available at BRdbmsWorker.bajadoc
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
409
Components in rdbDb2 module
Components in rdbDb2 module
•
•
Chapter 13 — Component Guides rdbDb2-Db2Database
rdbDb2-Db2Database
Db2Database models an Db2 relational database. It is available in the rdbDb2 palette. Bajadoc is available at BDb2Database.bajadoc
rdbDb2-Db2HistoryDeviceExt
Db2HistoryDeviceExt is the Db2 implementation of HistoryDeviceExt. It is a child of a
Db2Database . Bajadoc is available at BDb2HistoryDeviceExt.bajadoc
Components in rdbOracle module
•
•
rdbOracle-OracleDatabase
Db2Database models an Oracle relational database. It is available in the rdbOracle palette.
Bajadoc is available at BOracleDatabase.bajadoc
rdbOracle-OracleHistoryDeviceExt
OracleHistoryDeviceExt is the Oracle implementation of HistoryDeviceExt. It is a child of a
OracleDatabase . Bajadoc is available at BOracleHistoryDeviceExt.bajadoc
Components in rdbSqlServer
•
•
rdbSqlServer-SqlServerDatabase
SqlServerDatabase models an SqlServer relational database. It is available in the rdbSqlServer palette. Bajadoc is available at BSqlServerDatabase.bajadoc
rdbSqlServer-SqlServerHistoryDeviceExt
SqlServerHistoryDeviceExt is the SqlServer implementation of HistoryDeviceExt. It is a child of an
SqlServerDatabase . Bajadoc is available at BSqlServerHistoryDeviceExt.bajadoc
410
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in schedule module
Components in schedule module
•
•
•
•
•
•
schedule-BooleanSchedule
schedule-BooleanSchedule
A deployable weekly schedule that provides a continuous StatusBoolean output. Other weekly
schedule types include EnumSchedule , NumericSchedule
, and
. See
“About weekly schedules” on page 297 for more details.
Input - If the “in” property is linked and its value is non-null, then this value overrides the scheduled output. The BooleanSchedule is available in the schedule palette. Bajadoc is available at BBooleanSchedule.bajadoc
Using Schedules
Schedules allow you to program commands to occur at specific times. Each schedule component is designed to provide an output based on the current time. Components can receive this
command by linking to this output. See the “Weekly Scheduler view” on page 299 for more informa-
tion on using schedules.
schedule-CalendarSchedule
The CalendarSchedule provides a calendar for scheduling holidays or other schedule overrides.
The CalendarSchedule is available in the schedule palette. Bajadoc is available at BCalendar-
Schedule.bajadoc
schedule-EnumSchedule
A deployable weekly schedule that provides a continuous StatusEnum output. Other weekly
schedule types include BooleanSchedule , NumericSchedule
, and
. See
“About weekly schedules” on page 297 for more details.
Input - If the “in” property is linked and its value is non-null, then this value overrides the scheduled output. The EnumSchedule is available in the schedule palette. Bajadoc is available at BEnum-
Schedule.bajadoc
schedule-NumericSchedule
A deployable weekly schedule that provides a continuous StatusNumeric output. Other weekly
schedule types include BooleanSchedule , EnumSchedule
, and
. See
“About weekly schedules” on page 297 for more details.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
411
Components in timesync module
Chapter 13 — Component Guides schedule-StringSchedule
Input - If the “in” property is linked and its value is non-null, then this value overrides the scheduled output. The NumericSchedule is available in the schedule palette. Bajadoc is available at BNumericSchedule.bajadoc
schedule-StringSchedule
A deployable weekly schedule that provides a continuous StatusString output. Other weekly
schedule types include BooleanSchedule , EnumSchedule
, and
“About weekly schedules” on page 297 for more details.
Input - If the “in” property is linked and its value is non-null, then this value overrides the scheduled output. The StringSchedule is available in the schedule palette. Bajadoc is available at BString-
Schedule.bajadoc
schedule-TriggerSchedule
A schedule that fires topics - there is no continuous output. The TriggerSchedule is available in the schedule palette. Bajadoc is available at BTriggerSchedule.bajadoc
Components in timesync module
•
•
timesync-TimeServer
Slot of a TimeSyncService used to poll a time protocol server. The TimeServer is available in the timesync Module. Bajadoc is available at BTimeServer.bajadoc
timesync-TimeSyncService
A time protocol (RFC 868) client and server. To synchronize with other servers, TimeServers must be added to the service. As a convenience, a disabled default client has already been added
(it will need configuring). The service uses the clients to poll their configured servers, and if the service detects a drift greater than the tolerance property, the service will reset the system time. The module palette contains clients preconfigured for well known time protocol servers. The primary
view of this Component is TimeSyncManager .
From the
PropertySheet , you can set Enabled and Server Enabled.Enabled (to false) to dis-
able the time sync client. Server Enabled enables the time sync server. In order to sync between
configured for the server Station. The TimeSyncService is available in the timesync Module. Bajadoc is available at BTimeSyncService.bajadoc
412
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 13 — Component Guides
Components in web module web-WebService
ForceSync
Force Time Synchronization.
Sync
Time Synchronization.
Components in web module
•
web-WebService
WebService encapsulates access to the HTTP Web Server as well as to the Servlet infrastructure used to provide a World Wide Web browser based interface. Each Station contains a single
WebService. HTTP requests can be tunnelled through the WebService of a Station to the WebService of another Station on the NiagaraNetwork. This is done with a request of the format: http://host/tunnel/stationname/ where host is the supervisor and stationname is the name of the station under NiagaraNetwork.
The WebService is available in the web Module. Bajadoc is available at BWebService.bajadoc
Components in workbench module
•
•
•
•
workbench-ComponentFinder
The ComponentFinder dialog provides a means of finding Components.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
413
Components in workbench module
Figure 1 Sample Window
Chapter 13 — Component Guides workbench-WbFieldEditorBinding
workbench-WbFieldEditorBinding
WbFieldEditorBinding is used to bind WbFieldEditors to an object. It allows any existing
WbFieldEditor (BooleanFE, EnumFE, AbsTimeFE,etc) to be used in a PX presentation. Bajadoc is available at BWbFieldEditorBinding.bajadoc
workbench-WbViewBinding
WbViewBinding is used to bind WbViews to an object. It allows any existing WbView (
, PointManager , etc) to be used in a PX presentation. Bajadoc is available at
BWbViewBinding.bajadoc
workbench-WsOptions
The WireSheet options allow you to view and change the following:
•
•
These are stored under /user/{user}/wiresheet.options.
414
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides alarm-AlarmConsole Viewing Alarms
Plugin Guides
There are many ways to view plugins (views). One way is directly in the tree. In addition, you can right-click on an item and select one of its views. Plugins provide views of components.
Access the following summary descriptions on any plugin by selecting Help > On View (F1) from the menu, or pressing F1 while the view is open.
alarm-AlarmConsole
The Alarm Console allows you to view and acknowledge Alarms. It can be started by Right-
clicking the alarmRecipient in the AlarmService
and selecting Views > Alarm Console.
Viewing Alarms
•
•
•
•
Multiple Alarms from a single source are visualized as a single row in the alarm console. Color coded icons provide a visual indication for unacknowledged/inAlarm, acknowledged/inAlarm, and unacknowledged/not inAlarm.
•
•
•
•
• alarm
redAlarm
greenAlarm
orangeAlarm
Double-clicking a row in the Table hows the history of the alarms associated with that point. You can sort the Alarms in order of any column by pressing the column bar (once for ascending, twice for descending). Available commands include:
Acknowledging Alarms
Select an Alarm by Left-clicking it. In order to acknowledge an Alarm, press the Alarm
Acknowledge
toolbar button or select Alarm > Acknowledge from the Menu. You can select multiple Alarms and acknowledge them simultaneously. In order to silence Alarms, press the
Alarm Silence
toolbar button or select Alarm > Silence from the Menu.
Acknowledge
Acknowledge allows you to acknowledge the currently selected Alarm(s).
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
415
alarm-AlarmDbMaintenance
Hyperlink
Hyperlink allows you to hyperlink to Alarm URL.
Silence
Silence allows you to silence the currently selected Alarm(s).
Filter
Filter allows you to filter alarms.
Chapter 14 — Plugin Guides
Alarm Report Dialog
Alarm Report Dialog
•
•
•
•
From the Alarm console, you can view the Alarm Report to see all alarms on the point. Select an
Alarm and Double-click it to see the Alarm Report.
You can sort the Alarms in order of any column by pressing the column bar (once for ascending, twice for descending). Available commands include:
Viewing Alarm Record
•
•
•
•
From the Alarm Report Dialog, you can view the Alarm record to see all information on the Alarm.
Select an Alarm and Double-click it to see the Alarm record.
Available commands include:
Notes
Notes allows you to add user notes to Alarm records.
alarm-AlarmDbMaintenance
AlarmDbMaintenance is a view of the alarm service. It allows you view and manage alarm records.
For more information refer to:
•
“About alarm database maintenance”
416
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides alarm-AlarmClassSummary Notes
•
alarm-AlarmClassSummary
AlarmClassSummary is a view of the alarm service. It presents a table of information about all alarm classes that are assigned to the alarm service.
For more information refer to:
•
“About the alarm class summary view”
•
alarm-AlarmExtManager
AlarmExtManager allows you to manage Alarm extensions.
alarm-AlarmPortal
•
•
•
•
•
The Alarm Portal allows you to view and acknowledge Alarms from multiple Stations. It can be started from the main Menu by selecting Tools > AlarmPortal.
From the Alarm Portal, you can view the Alarm record to see all information on the Alarm. Select an
Alarm and Double-click it to see the Viewing Alarm Record
. Available commands include:
backup-BackupManager
The BackupManager is the default view for a station’s
BackupService . From this view you can
issue a backup command, to back up the station’s configuration to your local PC, in dist file format. When you issue a Backup command, a File Chooser dialog appears to select the destination directory on your PC (see
File Ord Chooser ) and the file name for the backup dist file.
The default backup destination depends on your station connection, as either:
• Workbench (Fox) — !backups
A subdirectory “backups” under your Niagara release directory. If you have not previously made station backups, this directory is automatically created.
• Browser access (Wb Web Profile) — !backups
A subdirectory “backups” under the Niagara subfolder of your installed Java 2 runtime environment (Java plugin).
For example: C:\Program Files\Java\j2rel1.4.2_05\niagara\backups.
If you have not previously made station backups, this directory is automatically created.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
417
chart-ResourceManager
Chapter 14 — Plugin Guides
Notes
The default name for a backup file uses a format of: backup_stationName_YYMMDD_HHMM.dist
For example, “backup_J403IP98c_050618_1429.dist” for a backup made of station “J403IP98c” on
June 18, 2005 at 2:29 pm.
In the BackupManager, a progress bar and Job Log (>> control) is provided for an initiated backup.
The BackupManager displays a table of the 10 most recent backups, with the following data columns:
• Timestamp
Station date and time when the backup was initiated.
• Host
IP address of the requesting (remote) PC for the backup.
• Path
File path used on the requesting (remote) PC for saving the backup. Typically, this is relative to the default Niagara directory (!), however, it may be an absolute file path.
• User
The station user that initiated the backup.
chart-ResourceManager
The Resource Manager is an available view on any running station. It provides a line chart of both CPU and memory usage of the host platform, and updates in real time. In addition, individual resource statistics are provided in a table, which you can refresh by clicking the Update button.
devkit-LexiconEditor
The LexiconEditor Plugin allows you to view and modify the localization of lexicon files. The lexiconEditor is invoked by selecting Lexicon Tool from the main Tools Menu. From there you can select a lexicon by clicking on one. The LexiconEditor is invoked if you Double-click on a Module. It will present the list of keys with default and lexicon value. If you select a key, you can change the lexicon value by entering it at the bottom and pressing Change. You can select a different lexicon or Module using the selection list at the top. You can also check Hide Icons, Hide
Accelerators
and/or Show Missing Only to select the keys that will be displayed.
LexiconEditor Menus
The Workbench main menu functions are available. When the LexiconEditor is visible, the following
LexiconEditor menu functions are also available:
•
•
•
LexiconEditor Pulldowns and Buttons
The lexiconEditor has pulldowns and buttons that include:
•
418
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides devkit-LexiconEditor Notes
•
•
•
•
•
•
•
LexiconEditor Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
Lexicon
Lexicon pulldown allows you to select another lexicon directly from the LexiconEditor.
Module
Module pulldown allows you to select another Module directly from the LexiconEditor.
Hide Ref Values
Filter values starting with / from lexicon view. This is available if you do not want to localize references (like icons).
Hide Accelerators
Hide entries that define keyboard accelerators. This is available if you do not want to localize the accelerators.
Show Missing Only
Hide entries that are localized. This is available if you do not want to see localized keys.
Value
Value
allows you to enter a new value for a lexicon entry. You must press Change for the value to be entered.
Change
Change
places the new value into the list of keys. You must press Save to write values to the lexicon file.
Add New Key
Add New Key
allows you to add an additional key to the lexicon. You must press Save to write
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
419
devkit-LexiconReport
Chapter 14 — Plugin Guides
Notes values to the lexicon file.
devkit-LexiconReport
The LexiconReport Plugin provides a report on localization of lexicon files. The LexiconReport in invoked by selecting Lexicon Tool from the main Tools menu. From there you can select a lexicon by Clicking on one. It will present the list of Modules with lexicons and the last time that the Module lexicon was modified and the last time the lexicon was modified. It also shows the number of keys missing from the lexicon for each Module. You can check Hide Icons and/or
Hide Accelerators
to ignore these keys which are not usually localized. If you Double-click a
Module, you will go to the LexiconEditor
. You can create new lexicons and delete lexicons.
LexiconReport Menus
The Workbench main menu functions are available. When the LexiconReport is visible, the following
LexiconReport menu functions are also available:
•
•
LexiconReport Pulldowns and Buttons
The LexiconReport has pulldowns and buttons that include:
•
•
•
•
LexiconReport Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38.
New Lexicon
This allows you to define a new lexicon. It should follow the Java localization model.
Delete Lexicon
This allows you to delete a lexicon.
driver-DeviceManager
The DeviceManager plugin allows you to create and manage devices. The DeviceManager is a
view on a network component in a station. For details, see “About the Device Manager” on page 105.
420
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides driver-DriverManager Notes
driver-DriverManager
“About the Driver Manager” on page 93.
driver-HistoryExportManager
HistoryExportManager provides a view of
NiagaraHistoryDeviceExt . To see the view, rightclick on a NiagaraHistoryDeviceExt
in a Station and select Views > History Export
Manager
. For details, see “History Export Manager” on page 137.
driver-HistoryImportManager
HistoryImportManager provides a view of
NiagaraHistoryDeviceExt . To see the view, rightclick on a NiagaraHistoryDeviceExt
in a Station and select Views > HistoryImportMan-
ager
. For details, see “History Import Manager” on page 132.
driver-PointManager
PointManager provides an overview of the proxy points mapped into the PointDeviceExt. In a
NiagaraNetwork , PointManager is a view on the NiagaraPointDeviceExt of a NiagaraStation. To
see the PointManager, right-click on a Points device extension and select Views > Point Man-
ager
. For details, see “About the Point Manager” on page 121.
email-EmailAccountManager
email Manager allows you to view email accounts. It is available on the
help-BajadocViewer
The BajadocViewer Plugin provides the ability to navigate and browse Baja reference documentation. Baja reference documentation includes both Java API details as well as Baja slot documentation. It shows documentation for the following:
•
•
•
•
• Constructors
• Methods
• Fields
In order to view Bajadoc, either right-click on a Bajadoc file and select Views > Bajadoc
Viewer
or select Bajadoc On Target from the main Help Menu or popup Menu.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
421
help-BajadocViewer
See Object Model in the Developer Guide for more information.
Chapter 14 — Plugin Guides
Notes
BajadocViewer Menus
The BajadocViewer menu functions include:
• Show Baja Only
• Flatten Inheritance
Show Baja Only
This option allows you to view only the documentation for slots (Properties, Actions, and Topics).
When it is set to false, documentation on the Java constructors, methods and fields is also displayed.
Flatten Inheritance
This option allows you to flatten the inheritance hierarchy into a single set of documentation. When it is false only the Java members and Baja slots declared in the specified class are displayed. When it is set to true all the Java members and Baja slots inherited from super classes are also shown.
Subclasses
Subclasses provides a subclass tree of all that are subclassed from this item.
Properties
Properties represent a storage location of another Niagara object. Flags are boolean values which are stored as a bitmask on each slot in a Baja Object. Some flags apply to all slot types, while some only have meaning for certain slot types.
Table 1 Flags
Flag
readonly transient hidden summary t r
Char
P
Applies
h s
P
P,A,T
P
Description
The readonly flag is used to indicate slots which are not accessible to users.
Transient properties do not get persisted when saving a object graph to the file system. Transient properties are usually also readyonly, unless they are designed to be a linkable input slot.
Hidden slots are designed to be invisible to the user, and exist only for
Java developers. User interfaces should rarely display hidden slots.
Summary properties are the focal points of any given BComponent. This flag is used by user interface tools to indicate primary properties for display. This might be as a columns in a Table, or as a glyph in a graphical programming tool.
422
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides help-BajadocViewer Notes async
Flag
noExecute defaultOn-
Clone confirmRequired operator userDefined1 userDefined2 userDefined3 userDefined4 a
Char
A
Applies
x d c c
3
4
1
2
P
P
A
P,A,T
P,A,T
P,A,T
P,A,T
P,A,T
Description
By default Action are invoked synchronously on the callers thread. By using the async flag on an Action, invocations are coalesced and executed asynchronously at some point in the near future on the engine's thread.
No execute properties prevents start/stop from recursing on properties with with this flag set.
Specifies that when an object is cloned via the newCopy() method these properties retain their default value, not the clone source's value.
When the Action is invoked by a user, a confirmation dialog must be acknowledged before proceeding.
This makes a slot as operator security level. By default when this flag is clear, the slot is an admin security level.
User defined.
User defined.
User defined.
User defined.
See Flags.bajadoc for more information. See
for information on configuring flags on properties.
Actions
An Action is a slot that specifies behavior which may be invoked either through a user command or by an event. Actions provide the capability to provide direction to Components. They may be issued manually by the operator or automatically through links. Actions can be issued by Right-clicking on the Component. The Component bajadoc provides a complete list of Actions available for each Component. Typical Actions include:
• Manual actions are available based on Component type. The following are commonly available:
• Auto (BooleanWritable, NumericWritable and EnumWritable)
• Active (BooleanWritable)
• Inactive (BooleanWritable)
• Override (NumericWritable and EnumWritable)
Each of the above actions is issued to the priorityArray of the Component at level 8 (Manual
Operator).
• Many other Actions are available on other Components. Each Action available for a Component is listed in the Actions sect2 of the Component bajadoc.
Topics
Topics represent the subject of an event. Topics contain neither a storage location, nor a behavior.
Rather a topic serves as a place holder for a event source.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
423
history-DatabaseMaintenance
history-DatabaseMaintenance
Chapter 14 — Plugin Guides
Notes
The DatabaseMaintenance allows you to maintain the histories in a station from the Workbench. You can Clear Old Records, Clear All Records or Delete Histories.
history-HistoryChart
The HistoryChart is a view that allows you to view and configure charts of histories. Any point
History can be charted by double-clicking it in the History Service.
history-HistoryChartBuilder
The HistoryChartBuilder is a view that allows you to view and configure charts of one or more histories. Add a history by double-clicking or dragging into the configuration area. For any chart, you can specify a Time Range, Title, and whether to show grid lines. Each history has a selectable Chart Type of either Line or Discrete Line. After you Build a chart, you can Save it.
history-HistoryEditor
The HistoryEditor allows you to view and query a History in a Station.
The HistoryEditor allows you to Hide or Unhide selected records.
history-HistoryExtManager
The HistoryExtManager allows you to view histories. It is a view on the
You can Double-click the Point, Extension or History Name to go to each directly. Enabled and
State are also shown. If a History is disabled, it is purple. If a History is not collecting, it is orange.
See BHistoryExtManager.bajadoc for more information.
HistoryExtManager Menus
•
The Workbench main menu functions are available. When the HistoryExtManager is visible, the following HistoryExtManager menu function is also available:
HistoryExtManager Enable Collection
•
HistoryExtManager Disable Collection
•
HistoryExtManager Rename History
•
HistoryExtManager Default History Name
HistoryExtManager Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
When the HistoryExtManager is visible, additional toolbar buttons include:
424
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides history-HistorySummaryView Notes
•
•
•
HistoryExtManager Enable Collection
HistoryExtManager Disable Collection
HistoryExtManager Rename History
HistoryExtManager Enable Collection
Enable Collection allows you to enable history collection.
HistoryExtManager Disable Collection
Disable Collection allows you to disable history collection.
HistoryExtManager Rename History
Rename History allows you to disable history collection.
HistoryExtManager Default History Name
Default History Name allows you to use the default history name.
history-HistorySummaryView
The HistorySummaryView allows you to view the summary information about a History from the Workbench.
history-HistoryTable
The HistoryTable is a view that allows you to view tables of histories. The selected entries are shown as timestamp, trendFlags, status and value in each row of the Table.
You can resize columns in the HistoryTable. If you move the cursor over the line between columns, it will change to a resize cursor. You can then drag the line to the desired size.
If want to reorder the columns in the HistoryTable, drag the column header to a new location.
Query
Query lets you select the period for the query. Selections include:
• Time Range
• Today
• Yesterday
• Last Week
• Last 7 Days
• Last Month
• Last Year
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
425
html-WbHtmlView
Chapter 14 — Plugin Guides
Introduction
• Month-to-date
• Year-to-date
Filter
Filter lets you use the filter you have configured for the data in the Table.
Filter Config
Filter lets you configure the filter for the data in the Table.
html-WbHtmlView
•
•
•
Introduction
The WbHtmlView allows you to view HTML files.
WbHtmlView Menus
The Workbench main menu functions are available.
WbHtmlView Toolbar
HTML Support
HTML Tags
The WbHtmlView attempts to ignore mismatched or missing Tags. It can parse any HTML, no matter how badly messed up the Tags are, although it might do a pretty bad job of rendering the results. It does simplistically attempt to repair missing <p>, but other problems are solved by ignoring Tags.
Warnings will appear on the command line showing its best guess as to what the problem was. Valid tags include:
• a - anchor Ex:<a href="#fragment">Title<a> and <a name="fragment">Title<a>
(Attributes href and name)
• applet - not supported
• b - bold text style Ex: <b>bold text<b>
• body - document body
• br - forced line break
• code - computer code fragment
426
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides html-WbHtmlView HTML Support
• col - not supported
• colgroup - not supported
• dd - definition description
• div - not supported
• dl - definition list
• dt - definition term
• em - emphasis Ex: <em>emphasis text<em>
• font - local change to font (Attributes Color, name and size)
• h1 - heading Ex:<h1 class='title'>Title<h1>
• h2 - heading
• h3 - heading
• h4 - heading
• h5 - heading
• h6 - not supported
• head - document head
• hr - horizontal rule
• html - document root element
• i - italic text style
• img - embedded
ℑ Ex: <img src="../doc/icons/x16/home.png"> An <img> without an align attribute is treated as an 'inline'
ℑ. An align of left or right causes text to flow around the
ℑ.
• li - list item
• link - a media-independent link Ex:<link rel='StyleSheet' href='module:// bajaui/doc/style.css' type='text/css'/>
• meta - not supported
• object - not supported
• ol - ordered list
• p - paragraph Ex:<p class='note'>Note<p>
• pre - preformatted text
• span - not supported
• style - not supported
• table - table (Attributes align, border, bordercolor, cellpadding, cellspacing and width)
• tbody - not supported
• td - table data cell supports ALIGN (left, right, and center), BGCOLOR, COLSPAN, ROWSPAN and WIDTH
• tfoot - not supported
• th - table header cell supports ALIGN (left, right, and center), BGCOLOR, COLSPAN, ROWS-
PAN and WIDTH
• thead - not supported
• title - document title
• tr - table row supports ALIGN (left, right, and center)and BGCOLOR
• tt - teletype or monospaced text style
• ul - unordered list
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
427
html-WbHtmlView
Chapter 14 — Plugin Guides
HTML Support
HTML Attributes
HTML Elements have associated properties, called attributes, which may have values. Attribute/ value pairs appear before the final ">" of an element's start tag. Valid attributes include:
• align - vertical or horizontal alignment Deprecated; elements: img, object? values: bottom, left
, middle, right or top.
• align - table position relative to window Deprecated; elements: table; values: center, left or right
• align - align, text alignment Deprecated; elements: div?, h1?, h2?, h3?, h4?, h5?, h6?, p; values: center
, justify, left or right
• align - alignment; elements: col?, colgroup?, tbody?, td, tfoot?, th, thead?, tr; values: center, char
, justify, left or right
• bgcolor - background Color Deprecated; elements: h1, h2, h3, h4, h5, h6?, p, td, th, tr
• border - controls frame width around table; elements: table
• cellpadding - spacing within cells; elements: table
• cellspacing - spacing between cells; elements: table
• class - class name or set of class names for stylesheets; elements: most elements
• color - text Color Deprecated; elements: font, h1, h2, h3, h4, h5, h6?, p, pre, td?, th?, tr?
• colspan - number of cols spanned by cell; elements: td, th
• content - associated information; elements: meta?
• href - URI for linked resource; elements: a, link
• id - name to an element; elements: most elements
• lang - Language Code; elements: most elements not supported
• name - named link end; elements: a
• name - metainformation name; elements: meta?
• rel - forward link types; elements: link; values: stylesheet
• rowspan - number of rows spanned by cell; elements: td, th
• size - size of font; elements: font; value: fixed 1-7 or relative -7 to +7
• summary - purpose/structure for speech output; elements: table
• type - advisory content type; elements: link; values: text/css
• width - table width; elements: table
Character Entity References
Character Entity References are supported including the following:
• & - ampersand &
• ' - apostrophe '
• © - copyright ©
• > - greater than >
• “ - double quotation, left “
• ‘ - single quotation, left ‘
• < - less than <
• — - em dash —
• - non breaking space " "
• – - en dash –
• ” - double quotation, right ”
428
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides html-WbHtmlView Stylesheet Support
• ’ - single quotation, right ’
• " - quotation mark "
• ® - registered trademark ®
• ™ - trademark ™
Stylesheet Support
Introduction
Stylesheets are supported using a link in the header as follows:
<head>
<title>Sample<title>
<link rel='StyleSheet' href='module://bajaui/doc/style.css' type='text/css'/>
<head>
See the default stylesheet used for Niagara developer documentation: module://bajaui/doc/style.css or the CSS stylesheet used for this document at docbook.css.
Pseudo-classes and Pseudo-elements
Anchor pseudo-classes include:
• A:link unvisited links unsupported
• A:visited visited links unsupported
• A:active active links unsupported
CSS1 Properties
Stylesheet elements supported include:
• background - The 'background' property is a shorthand property for setting the individual background properties (i.e., 'background-color', 'background-image', 'background-repeat', 'background-attachment' and 'background-position') at the same place in the style sheet.
• background-attachment unsupported
• background-color - This property sets the background Color of an element.
• background-image unsupported
• background-position unsupported
• background-repeat unsupported
• border unsupported
• border-bottom unsupported
• border-bottom-width unsupported
• border-color unsupported
• border-left unsupported
• border-left-width unsupported
• border-right unsupported
• border-right-width unsupported
• border-style unsupported
• border-top unsupported
• border-top-width unsupported
• border-width unsupported
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
429
html-SpyViewer
Chapter 14 — Plugin Guides
Stylesheet Support
• clear unsupported
• color - This property describes the text Color of an element (often referred to as the foreground
Color).
• display unsupported
• float unsupported
• font unsupported
• font-family unsupported
• font-size unsupported
• font-style unsupported
• font-variant unsupported
• font-weight unsupported
• height unsupported
• letter-spacing unsupported
• line-height unsupported
• list-style-image unsupported
• list-style-position unsupported
• list-style-type unsupported
• margin unsupported
• margin-bottom unsupported
• margin-left unsupported
• margin-right unsupported
• margin-top unsupported
• padding unsupported
• padding-bottom unsupported
• padding-left unsupported
• padding-right unsupported
• padding-top unsupported
• text-align
• text-decoration unsupported
• text-indent unsupported
• text-transform unsupported
• white-space unsupported
• width unsupported
• word-spacing unsupported
html-SpyViewer
SpyViewer allows you to view diagnostic information about the system. It contains the following:
• sysinfo - sysinfo provides system information.
• stdout - stdout provides access to standard output.
• systemProperties - systemProperties provides access to system properties.
• logSetup - logSetup allows you to config your log severities dynamically. There is also an option to flush the current settings to log.properties.
• sysManagers - sysManagers provides information on managers. These include:
430
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides ldap-LdapUserManager Stylesheet Support
• registryManager
• schemaManager
• componentNavEventManager
• moduleManager
• engineManager
• leaseManager
• serviceManager
• licenseManager
• stationManager
• navSpace - provides information on the navSpace.
• userinterface - if System - userInterface provides information on the user interface framework.
• fox - fox provides information on fox client and server sessions.
ldap-LdapUserManager
LdapUserManager allows you to manage Ldap users. You can add new users and edit existing users.
niagaraDriver-NiagaraHistoryExportManager
NiagaraHistoryExportManager provides a view of NiagaraHistoryDeviceExt
. To see the view,
right-click on a NiagaraHistoryDeviceExt
in a Station and select Views > Niagara His-
tory Export Manager
.
niagaraDriver-NiagaraHistoryImportManager
NiagaraHistoryImportManager provides a view of NiagaraHistoryDeviceExt
. To see the view,
Right-click on a NiagaraHistoryDeviceExt
in a Station and select Views > Niagara His-
tory Import Manager
.
niagaraDriver-NiagaraPointManager
NiagaraPointManager provides an overview of the Proxy points mapped into the PointDevice-
•
Right-click on a NiagaraPointDeviceExt
in a Station and select Views > Niagara Point
Manager
.
Learn
Learn allows you to Discover other points that are available. Once you press Learn, you can press Discover to start the BQL Builder to select the types of points that you would like to review. You can then Add or Match points so that they are available in your Database.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
431
niagaraDriver-NiagaraScheduleExportManager
Chapter 14 — Plugin Guides
Stylesheet Support
Paste As ProxyPoint
In order to link two Components in different stations, follow these steps:
1. Right-click on the Component in the originating Station and select Copy.
2. From the PointSummary View on NiagaraPointDeviceExt (usually Points under station in NiagaraNetwork) in the receiving Station, Right-click on the background and select Paste As
ProxyPoint
or press Paste as ProxyPoint. This will pop-up the Paste As Proxy
Dialog.
3. Double-click on the property to link (often out). This will cause the Source and Proxy Point to be visible on the right.
4. Press Ok.
If you change the Proxy Point Type to a Writable type and select one of the priority levels, you can make it commandable.
Create Graphics Page
Create Graphics Page starts a Wizard to guide you through creation of a graphics page.
niagaraDriver-NiagaraScheduleExportManager
The NiagaraScheduleExportManager Plugin allows you to Discover and view Stations. The
NiagaraScheduleExportManager is a view on the NiagaraNetwork in a Station.
niagaraDriver-NiagaraScheduleImportManager
The NiagaraScheduleImportManager Plugin allows you to Discover and view Stations. The
NiagaraScheduleImportManager is a view on the NiagaraNetwork in a Station.
niagaraDriver-ServerConnectionsSummary
The Server Connections Summary is the default view of the ServerConnections slot in the Niagara Fox Service, under the NiagaraNetwork. It provides a table listing current client connections to the station’s Fox server (station-to-station connections are not included).
Note: The main usage of this view is to perform a Force Disconnect action (right-click access) on any Fox server session shown. In some station maintenance scenarios, this may be helpful.
Included in connections summary table are the following columns:
• Address
IP address of the Fox client connected to the station, along with its remote TCP port.
• User
Station user account used for authentication.
• Connection Time
Timestamp of when the Fox connection occurred.
• Application
Client software used to access the station (for example, Niagara Workbench 3.0.76).
432
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides niagaraDriver-StationManager Stylesheet Support
From the table, to see more details on any Fox server session, double-click an entry. The view changes to show the property sheet of that SessionN, with status slots of historical information, including connect and disconnect entries.
Access the Server Connections Summary from the property sheet of the NiagaraNetwork.
Expand the Fox Service, then click the Server Connections slot.
niagaraDriver-StationManager
The StationManager Plugin allows you to Discover and view Stations. The StationManager is a view on the NiagaraNetwork in a Station.
program-BatchEditor
The BatchEditor allows you to modify a common slot for a set of BObjects. It is a view on the
program-ProgramEditor
Introduction
The ProgramEditor Plugin provides the ability to view and edit
Components. To view,
Right-click a Program and select ProgramEditor. It shows
,
and
ProgramEditor Edit
Edit allows you to edit the onExecute, onStart, onStop and freeForm methods. An example from the demo Database follows:
BStatusNumeric inA = getInA();
BStatusNumeric inB = getInB();
BStatusNumeric out = getOut(); out.setValue( inA.getValue() + inB.getValue() );
ProgramEditor Slots
Slots allows you to view and change the slots of the program component. It includes Slot, #,
Name
, Display Name, Definition, Flags and Type for each slot. See
more information on slots.
ProgramEditor Imports
Imports allows you to view the Modules that have been imported.
It also allows the following:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
433
program-ProgramEditor
Chapter 14 — Plugin Guides
Stylesheet Support
•
•
•
ProgramEditor ImportType
ImportType allows you to import a new type.
ProgramEditor ImportPackage
ImportPackage allows you to import a new type.
ProgramEditor Remove
Remove allows you to import a new type.
ProgramEditor Source
Source allows you to view and edit the source of the program component. The editor supports special Color coding for Java Files. An example from the demo Database follows:
/* Auto-generated ProgramImpl Code */ import java.util.*; /* java Predefined*/ import javax.baja.sys.*; /* baja Predefined*/ import javax.baja.status.*; /* baja Predefined*/ import javax.baja.util.*; /* baja Predefined*/ import com.tridium.program.*; /* program Predefined*/ public class ProgramImpl extends com.tridium.program.ProgramBase
{
////////////////////////////////////////////////////////////////
// Getters
//////////////////////////////////////////////////////////////// public BStatusNumeric getOut() { return (BStatusNumeric)get("out"); } public BStatusNumeric getInA() { return (BStatusNumeric)get("inA"); } public BStatusNumeric getInB() { return (BStatusNumeric)get("inB"); }
////////////////////////////////////////////////////////////////
// Setters
//////////////////////////////////////////////////////////////// public void setOut(javax.baja.status.BStatusNumeric v) { set("out", v); } public void setInA(javax.baja.status.BStatusNumeric v) { set("inA", v); } public void setInB(javax.baja.status.BStatusNumeric v) { set("inB", v); }
////////////////////////////////////////////////////////////////
// onExecute
//////////////////////////////////////////////////////////////// public void onExecute() throws Throwable
434
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides program-ProgramEditor
{
BStatusNumeric inA = getInA();
BStatusNumeric inB = getInB();
BStatusNumeric out = getOut();
}
} out.setValue( inA.getValue() + inB.getValue() );
Stylesheet Support
•
•
•
•
•
•
•
•
•
ProgramEditor Menus
The Workbench main menu functions are available. When the ProgramEditor is visible, the following
ProgramEditor menu function is also available:
Ctrl + A
Delete Delete
Ctrl + R
Reorder
F9
Ctrl + F9
ProgramEditor Toolbar
•
•
•
•
•
•
The Workbench toolbar contains navigation and editing buttons as described in
Find F5
Replace F6
F9
Ctrl + F9
Console Prev (?need to find SearchConsolePrev.html source?)
Console Next (need to find SearchConsoleNext.html source)
ProgramEditor Compile & Save
CompileSave allows you to compile and save the source of the program component. The shortcut is F9.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
435
program-RobotEditor
Chapter 14 — Plugin Guides
Stylesheet Support
ProgramEditor Compile
Compile allows you to compile the source of the program component. The shortcut is Ctrl + F9.
program-RobotEditor
The RobotEditor is used to write Robots that can be run via the ProgramService
.
•
•
RobotEditor Menus
The Workbench main menu functions are available. When the RobotEditor is visible, the following
RobotEditor menu function is also available:
Ctrl + F9
F9
RobotEditor Toolbar
•
•
•
•
•
•
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38. When the RobotEditor is visible, additional toolbar buttons include:
Find F5
Replace F6
Ctrl + F9
F9
Console Prev (?need to find SearchConsolePrev.html source?)
Console Next (?need to find SearchConsoleNext.html source?)
RobotEditor Compile
Compile allows you to compile the source of the Robot component. The shortcut is Ctrl + F9.
RobotEditor Compile & Run
Compile& Run allows you to compile and run the source of the Robot component. The shortcut is F9.
pxEditor-PxEditor
The PxEditor provides tools for creating and editng px files. The px editor is the view that is used to create graphic presentations in Niagara AX. For more details about the px editor, refer to the following:
•
•
436
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides raster-RasterEditor Stylesheet Support
•
•
raster-RasterEditor
The RasterEditor is used to edit bitmapped
ℑ files: GIF, JPEG, PNG.
RasterEditor Menus
The Workbench main menu functions are available. When the RasterEditor is visible, the following
View menu functions are also available:
•
•
•
•
•
•
•
•
•
•
•
Shift + V
•
Ctrl + Shift + V
When the RasterEditor is visible, the following Mode menu functions are also available:
RasterEditor Toolbar
•
•
•
•
•
•
•
The Workbench toolbar contains navigation and editing buttons as described in
When the RasterEditor is visible, additional toolbar buttons include:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
437
raster-RasterEditor
Chapter 14 — Plugin Guides
Stylesheet Support
•
•
OriginalView
Go to the original view. The shortcut is Shift + N.
Fit To Window
Adjust scale to fit in window. The shortcut is Shift + F.
ImageInformation
View ImageInformation. The shortcut is Shift + I.
ViewPaletteTransparency
View ViewPaletteTransparency. The shortcut is Shift + V.
SetPaletteTransparency
View SetPaletteTransparency. The shortcut is Ctrl + Shift + Z.
Zoom
Left click zooms
ℑ in. Right click zooms ℑ out. The shortcut is Ctrl + Z.
Selection
select a region of the
ℑ. Hold down SHIFT to add a region. Hold down CTRL to remove a region. The shortcut is Ctrl + S.
Dropper
View or select a Color in the
ℑ. The shortcut is Ctrl + D.
PaintBrush
Paint on
ℑ. The shortcut is Ctrl + P.
FloodFill
Fill a region with a Color and/or pattern. The shortcut is Ctrl + F.
438
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides raster-RasterViewer Stylesheet Support
Text
Add text to
ℑ. The shortcut is Ctrl + T.
Shape
Paints shapes such as lines, rectangles, and ellipses. The shortcut is Ctrl + R.
raster-RasterViewer
The RasterViewer is used to display bitmapped
ℑ files: GIF, JPEG, PNG. It displays the ℑ in the main window with Format and
ℑ Size at the bottom.
rdb-RdbmsHistoryExportManager
The RdbmsHistoryExportManager allows you to export records in an Rdbms database as Niagara histories. It is a view on the Histories extension of an Rdbms database, for example
Db2HistoryDeviceExt , OracleHistoryDeviceExt , and SqlServerHistoryDeviceExt
.
rdb-RdbmsSessionView
The RdbmsSessionView provides a view for a session to a relational database.
schedule-CalendarScheduler
The CalendarSchedule view is used to define calendar days in a CalendarSchedule
. Typically, calendar days represent holidays.
Use the Add button to add a calendar day (or range of days). Each entry requires a unique name, a date type, and other specific calendar data criteria. Other controls in the CalendarSchedule allow you to edit priority, rename, or delete calendar date entries.
schedule-CurrentDaySummary
The CurrentDaySummary view is available on
BooleanSchedule , EnumSchedule , Numeric-
components. It provides a simple linear listing of all schedule events for the current day, moving left-to-right from 0-to-24 hours.
schedule-Scheduler
The Scheduler allows you to view and edit schedule components, namely BooleanSchedule
,
EnumSchedule , NumericSchedule , and
StringSchedule . Each of these components has a Sched-
uler view. The only difference between these different schedules is the output type.
“Weekly Scheduler view” on page 299.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
439
schedule-TriggerScheduler
Chapter 14 — Plugin Guides
Weekly Schedule
There are four major elements in the Scheduler interface, separated by tabs in the view:
•
•
•
•
Weekly Schedule
Defines the regular (repeating) day-of-week schedule events for each day of the week.
Creating A Time Range Right-click and drag down in the slider column for desired the day.
Deleting A Time Range Click on a time range and press the delete or backspace key.
Editing A Time Range Time can be adjusted four ways: Dragging the top, bottom or center of a time range, or using the fine grained start and finish editors. To fine-tune a time range click on a time range then adjust the times in the editors to the left.
IMPORTANT - The finish time is exclusive; it is the first non-effective time after the effective period.
The start time is inclusive.
Output is assigned to each time range and can be edited just below the time editors on the left.
Special Events
Special events override (yet intermingle with) events in the normal weekly schedule.
Adding, Prioritizing, Renaming, and Deleting. Use the controls at the bottom for this purpose
Editing At least one time range must be present for an exceptional to work. Output is assigned to the time ranges. The slider operates exactly like the normal weekly sliders.
Properties
Define the schedule’s effective period, default output, facets, and whether automatic special-event cleanup occurs.
Default Output
This is the value of the schedule's output when no normal or exceptional schedule is effective.
Cleanup Special Events
If set to true (default), special events that have expired are removed from the view after nn days?
Summary
Shows months with selectable days, including all schedule event activity for any day selected.
schedule-TriggerScheduler
The TriggerSchedule view is used to define schedule events in a
440
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides timesync-TimeSyncManager WireSheet Menus schedules are defined by combination of calendar day (or days) and trigger event time(s), including time ranges, each with a repeating interval.
Use the bottom-left Add button to add a scheduled day (or range of days). Each entry requires a unique name, a date type, and other specific calendar data criteria. Other controls in the Trigger-
Schedule allow you to edit priority, rename, or delete calendar day entries.
Use the bottom-right Add button to add trigger events to any selected scheduled day(s). Use the time selector to specify the individual trigger event. Use the Range controls to define a time range with repeating interval for trigger events to occur.
timesync-TimeSyncManager
The TimeSyncManager is used to display the status of
TimeServer s. It displays Server Name,
Poll Local Time and Poll Server Time.
wiresheet-WireSheet
The WireSheet view shows the contents of this Component. It can be used on a Component of a running Station or a Component in a Bog File. If in a running station, it is active and real-time updates are provided. In order to command or select a different view of the item, you may Right-click to get the popup menu.
WireSheet Menus
The WireSheet includes the following menus:
•
•
•
•
WireSheet Main Menu
•
The WireSheet main menu functions are available. When the *wiresheet; is visible, the following
WireSheet
menu functions are also available:
Delete Links
•
•
•
•
•
WireSheet Component Menu
If you Right-click any Component in the WireSheet, you can choose from the following:
• views - Go to any of the views of the Component.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
441
wiresheet-WireSheet
•
•
•
•
•
•
•
•
•
• Actions - Perform any of the Actions on the Component.
Cut Ctrl + X
Copy Ctrl + C
Paste Ctrl + V
Duplicate Ctrl + D
Delete Delete
Rename
Reorder
Chapter 14 — Plugin Guides
WireSheet Menus
WireSheet Background Menu
If you Right-click the Background of the WireSheet, you can choose from the following:
•
•
•
• Cut Ctrl + X
Copy Ctrl + C
Paste Ctrl + V
Duplicate Ctrl + D
•
• Delete Delete
Delete Links
•
•
•
WireSheet Link Menu
If you Right-click any link in the WireSheet, you can choose from the following:
•
•
•
• Cut Ctrl + X
Copy Ctrl + C
Paste Ctrl + V
Duplicate Ctrl + D
•
• Delete Delete
Delete Links
•
•
442
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides wiresheet-WireSheet WireSheet Menus
•
•
WireSheet Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38. When the WireSheet is visible, additional toolbar buttons include:
Delete Links
Delete Links
Delete Links may be accessed from the Menu under Edit or from the toolbar. It allows you to eliminate the selected link(s). You can Delete Links only in the WireSheet.
Pin Slots
Pin Slots provides the capability to make Properties of a Component visible in the WireSheet view of the Component. Right-click on the Component and select Pin Slots. This will bring up the Pin Slots Dialog.
The selected Properties are now visible in the WireSheet.
Arrange
Arrange allows you to arrange the items in the WireSheet. You can Arrange All or
Arrange Selection
.
Select All
Select All allows you to select all items in the WireSheet.
Show Thumbnail
Show the thumbnail view in the upper right corner of the WireSheet. This allows you to toggle whether this function is enabled. This function may be accessed from the Menu under WireSheet.
It allows you to display a thumbnail of the WireSheet view in the corner of the WireSheet. You can use the thumbnail to move around the WireSheet by Dragging the shadded area in the thumbnail. You can also hold down the Ctrl key and move the thumbnail around the WireSheet to keep it out of your way.
Show Grid
When enabled, the Grid is displayed in the background of the WireSheet. This helps you to align
Components when you move them. You may control whether the Grid layer is enabled or visible from the WireSheet Menu or the Tools > Options Menu. This allows you to toggle whether this function is enabled.
Show Status Colors
Show the StatusColors. This allows you to toggle whether this function is enabled. This function may
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
443
wbutil-CategoryBrowser
Chapter 14 — Plugin Guides workbench-PrintDialog be accessed from the Menu under WireSheet. It allows you to display StatusColors in the WireSheet.
workbench-PrintDialog
Print provides the capability to print the WireSheet. The WireSheet will remain fixed at logical size of 100 x 100 "blocks". Printing will scale the WireSheet drawing to fit the page size (minus header and footer). Thus if you build your WireSheet logic in the top left corner, you will get a large scale for your print out. If you use the entire WireSheet down to the bottom right corner, you will get a much smaller scale for your print out. Margins are 1" for left and 1/2" for top, bottom, and right. A standard header is included which displays container's reference and current date. A future version will create a footer listing external links and knobs.
workbench-CompositeEditor
Composite Editor provides the capability to expose child slots of a Component as slots on the parent. Right-click on the Component and select Composite Editor. This will bring up the
Composite Editor Dialog. The selected Properties are now visible in the WireSheet.
workbench-ExportDialog
Export provides the capability to Export views. You can Export any Table found in the workbench (anything built with bajaui:Table). The Table options menu (that little button to the right of the header), includes a Print and Export command. These commands allow you to Export the Table to PDF, HTML, or CSV (
ExcelFile ). The Export uses the current sort order and visible columns you
have displayed.
wbutil-CategoryBrowser
CategoryBrowser is the default view of a station’s CategoryService. Use it to assign objects in the station into categories. This view presents an expandable tree table where the table columns are the available categories, and rows are the categorizable objects.
• Yellow rows are objects explictly assigned into a category.
• Dimmed rows represent objects inheriting their parent’s categories.
Note: For any object except the three root objects: station (components), file, and history, you can check to inherit its parent’s categories. For root objects, you must select at least one category.
For any component, you can alternately use its
Browser” on page 290 for more details on this CategoryService view.
wbutil-CategoryManager
CategoryManager is a view on the CategoryService that allows you to create, enable and delete categories. Categories are used by the security model, as well as for future features. You can then use the
CategoryBrowser view to centrally assign objects to categories. Or, at the individual compo-
444
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides wbutil-CategorySheet workbench-ExportDialog nent level, use a component’s
CategorySheet view to assign it to categories.
You can assign an object to many categories at the same time. Each object stores its own categories.
wbutil-CategorySheet
CatgegorySheet is used to assign a component into one or more categories (or configure it to
“CategorySheet” on page 292 for more
details on this component view.
wbutil-PermissionsBrowser
PermissionsBrowser is an available view on the UserService, for reviewing the permissions
any user has on each object. It provides an expandable tree table (similar to the CategoryBrowser
view of the CategoryService). In the PermissionsBrowser, columns represent station user accounts, and rows are the objects in the station, with each table cell showing user permissions.
• Yellow rows are objects explictly assigned with permissions.
• Dimmed rows represent objects inheriting their permissions.
Double-click a cell to bring up the permissions dialog for that user (unless user has super user rights).
This allows you to globally change that user’s permission levels for any category in the station.
See “Permissions and security”
wbutil-ResourceEstimator
The Resource Estimator tool allows you to estimate station resources based a number of variables, which you enter in various fields. It is one of several tools in Workbench’s Tools menu.
wbutil-TodoList
The Todo List tool allows you to enter, summarize, group, and prioritize pending Workbench tasks. It is one of several tools in Workbench’s Tools menu.
wbutil-UserManager
The UserManager is the primary view of the UserService. You use it to add, edit, and delete
users for accessing the station. See “Users and security” on page 273 for details on how users
affect security, and “UserManager” on page 283 for more details on this UserService view.
For an overview on the station security model, see
“Security model overview” on page 271.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
445
workbench-CollectionTable
Chapter 14 — Plugin Guides workbench-ExportDialog
workbench-CollectionTable
The CollectionTable allows you to view tables. One way to create a Table is through a BQL collection like: local:|fox:|station:|slot:/ControlObjects|bql:select displayName,type, out, facets from control:ControlPoint
The Table options menu (that little button to the right of the header), allows you to Reset Column
Widths, Print and Export.
workbench-DirectoryList
The DirectoryList Plugin provides a listing of the subdirectories and files found in a given Directory. If you Double-click an item, you will go to its default view.
Files will be displayed with an icon based on file type.
DirectoryList Menus
•
•
•
•
•
•
•
The Workbench main menu functions are available. When the DirectoryList is visible, the following popup menu functions are also available:
• Views - show the view menus for the Component.
• Actions - Perform any of the Actions on the Component.
• New - Create a new file of standard types (if a Directory).
Cut Ctrl + X
Copy Ctrl + C
Paste Ctrl + V
Duplicate Ctrl + D
Delete Delete
Rename
Reorder
DirectoryList Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38.
Refresh
Refresh allows you to synchronize the cached components with the actual file system.
New
New allows you to make a new Folder or File in the selected Folder of these types:
446
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-HexFileEditor workbench-ExportDialog
•
•
•
•
•
•
•
New Folder allows you to make a new Folder in the selected Folder.
BogFile.bog
HtmlFile.html
JavaFile.java
NavFile.nav
PrintFile.print
TextFile.txt
workbench-HexFileEditor
The HexFileEditor allows you to view hexadecimal files. It provides a binary view of a file's contents.
workbench-JobServiceManager
The JobServiceManager is the default view on a station’s
JobService . It provides a table listing
of all
Job s executed by the station since the last station start. Order is oldest job at top, most
recent job at bottom.
To see details on any job, click the “>>” button next to its status descriptor. A popup Job Log dialog displays all the interim steps about the job, including timestamps and relevant messages.
To dispose of any job, click the close (“X”) button to remove it from the station.
Note: All jobs in a station are cleared upon a station restart.
workbench-LinkSheet
The LinkSheet allows you to view and delete links. It provides a view of the links on a Componentand Go to the link.
•
•
LinkSheet Main Menu
The Workbench main menu functions are available. When the LinkSheet is visible, the following
LinkSheet
menu functions are also available:
LinkSheet Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38. When the LinkSheet is visible, additional toolbar buttons include:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
447
workbench-ModuleSpaceView
Chapter 14 — Plugin Guides
OptionsButton
•
GoTo
Go To goes to the selected item.
workbench-ModuleSpaceView
The ModuleSpaceView allows you to view Modules.
OptionsButton
The Options Button provides the ability to toggle columns on and off like Mozilla does.
workbench-NavContainerView
NavContainerView is a default listing of nav children.
workbench-NavFileEditor
The NavFileEditor allows you to view and edit Nav Files. It provides a view of the Pages in the station and a view of the Nav Tree. You can drag Pages to the Nav Tree to add them to the Nav
File. The name and Ord are shown at the bottom of the window.
Service . See BNavFile.bajadoc for more information.
workbench-PropertySheet
The Property Sheet shows all the user visible Properties of the Component. This view also lets you change any Properties that you have authority to change. It can be used on a Component of a running Station or a Component in a Bog File.
In order to see Properties of Components in the PropertySheet, press the + sign to expand the
Component.
When you want to enter a URL, you can Copy the Component or URL and Paste it into the Proper-
tySheet
using the Paste shortcut Ctrl + V.
When a Property has been changed, its symbol will become red until you press Save.
PropertySheet Menus
The Workbench main menu functions are available. If you Right-click any Component in the PropertySheet, you can choose from the following:
• Views - show the view menu for the Component.
• Actions - Perform any of the Actions on the Component.
448
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-PropertySheet Config Flags
•
•
•
•
•
•
•
• Cut Ctrl + X
Copy Ctrl + C
Paste Ctrl + V
Duplicate Ctrl + D
Delete Delete
Rename
Reorder
PropertySheet Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38.
Config Flags
Configure Flags on the Component. This is available on Properties. Right-click a Property to view the Config Flags Dialog.
See Flags.bajadoc for more information.
Links
Links provide the mechanism to dynamically attach Components. They allow you to attach an output Property of one Component to an input Property of another Component. The links are visible in the Property Sheet of the Component. Links show whether they are direct or indirect and their source Property.
In order to view the Properties of the link, Left-click the + plus sign on the Component to expand it.
Each link shows the following:
• Link Type and source
• Source Ref - This is the linked Component.
• Source Slot Name - This is the linked Component's property.
• Target Slot Name - This is the current Component's property.
• Enabled - This shows whether the link is currently enabled.
See for more information on creating links.
OrdChooser
In order to select an Ord instead of typing it, you can use one of the Ord editors. They include:
•
•
•
•
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
449
workbench-PropertySheet
Chapter 14 — Plugin Guides workbench:FileOrdChooser
•
Once you have selected an editor, you can use the to the right of the selection box. It will present the selected editor.
workbench:FileOrdChooser
In order to select a file Ord instead of typing it, you can use the FileOrdChooser.
You can select FileSpaces, Bookmarks and directories and files. In addition toolbar functions are provided including:
Back
Back moves back to the previous view.
Uplevel
Uplevel moves up one level in tree.
Home
Home moves up one level in tree.
New Folder
New Folder creates a new Directory.
ListView
ListView allows you to use the list view.
DetailsView
DetailsView allows you to use the details view.
Bookmarks
You can press the Bookmarks button to add the selection to Bookmarks.
Show/Hide Preview
Show/Hide Preview toggles whether the preview pane is visible.
workbench:DirectoryOrdChooser
In order to select a Directory Ord instead of typing it, you can use the DirectoryOrdChooser.
You can select FileSpaces, Bookmarks and directories. In addition toolbar functions are provided including:
450
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-PropertySheet workbench:HistoryOrdChooser
New Folder
New Folder creates a new Directory.
Bookmarks
You can press the Bookmarks button to add the selection to Bookmarks.
workbench:HistoryOrdChooser
In order to select a reference Ord instead of typing it, you can use the HistoryOrdChooser.
You can select items from the tree by type slot or Handle.
workbench:RefChooser
In order to select a reference Ord instead of typing it, you can use the RefChooser.
You can select items from the tree by type slot or Handle.
workbench:BqlQueryBuilder
In order to select a BQL query instead of typing it, you can use the BqlQueryBuilder.
BQL is one Scheme used to Query in the Niagara Framework. An Ord is made up of one or more
Queries. A Query includes a Scheme and a body. The bql Scheme has a body with one of the following formats:
• BQL expression
• Select projection FROM extent Where predicate
You can create the Ord Qualifier, Select, FROM and Where portions of a Query.
Ord Qualifier
In the left window, you can select an Ord to use as the qualifier. It will immediately be placed in the
BQL statement at the top when you select it.
If you select the history Scheme, your options will vary from those shown here.
workbench:ProjectionBuilder
In order to build the projection for a BQL request instead of typing it, you can use the Projection-
Builder in
. You can select an item from the center window to use with the select statement. Press the right arrow to add each one to the projection.
Bql Expressions"
An expression can be one of the following:
• field like displayName
• x.y.z
• any method that returns non-void and takes zero parameters
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
451
workbench-PropertySheet
Chapter 14 — Plugin Guides workbench:ExtentBuilder
After you build the BQL statement, you can remove the "Select" to provide a BQL expression instead of a Select statement.
workbench:ExtentBuilder
An extent can be one or more of the following:
• "*" all available from the target
• all property slots
• all methods that return non-void and take zero parameters
In order to build the Extent for a BQL request instead of typing it, you can use the ExtentBuilder in
. You can select the Restrict Type and choose the module and item to use with the
FROM clause. It will immediately appear in the BQL statement at the top.
This also changes the items that are available in the projection.
If you choose a history Scheme, the ExtendBuilder will provide different selections. The extent for a
History typically can be one of the following:
• "from /demo/Float" where demo is the station name
• "from !Float" where "!" signifies the current station
workbench:QualifierBuilder
In order to build the Qualifier for a BQL request, you can type it in the QualifierBuilder in Bql
. As you type, it will immediately appear in the BQL statement at the top.
Edit Facets
Edit Facets allows viewing and editing of facets. In order to change facets, you use the to the right of the facets. It will present the Edit Facets dialog.
From here you can
Add , Remove or select the Enum Range Dialog . See BFacetsConfig.bajadoc for
more information.
Add
Add allows you to add a Key and Type.
Remove
Remove allows you to remove facets.
Enum Range Dialog
In order to view or set the range of values for a Enum, you can use the . It will present the Enum
Range Dialog:
You can enter one of the standard Enumerations in the field under the Use Enum Type in
Range (module:name)
.
Press Use Enum Type in Range (module:name) to use the Enumeration that you entered.
452
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-SlotSheet Enum Range Dialog
In order to enter or change an Enumeration, enter the Ordinal in the field above the Add button. Next enter the new value for the Tag and press Modify. Press OK to complete the dialog.
workbench-SlotSheet
The Slot Sheet shows all the user visible slots of the Component. This includes Properties,
Actions, and Topics.
The SlotSheet is a Table that shows the following for each slot:
• Slot
• #
• Name
• Display Name
• Definition
• flags
• Type
The SlotSheet also optionally shows any Name Maps. The SlotSheet includes the following menus:
•
•
SlotSheet Main Menu
The Workbench main menu functions are available. When the SlotSheet is visible, the following
SlotSheet
menu functions are also available:
•
•
•
Ctrl + A
Ctrl + R
•
• Reorder
•
SlotSheet Component Menu
•
•
•
•
•
If you Right-click any Component in the SlotSheet or the background, you can choose from the following:
Ctrl + A
Copy Ctrl + C
Delete Delete
Ctrl + R
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
453
workbench-StationSummary
Chapter 14 — Plugin Guides
Enum Range Dialog
•
•
•
•
SlotSheet Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38. When the SlotSheet is visible, additional toolbar buttons include:
•
• Reorder
Add Slot
Add Slot allows you to add a slot to the Component.
Rename Slot
Rename Slot allows you to rename a slot in the Component.
Add Name Map
Add Name Map
allows you to add a Name Map to the Component. You Right-click on the Property displayNames to delete or rename Name Map and displayNames_xx to delete or rename Name Map
(xx) where xx is the Language Code.
Config Facets
Configure Facets on the Component. This is available on Properties. Right-click a Property to view the Config Facets Dialog.
workbench-StationSummary
StationSummary is the default view on a Station . It holds primary components (e.g. Config,
Files, History) as well as shows specific configuration information about the station’s host platform, including:
• Station Name
• Host
• Host Model
• Host Id
• Niagara Version
• Java Version
• OS Version
• Locale
454
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-TextFileEditor Enum Range Dialog
• Current Time
workbench-TextFileEditor
The TextFileEditor Plugin provides a powerful Color coded text editor. It supports Color coding of C, java and xml file types. See
File Types for more information on Color coding of spe-
cific file types. See TextEditorOptions
to change editor options including Color coding.
TextFileEditor Menus
The Workbench main menu functions are available.
TextFileEditor Toolbar
The Workbench toolbar contains navigation and editing buttons as described in
“About the toolbar” on page 38.
File Types
The TextFileEditor Plugin provides a powerful Color coded text editor. It supports Color coding of C, java
, properties, Python and xml file types. See
to change editor options including Color coding.
C Files
The TextFileEditor supports special Color coding for C files including:
• Preprocessor - #include
• Line Comment - / comment /
• Multiline Comment - /* comment */
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
• Keyword - blue - if
CSS Files
The TextFileEditor supports special Color coding for CSS files including:
• Identifier - HTML element or CSS identifier
• Line Comment - / comment /
• Multiline Comment - /* comment */
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
• Keyword - blue - if
HTML Files
The TextFileEditor supports special Color coding for HTML files including:
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
455
workbench-TextFileEditor
• Identifier - HTML element
• Multiline Comment - <!-- Comments here -->
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
• Keyword - blue - if
Chapter 14 — Plugin Guides
Enum Range Dialog
Java Files
The TextFileEditor supports special Color coding for Java files including:
• Bracket - ( { [
• Keyword - if
• Line Comment - / comment /
• Multiline Comment - /* comment */
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
JavaScript Files
The TextFileEditor supports special Color coding for JavaScript files including:
• Bracket - ( { [
• Keyword - if
• Line Comment - / comment /
• Multiline Comment - /* comment */
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
Properties Files
The TextFileEditor supports special Color coding for properties files including:
• Line Comment - #
• Bracket - =
Python Files
The TextFileEditor supports special Color coding for Python files including:
• Bracket - {}()[]
• Keyword - if
• Line Comment - #
• String literal - "string" and 'string'
• Number literal - '0' and 'F'
Xml Files
The TextFileEditor supports special Color coding for Xml files including:
• Multiline Comment - <!-- comment -->>
• Bracket - < > < >
456
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Chapter 14 — Plugin Guides workbench-ServiceManager Enum Range Dialog
• String literal - "string" and 'string'
workbench-ServiceManager
Service Manager allows you to view services. It is available on the ServiceContainer
.
workbench-WbPxView
PxView is a dynamic view which may be added to Components as a property. PxViews store
which is an XML file with a PX extension. The view itself is defined as a tree of bajaui:Widgets.
For more information about Px views, refer to “About Px views” on page 218.
For more information about Px view menus, refer to
“About the Px Editor menu” on page 468.
Related Px information is available as listed below:
•
•
•
WbPxView Menus
The Workbench main menu functions are available. When the Px Viewer is visible, the following menu functions are also available:
•
PxViewer View Source Xml
You can view the source XML of a PX Page by selecting View Source Xml from the main menu.
See BPxView.bajadoc for more information.
workbench-WbServiceManagerView
Workbench Service Manager allows you to view services. It is available from the Tools menu.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
457
workbench-WbServiceManagerView
Chapter 14 — Plugin Guides
Enum Range Dialog
458
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
In this appendix (introduction)
Appendix A References
In this appendix (introduction)
This appendix contains the following reference information:
•
Explains how to use the keyboard to enter menu bar and popup menu commands – without using the mouse.
•
•
Describes the popup menus that appear in different views and contexts.
•
•
Explains the different views available in the view pane. For an overview of the view pane, refer to
“About the view pane” on page 36.
•
Explains each of the different sets of selector menu menus. For an overview of the view selector menu, refer to
“About the view selector” on page 40.
•
Explains the options that appear in each of the Workbench GUI dialog boxes.
About keyboard shortcuts
Workbench provides a number of keyboard shortcuts for common actions. These are performed by holding down the combination of keys listed. They include:
• F1 - Help On View
• F3 - Console
• F4 - Hide Console
• F5 - searchFind;
• F6 - searchReplace;
• F7 - Goto File
• F8 - searchConsoleNext;
• F9 - Save amp; Compile
• Alt + Left - Back
• Alt + Right - Forward
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
459
Types of menu bar items
• Alt + Up - Up Level
• Alt + Home - Home
• Alt + Space - Recent Ords
• Ctrl + A - Add Slot
• Ctrl + C - copyg;
• Ctrl + D - duplicate;
• Ctrl + F - Find Next
• Ctrl + G - Goto Line
• Ctrl + L - Open Ord
• Ctrl + N - New Window
• Ctrl + O - Open File...
• Ctrl + P - Print
• Ctrl + R - Rename Slot
• Ctrl + S - Save
• Ctrl + T - New Tab
• Ctrl + V - paste;
• Ctrl + W - Word Wrap
• Ctrl + X - cut;
• Ctrl + Z - undo;
• Ctrl + F1 - Find Bajadoc
• Ctrl + F4 - Active Plugin
• Ctrl + F5 - searchFindFiles;
• Ctrl + F6 - searchReplaceFiles;
• Ctrl + F9 - Compile
• Ctrl + PageUp - Next Tab
• Ctrl + PageDown - Previous Tab
• Shift + F8 - searchConsolePrev;
• Ctrl + Shift + F - searchFindPrev;
• Ctrl + Alt + Z - redo;
Types of menu bar items
This section describes the menu items that appear in the Workbench menu bar:
• File menu
See “About the File menu” on page 461
• Edit menu
See “About the Edit menu” on page 463
• Search menu
See “About the Search menu” on page 465
• Bookmarks menu
See “About the Bookmarks menu” on page 466
• Tools menu
See “About the Tools menu” on page 466
Appendix A — References
460
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
• Window menu
See “About the Window menu” on page 467
• Px Editor menu
See “About the Px Editor menu” on page 468
• Help menu
See “About the Help menu” on page 469
Types of menu bar items
About the File menu
The File menu in the menu bar has the following options:
The File menu in the menu bar provides the following options:
•Open Ord You may open a ord by selecting File > Open > Open Ord from the main menu or from the toolbar open button.
The Ord Chooser also allows you to directly type the Ord of a location in order to go there. If no view is specified, the default view for the item will be presented. You may also paste an Ord instead of typing it by pressing the paste shortcut Ctrl + V after you have copied a node or Ord into the clipboard.
•Open File
You may open a file by selecting File > Open > Open File... from the main menu.
•Open Directory
You may open a Directory by selecting File > Open > Open Directory... from the main menu.
•Open Station (Fox)
You may open a Station by selecting File > Open > Open Station (Fox)... from the main menu. This will cause the following popup window to be presented so that you can complete each field.
Address - This is the address of the computer running the Station that you wish to access.
User name - This is the user name given to you by your system administrator.
Password - This is the password given to you by your system administrator.
Remember these credentials - This will save this connection in your connection list.
Once you successfully connect to the Station, it will appear in the tree and your home page will be displayed.
If you will be away from the system, you should close the Station to prevent unauthorized access.
•Open Platform
You may open a Platform by selecting File > Open > Open Platform... from the main menu. This will cause the following popup window to be presented so that you can complete each field.
Host - This is the address of the computer running the Platform that you wish to access.
Port - This is the port used.
Password - This is the password given to you by your system administrator.
Remember these credentials - This will save this connection in your connection list.
Once you successfully connect to the Platform, it will appear in the tree and the available tools will be displayed.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
461
Appendix A — References
Types of menu bar items
•Find Stations
You may find Stations by selecting File > Open > Find Stations... from the main menu. This command finds all the stations running on the network. It will search for 5 seconds, then display a Table of all the stations found. You may display additional columns about each station using the options button (on the right of the header). Double-click a Station to open a
Fox connection to it.
•Back
Back allows you to go to the previous view. The shortcut is Alt + Left.
•Forward
Forward
allows you to go to the next view. You must have used the Back command previously. The shortcut is Alt + Right.
•Up Level
Up Level allows you to go to the next level up. The shortcut is Alt + Up.
•Save
Saves the value of the Component.
•Save Bog
Save the Component changes to the Bog File file.
•Save All
Save all open views. This saves all Tabs when browsing with multiple Tabs.
•Recent Ords
Recent Ords allows you to see recent Ords. The shortcut is Alt + Space.
•Refresh
Refresh allows you to refresh the current view.
•Home
Home allows you to go to the home view. The shortcut is Alt + Home.
p
•Printing
Printing provides the capability to print the current view. When it appears dimmed, printing is not available.
•Export
Export provides the capability to Export the current view. When it appears dimmed, Export is not available.
• Logging off the System
You may exit the system by a number of means. You may Close the session, Close All sessions, Exit, or Close the current window. Each of these causes different actions and should be understood.
• Close Session
You may logoff the Station at any time by selecting File > Close from the main menu.
Once you successfully close a session, it will be removed from the tree. This could leave a user interface running without an open session.
• Disconnect
You may logoff the system at any time by Right-clicking the connected system in the tree and select Disconnect. This allows you to close a session with a Station without removing it from the tree.
• Dismiss
462
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of menu bar items
You may logoff a connected system at any time by Right-clicking the connected system in the tree and select Dismiss. This allows you to close a session with a Station and remove it from the tree.
• Exiting the System
You may exit the system at any time by selecting File > Exit from the main menu. This differs from logoff in that it also causes the user interface to stop.
• Close the Current Window
You may close the current window at any time, if it is not the primary window, by any of the following methods:
• selecting File > Close from the main menu
• pressing the box in the top left corner and selecting Close from the menu
• pressing the close icon in the top right corner of the window
• New Window
New Window requests that a new window be created identical to the current one. This allows you to view multiple views concurrently.
•New Tab
New Tab requests that a new tab be created identical to the current one. This allows you to view multiple views in the same Window. You can hold down the Ctrl key during a Double-click to hyperlink into a new tab. You can also Right-click to get a popup menu on tabs to close the tab, or close all other tabs.
•Close Tab
Close Tab requests that a tab be closed.
• Close Other Tabs
Close Other Tabs requests that all other tabs be closed.
• Next Tab
Next Tab selects the next tab. The shortcut is Ctrl + PageUp.
• Previous Tab
Previous Tab selects the previous tab. The shortcut is Ctrl + PageDown.
About the Edit menu
• Cut
Cut copies the current Selection to the clipboard and changes its Color to gray until a Paste is performed to delete it. If the Selection is a string, Cut makes a Copy of the current text selection and places it in the clipboard and removes it from the current string. It is may be accessed by selecting an item and:
• Right-clicking the item(s) and choosing Cut.
• Right-click in the tree and choosing Cut.
• In the Wire Sheet press the Cut toolbar icon.
• In the Wire Sheet select Edit > Cut from the main menu.
• pressing the shortcut key Ctrl + X (hold down Ctrl and press X) when in a window other than the main browser window.
You can use
Drag to Cut and Paste in one operation.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
463
Appendix A — References
Types of menu bar items
• Copy
Copy copies the current contents of the clipboard to the destination component as a set of new dynamic properties. If the Selection is a string, Copy makes a copy of the current text
Selection and places it in the clipboard. To Copy a Component, do any of the following:
• Right-click a Component in a view or tree and choose Copy
• Right-click the background in the Wire Sheet choosing Copy
• In the Wire Sheet press the Copy toolbar button.
• In the Wire Sheet select Edit > Copy from the main menu
• pressing the shortcut key Ctrl + C (hold down Ctrl and press C) when in a window other than the main browser window.
You can copy a selected group of Components in the Wire Sheet.
You can use
In order to Copy a Component, you must Copy it from the Palette or an existing Database. You can follow one the following steps:
• In the Palette Sidebar, expand a module (like control) and sub-directory (like Points), Rightclick on a Component (like BooleanWritable) and select Copy.
• In the namespaces sidebar (tree), expand System, Modules, a module (like control), Files, module.palette, and sub-directory (like Points), Right-click on a Component (like BooleanWritable) and select Copy.
• OR Right-click on a Component that you want to Copy from a Wire Sheet, Property Sheet or the tree and select Copy.
• Paste
Paste copies the contents of the clipboard to the destination Component as a set of new dynamic properties. If the target is a string, Paste places a reference to the source that was cut or copied into clipboard. It may be accessed by cutting or copying item(s) and:
• Right-clicking the item and choosing Paste
• Right-click in the tree and choosing Paste
• In the Wire Sheet press the Paste toolbar icon.
• In the Wire Sheet select Edit > Paste from the main menu
• pressing the shortcut key Ctrl + V (hold down Ctrl and press V) when in a window other than the main browser window.
You can use
Drag to Cut and Paste in one operation.
You can add a Component to a running Station or an offline Bog File file. You can do this using any of the following:
• In the Wire Sheet, Right-click on the background and select Paste to add the new Component.
The new Component is created and is selected.
• In the tree, Right-click on a Container and select Paste to add the new Component inside the
Container.
See the Bajadoc Index for reference information. If you select Help > Guide On Target with a Component selected, you will get the Guide for that Component. If you select Help >
Bajadoc On Target
with a Component selected, you will get the bajadoc for that Component. The BooleanWritable bajadoc is at module://control/doc/javax/baja/control/BBooleanWritable.bajadoc.
• Paste Special
464
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of menu bar items
Paste Special copies the contents of the clipboard to the destination Component when it is a
Special Transferable.
• Duplicate
Duplicate copies the current Selection and places a duplicate in the same Container. This function may be access from the menu under Edit (shortcut Ctrl + D) or from the toolbar.
• Delete
Delete removes the current Selection from its parent Container. It may be accessed by selecting an item and:
• Right-clicking the item(s) and choosing Delete
• Right-click in the tree and choosing Delete
•In the Wire Sheet press the Delete toolbar button.
•In the Wire Sheet select Edit > Delete from the main menu
• Undo
This reverses the last Action as if it had not been performed. It is only available for certain actions such as:
• Paste Component
• Cut Component
• link
• Delete Links
• Redo
This restores an Action after Undo has removed it. It is only available after a successful
Undo.
About the Search menu
The Search menu in the menu bar has the following options:
• Find
Find allows you to search in the file for the selected string. You can Match Case or
Match Word
. The shortcut is F5.
• Find Next
Find Next allows you to find the next occurrence of the selected string. The shortcut is Ctrl
+ F (hold down Ctrl and press F).
• Find Prev
Find Prev allows you to find the previous occurrence of the selected string. The shortcut is
Ctrl + Shift + F (hold down Ctrl and Shift and press F).
• Replace
Replace allows you to replace the next occurrence in the file. The shortcut is Ctrl + R (hold down Ctrl and press R).
• Goto Line
Goto Line allows you to go to a line number in the file. The shortcut is Ctrl + G (hold down Ctrl and press G).
• Goto File
Goto File allows you to go to a file. The shortcut is Ctrl + F3 (hold down Ctrl and press F3).
•Find Files
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
465
Appendix A — References
Types of menu bar items
Find In Files allows you to find the all occurrences of a string in files. You can Match
Case
or Match Word. You can choose Files to Find. You can select a Folder.
You can choose whether to Search subfolders.
• Replace Files
Replace Files allows you to replace the all occurrences in the files.
•Console Prev
Console Prev allows you to go to the previous console error. The shortcut is F7.
•Console Next
Console Next allows you to go to the next console error. The shortcut is F8.
About the Bookmarks menu
The Bookmarks menu in the menu bar has the following options:
• AddTo Bookmarks
You may add a Bookmark by selecting Bookmarks > Add to Bookmarks from the main menu.
• Manage Bookmarks
You may manage Bookmarks by selecting Bookmarks > Manage Bookmarks from the main menu.
• Bookmarks Go Into
You may select Bookmarks by selecting Bookmarks > Go Into from the main menu.
• Bookmarks File
You may select Bookmarks by selecting Bookmarks > File from the main menu.
About the Tools menu
The Tools menu in the menu bar has the following options:
• Viewing and Changing the Options
The Options allow you to customize the framework for the way you use it. It can be selected from the main Menu by selecting Tools > Options. It includes the following:
• General
• Lexicon
• Text Editor
• Wire sheet
• ColorChooser
The ColorChooser allows you to choose Colors.
• New Module Wizard
The New Module Wizard allows you to build a new Module. It can be selected from the main Menu by selecting Tools > New Module.
• New Station Wizard
466
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of menu bar items
The New Station Wizard allows you to build a new station Database. It can be selected from the main Menu by selecting Tools > New Station.
You must enter a Station Name. You can also choose whether this is a JACE Station or a Supervisor Station. Press Next to proceed. Next you should enter an Admin
Password
. You can also change the Fox Port and HTTP Port. Press Finish to proceed.
You are then presented a view of your newly created Station at local:|file:!stations/ stationname/config.bog|bog:|slot:/
.
• Manage Credentials
Manage Credentials is available in the main Tools menu by selecting Manage Cre-
dentials...
. You can Reset or Remove selected Credentials or Remove All Credentials. You can also Open selected Credentials.
• Request License
Request License is available in the main Tools menu by selecting Request License....
You can request a license by submitting the form.
About the Window menu
The Window menu in the menu bar has the following options:
•
Side Bars
•Show Side Bar
You can choose whether to have Side Bars by selecting Window > Side Bars >
Show Side Bar
from the main menu.
• Using the Help Sidebar
The typical configuration provides a Help Sidebar frame in the left side of the main window. Initially, the Help Sidebar is empty until you press Load Help.
Load Help will reappear any time any Module's timestamp is changed or a new
Module is added or removed. Load Help searches through all the available Modules to create the help Directory. The Help Sidebar provides a view of the available Help.
For more information about the Help Sidebar refer to “About the help side bar” on page 29:
•
Jobs Sidebar
The Jobs SideBar shows all the current jobs in all the stations with which you have a connection. The current status of each job is shown: running, canceling, canceled, success, or failed. If the job is running then a progress bar displays estimated progress. You may cancel a running job by pressing the cancel button. Once a job has completed you are notified via the async notification feature. You may then dismiss the job by pressing the close button. At at time the log details of the job may be access using the ">>" button.
•
Nav
•
Palette
• PathBar Uses NavFile
•
Active Plugin
The Active Plugin function gives focus to the current Plugin. From the main menu you can select
Window > Active Plugin
or use the shortcut Ctrl + F4. It is very useful to use F3/Ctrl + F4 to toggle between the
Console and the Text File Editor.
•
Hide Console
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
467
Appendix A — References
Types of menu bar items
You can hide the console by selecting Window > Hide Console from the main menu or using the shortcut Ctrl + F2.
•
Console
The Console provides the capability to issue console commands directly. From the main menu you can select Window and Console (F3) or Hide Console (F4) to determine if the console is visible.
Console commands include:
Niagara Shell Help
cd View and change current directory
debug Turn debug tracing on and off
print Print to the output stream
reset Reset the environment to its default state
set View and modify environment variables
which Resolve a filename in path
Additional help available via <cmd> -?
help Shows this help summary
In addition, you can use and
About the Px Editor menu
The Px Editor menu appears in the menu bar when Px Editor is the active view. The Px Editor has the following context–sensitive options:
• Toggle View/Edit Mode
This command toggles the active view between Px Editor (for editing) and Px View (view only).
If there are unsaved changes in your Px file, you are prompted to save before switching from Px
Editor to Px View.
• View Source Xml
Selecting this command displays the px source file in a separate read–only window.
• Go to Source Xml
Selecting this opens the px source (xml) file directly in the text file editor. Files can be edited and saved using the editor.
• Grid
This command toggles the grid display on and off.
• Snap
This command toggles the snap–to–grid feature on and off.
• Show Hatch
This command toggles the hatching pattern visibility on and off. When hatching is on, dim angular lines (hatching pattern) displays on objects to make them more visibly distinct.
• Set Target Media
This command is available when you are editing a Px file directly in the Px Editor–not when you are editing the Px file as a view of a component. When selected, this command displays the Set
Target Media
dialog box to allow you to choose your expected media viewer (HTML Px
Media or Workbench Px Media). See
“About presentation media” on page 19 for more details
about media types.
468
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of popup menu items
About the Help menu
The Help menu in the menu bar has the following options:
• Help Contents Index
p
The help contents provides a common point of access to all system documentation. It is accessed by selecting Help > Contents Index from the menu or pressing the Help button on the toolbar to see the Help Index.
• Help On View
This provides help for the current Plugin. It is accessed by selecting Help > On View from the menu with the Plugin in use.
• Help Guide On Target
This provides context sensitive help for Components. It is accessed by selecting Help >
Guide On Target
from the menu when the current view is a view of a Component. It is also available by Right-clicking a Component and choosing Views > Guide Help.
• Help Bajadoc On Target
This provides context sensitive Bajadoc help for Components. It is accessed by selecting
Help > Bajadoc On Target
from the menu when the current view is a view of a
Component. It is also available by Right-clicking a Component and choosing Views > Baja-
doc Help
.
• Help Find Bajadoc
This is accessed by selecting Help > Find Bajadoc from the menu. It searches for the requested bajadoc.
• Help About
This is accessed by selecting Help > About from the menu. It provides the software release and license information.
Types of popup menu items
Workbench provides view–specific, or context–specific commands for editing components in many of the views. Following, is a list of the standard Workbench popup (right–click) menus.
• Nav side bar
For descriptions of the popup menu items that are available in the nav side bar refer to
“About the nav side bar popup menu items” on page 470.
• Wire sheet
For descriptions of the wire sheet popup menu items, refer to
“About the wire sheet popup menu items” on page 471
• Property sheet
• Px Editor
For descriptions of the
“About the Px Editor popup menu items” on page 471.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
469
Appendix A — References
Types of popup menu items
About the nav side bar popup menu items
The nav sidebar provides a tree–type hierarchical view of the system. For an overview of the nav side bar, refer to
“About the nav side bar” on page 30.
The nav side bar menu is the popup menu that displays command options when you right–click on a component item in the nav side bar. The nav side bar menu has the following options:
• Views
Goes to any of the views of the selected component.
• Actions
Perform any available actions on the component.
• New
Create a new item of standard types.
• Cut
• Copy
Cuts the component, copying it to the clipboard.
• Paste
Copies the selected component to the clipboard.
Pastes the selected component from the clipboard onto the selected view.
• Duplicate
•Delete
Delete
•Find
•Link Mark
• Link From
• Link To
• Rename
• Reorder
•Composite
• Refresh
•Go Into
Go Into allows you to re-root the nav tree at any arbitrary node. Right-click the node and select the "Go Into" command. This will make that node the new root of the tree. All the nodes you have "gone into" are persistently saved as a special type of Bookmark. Use the pulldown to switch between them. This feature is quite handy when working with multiple Stations or deep
File systems and Databases.
470
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of popup menu items
About the wire sheet popup menu items
Most of the wire sheet menu commands are described in
“About the nav side bar popup menu items”
.
Following are wire sheet specific popup menu options:
• Arrange
Provides options for aligning components on the wire sheet in order to make them easier to view:
• Arrange All
Redistributes the layout of all components on the wire sheet.
• Arrange Selection
Redistributes the layout of all selected components on the wire sheet.
• Select all
Selects all components on the active wire sheet.
About the property sheet popup menu items
Most of the property sheet menu commands are described in
“About the nav side bar popup menu items”
. Following are wire sheet specific popup menu options:
• Config flags
About the Px Editor popup menu items
•
•
•
•
•
•
•
•
The Px Editor popup menu displays when you right-click on an object in the Px Editor view. The menu commands are dimmed or available, depending on the type of object that you select.
The following menu commands are on the Px Editor popup menu:
•
New
(refer to
“About the Edit menu” on page 463)
Cut Ctrl + X (refer to “About the Edit menu” on page 463)
Copy Ctrl + C (refer to “About the Edit menu”
Paste Ctrl + V (refer to
“About the Edit menu” on page 463)
Duplicate Ctrl + D (refer to “About the Edit menu” on page 463)
Delete Delete (refer to
“About the Edit menu” on page 463)
Edit Properties... (refer to
“About the properties side bar” on page 35)
Align > Left
This command is available when you select two or more objects in the Px Editor. Choose the
Left
command to align the left edges of two or more objects along a vertical line.
Align > Right
This command is available when you select two or more objects in the Px Editor. Choose the
Right
command to align the right edges of two or more objects along a vertical line.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
471
Appendix A — References
Types of edit commands
•
Align > Top
This command is available when you select two or more objects in the Px Editor. Choose the Top command to align the top edges of two or more objects along a horizontal line.
•
Align > Bottom
This command is available when you select two or more objects in the Px Editor. Choose the
Bottom
command to align the bottom edges of two or more objects along a horizontal line.
•
Reorder > To Top
This command is available when you select one or more objects in the Px Editor. Choose the
To Top
command to move the selected object to the top position (inside its parent object) in the
Widget Tree. This command will place the object in front (with respect to the view pane, or zaxis) of all other objects in the parent object, but will not move the object out of its parent object.
•
Reorder > Up
This command is available when you select one or more objects in the Px Editor. Choose the Up command to move the selected object one position higher in the Widget Tree and forward one position in the view pane. This command will not move the object out of its parent object.
•
Reorder > Down
This command is available when you select one or more objects in the Px Editor. Choose the
Down
command to move the selected object one position lower in the Widget Tree and back one position in the view pane. This command will not move the object out of its parent object.
•
Reorder > To Bottom
This command is available when you select one or more objects in the Px Editor. Choose the
To Bottom
command to move the selected object to the bottom position (inside its parent object) in the Widget Tree. This command will place the object behind (with respect to the view pane, or z-axis) all other objects in the parent object, but will not move the object out of its parent object.
•
Border > Add Border
This command is available when you select one or more objects in the Px Editor. Choose the Add
Border
command to wrap selected object(s) with a border pane. Each selection is wrapped in a separate border pane.
•
Border > Remove Border
This command is available when you select one or more border panes in the Px Editor. Choose the
Remove Border
command to delete selected border pane(s).
Types of edit commands
In addition to view–specific editing tools, Workbench provides commands for editing components in many of the views. Following, is a list of descriptions of the standard commands that are available in
Workbench views for editing components.
•
Drag
Dragging files or components only works within a single Workbench application. However, it is possible to drag files from Windows Explorer into the Workbench to see the default view. Dragging a component or file using the left mouse button performs a Copy operation. Dragging a com-
472
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of toolbar icons ponent or file using the right mouse button always prompts you for a Copy, Move, or Cancel command selection.
•
Cut
Use the Cut command to delete the selected object and send it to the clipboard.
•
Copy
Use the Copy to send the selected object to the clipboard without deleting it.
•
Paste
Use the Paste command to copy the current contents of the clipboard to the destination as a set of new dynamic properties.
•
Duplicate
Use duplicate to create a copy of the current selection in the same container as the selection.
•
Delete
Use the Delete command to remove a selected item from its parent container.
•
Undo
Use the Undo command to reverse the previous command. Undo is only available for certain commands, such as, Paste, Cut, Delete, and the Link action.
•
Redo
Use the Redo command to restore a command–action after the Undo command has removed it.
•
Rename
Use Rename to change the name of a Component.
Types of toolbar icons
For an overview of the Workbench toolbars, refer to “About the toolbar” on page 38.
Some icons are always visible as you navigate through the system. Additional icons may be added and removed from view when different views are active. When icons appear dimmed, their functions are unavailable. Icons that appear on the toolbar are grouped in the following categories:
• Standard toolbar icons
These icons may be dimmed (or unavailable in certain views) but they are always present on the toolbar. Refer to
“Standard toolbar icons” on page 474 for the listing of Standard toolbar icons.
• Slot sheet toolbar icons
• Px Editor toolbar icons
These icons appear only when the Px Editor or Px Viewer is active. Refer to
“Px Editor toolbar icons” on page 475 for the listing of Px Editor toolbar icons.
• History Editor icons
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
473
Appendix A — References
Types of toolbar icons
Standard toolbar icons
icons that appear in all views:
• Back. See “Back” on page 462 for details about the Back function.
• Forward. See “Forward” on page 462 for details about the Forward function.
• Up Level. See “Up Level” on page 462 for details about the Up Level function.
• Recent Ords. See “Recent Ords” on page 462 for details about the Recent Ords function.
• Home. See “Home” on page 462 for details about the Home function.
• Refresh. See “Refresh” on page 462 for details about the Refresh function.
• Left Side Bar. See
“Side Bars” on page 467 for details about the Side Bars function.
• Open. See “About the File menu” on page 461 for details about all the Open functions.
• Save Ctrl + S. See “Save” on page 462 for details on the Save function.
• Save Bog. See “Save Bog” on page 462 for details on the Save Bog function.
• Printing Ctrl + P. See “Printing” on page 462 for details on the Printing function.
• Cut Ctrl + X. See “Cut” on page 473 for details on the Cut function.
• Copy Ctrl + C. See “Copy” on page 473 for details on the Copy function.
• Paste Ctrl + V. See “Paste” on page 473 for details on the Paste function.
• Duplicate Ctrl + D. See “Duplicate” on page 473 for details on the Duplicate function.
• Delete Delete. See “Delete” on page 473 for details on the Delete function.
• Undo Ctrl + Z. See “Undo” on page 473 for details on the Undo function.
• Redo Ctrl + Alt + Z. See “Redo” on page 473 for details on the Printing function.
Slot Sheet toolbar icons
icons that appear when the Slot Sheet view is active:
• Add Slot
Creates a new slot (appearing as a row) on the slot sheet.
• Rename Slot
Displays the Rename Slot dialog box, when clicked. This icon is dimmed when no slot, or more than one slot is selected in the slot sheet editor view.
• Config Flags
Displays the Config Flags dialog box, when clicked. This icon is dimmed unless one or more slots are selected in the slot sheet editor view.
• Reorder
Displays the Reorder dialog box, when clicked.
474
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Types of toolbar icons
Px Editor toolbar icons
icons that appear when the Px Editor is the active view:
• Toggle View/Edit Mode.
Displays, alternately, the Px Editor or the Px Viewer in the view pane. This icon appears inset when the Px Editor view is active and it appears normal when the Px Viewer is active. See
“About Px views” on page 218 for more details about the Px Editor and Px Viewer.
• Right (Px Editor) side bar menu
Displays a dropdown menu of side bar options for the Px Editor. The following options are available:
• Bound Ords
Shows or hides the Bound Ords side bar (refer to “About the bound ords side bar” on page 34).
• Widget Tree
Shows or hides the Widget Tree side bar (refer to
“About the widget tree side bar” on page 35).
• Properties
Shows or hides the Properties side bar (refer to “About the properties side bar” on page 35).
• Left align
Aligns left edges of selected objects along a vertical line.
• Right align.
Aligns right edges of selected objects along a vertical line.
• Top align
Aligns top edges of selected objects along a horizontal line.
• Bottom align
Aligns bottom edges of selected objects along a horizontal line.
• To Top
Moves selected objects to the highest position (with regard to z-order) in the parent object.
• To Bottom
Moves selected objects to the lowest position (with regard to z-order) in the parent object.
• Select
Activates the pointer tool used to select objects in the Px Editor view using the mouse.
• Add Polygon
Activates the polygon tool for drawing polygons.
• Add Path
Activates the path tool that allows you to draw bezier curves in the Px Editor view.
• Add Point
Activates the Add Point tool that allows you to add a point to a path or a polygon in the Px
Editor view.
• Delete Point
Activates the Delete Point tool that allows you to remove a point from a path or a polygon in the Px Editor view.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
475
Appendix A — References
Types of views
History editor toolbar icons
For an overview description of the history editor view, refer to
• Hide
With one or more records selected, this icon is available to set the trend flag of all selected records to “hidden”. With no records selected, the icon is dimmed (unavailable).
• Unhide
With one or more records selected, this icon is available to set the trend flag of all selected records to “hidden”. With no records selected, the icon is dimmed (unavailable).
• Filter
Displays the Configure Flags dialog box, when clicked. This icon is available even if no records are selected.
• Configure Outliers
Displays the Configure Outliers dialog box, when clicked.
Types of views
This section describes the different views available in the view pane. For an overview of the view pane, refer to
“About the view pane” on page 36.
Types of view selector menus
View selector menu options are context–related menus that change, depending on what is being displayed in the view pane. The following section explains each of the different sets of selector menus.
For an overview of the view selector menu, refer to “About the view selector” on page 40.
Types of dialog boxes
Explains the options that appear in each of the Workbench GUI dialog boxes.
About console commands
The following sections provide descriptions of how to use the Workbench console in terms of:
•
Syntax of the console commands
•
476
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
List of console commands
•
Console commands optional flags
Non–required parameters that may be used in console commands
About console command usage
Following is the proper usage of the console commands:
• plat <command> <flags> <command-flags>
Types of console commands
The following commands may be typed in from the Workbench console.
• details
display a configuration summary for a remote host
• fget
get one or more files from a remote host
• flist
provide file details for a single file, or for all files in a directory
• ipconfig
display the TCP/IP configuration for a remote host
• jacejar
create Niagara module files that can be run on embedded hosts
• liststations
list stations that are managed by the Niagara platform daemon
• moduleinstall
install Niagara modules to a remote host
• reboothost
request that a remote Niagara platform daemon reboot its host
• script
run one or more platform commands in a script
• startstation
request that a Niagara platform daemon start a station
• stopstation
request that a Niagara platform daemon stop a station
• tellstation
send text to the console of a running Niagara station
• watchstation
monitor the output of a niagara station
• installdaemon
install the Niagara platform service (Win32 only)
• uninstalldaemon
remove the Niagara platform service (Win32 only)
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
About console commands
477
Appendix A — References
SVG Colors
• installdialup
install the Niagara dialup service (Win32 only)
• unistalldialup
remove the Niagara dialup service (Win32 only)
Console commands optional flags
• -usage
plat -usage prints the help listing in the console plat <command> -usage prints the command specific usage in the console
• -?
• plat -? prints the help listing in the console
• plat <command> -? prints the command specific usage in the console
• -help
• plat -help prints the help listing in the console
• plat <command> -help prints the command specific usage in the console
• -locale:<x>
sets the default locale (en_US)
• -@<option>
passes the option to the Java VM
• -buildreg
forces a rebuild of the registry
SVG Colors
The following list provides information about X11 colors that are supported by popular browsers with the addition of gray/grey variants from SVG 1.0. The list is the same as the SVG 1.0 color keyword names. The two color swatches on the left illustrate setting the background color of a table cell in two ways: The first column uses the named color value, and the second column uses the respective numeric color value.
Caution: The appearance of colors varies in different media (print, screen, and so on). Colors presentation also vary between browsers. The most reliable way to preview colors is in the browser type and version that it is are targeted for.
Table 1 SVG color table
Named Numeric Color name
aliceblue antiquewhite aqua
Hex rgb
#f0f8ff
#faebd7
#00ffff
Decimal
240,248,255
250,235,215
0,255,255
478
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Named Numeric Color name Hex rgb Decimal
aquamarine azure beige bisque
#7fffd4
#f0ffff
#f5f5dc
#ffe4c4
127,255,212
240,255,255
245,245,220
255,228,196 black blanchedalmond blue
#000000 0,0,0
#ffebcd 255,235,205 blueviolet brown burlywood cadetblue chartreuse chocolate
#0000ff
#8a2be2
#a52a2a
#deb887
#5f9ea0
#7fff00
#d2691e coral #ff7f50 cornflowerblue #6495ed
0,0,255
138,43,226
165,42,42
222,184,135
95,158,160
127,255,0
210,105,30
255,127,80
100,149,237 cornsilk crimson cyan darkblue
#fff8dc
#dc143c
#00ffff
#00008b
255,248,220
220,20,60
0,255,255
0,0,139 darkcyan #008b8b darkgoldenrod #b8860b
0,139,139
184,134,11 darkgray #a9a9a9 169,169,169 darkgreen #006400 0,100,0 darkgrey #a9a9a9 169,169,169 darkkhaki #bdb76b 189,183,107 darkmagenta #8b008b darkolivegreen #556b2f
139,0,139
85,107,47 darkorange darkorchid darkred darksalmon
#ff8c00
#9932cc
#8b0000
#e9967a
255,140,0
153,50,204
139,0,0
233,150,122
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
SVG Colors
479
SVG Colors
Named Numeric Color name Hex rgb Decimal
darkseagreen #8fbc8f darkslateblue #483d8b darkslategray #2f4f4f darkslategrey #2f4f4f
143,188,143
72,61,139
47,79,79
47,79,79 darkturquoise #00ced1 darkviolet #9400d3 deeppink deepskyblue
#ff1493
0,206,209
148,0,211
255,20,147
#00bfff 0,191,255 dimgray dimgrey dodgerblue firebrick floralwhite forestgreen fuchsia gainsboro
#696969
#696969
#1e90ff
#b22222
#fffaf0
#228b22
#ff00ff
#dcdcdc
105,105,105
105,105,105
30,144,255
178,34,34
255,250,240
34,139,34
255,0,255
220,220,220 ghostwhite gold goldenrod gray green greenyellow grey honeydew hotpink indianred indigo ivory
#ff69b4
#cd5c5c
#4b0082
#fffff0 khaki lavender
#f0e68c
#e6e6fa lavenderblush #fff0f5 lawngreen #7cfc00
#f8f8ff
#ffd700
#daa520
#808080
#008000
#adff2f
#808080
#f0fff0
248,248,255
255,215,0
218,165,32
128,128,128
0,128,0
173,255,47
128,128,128
240,255,240
255,105,180
205,92,92
75,0,130
255,255,240
240,230,140
230,230,250
255,240,245
124,252,0
Appendix A — References
480
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Named Numeric Color name Hex rgb Decimal
lemonchiffon lightblue lightcoral lightcyan lightgoldenrodyellow lightgray lightgreen lightgrey lightpink
#fffacd
#add8e6
#f08080
#e0ffff
255,250,205
173,216,230
240,128,128
224,255,255
#fafad2 250,250,210
#d3d3d3
#90ee90
211,211,211
144,238,144
#d3d3d3 211,211,211
#ffb6c1 255,182,193 lightsalmon #ffa07a lightseagreen #20b2aa lightskyblue lightslategray
#87cefa
#778899
255,160,122
32,178,170
135,206,250
119,136,153 lightslategrey lightsteelblue lightyellow lime limegreen linen magenta maroon mediumaquamarine
#778899
#b0c4de
#ffffe0
#00ff00
#32cd32
#faf0e6
#ff00ff
#800000
119,136,153
176,196,222
255,255,224
0,255,0
50,205,50
250,240,230
255,0,255
128,0,0
#66cdaa 102,205,170 mediumblue #0000cd mediumorchid #ba55d3
0,0,205
186,85,211 mediumpurple #9370db mediumseagreen
147,112,219
#3cb371 60,179,113
#7b68ee 123,104,238 mediumslateblue mediumspringgreen
#00fa9a 0,250,154
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
SVG Colors
481
SVG Colors
Named
482
Numeric Color name Hex rgb Decimal
mediumturquoise mediumvioletred midnightblue mintcream mistyrose moccasin
#48d1cc 72,209,204
#c71585 199,21,133 navajowhite navy oldlace olive olivedrab orange orangered orchid
#6b8e23
#ffa500
#ff4500
#da70d6 palegoldenrod #eee8aa palegreen #98fb98 paleturquoise #afeeee palevioletred #db7093
#191970
#f5fffa
#ffe4e1
#ffe4b5
#ffdead
#000080
#fdf5e6
#808000
25,25,112
245,255,250
255,228,225
255,228,181
255,222,173
0,0,128
253,245,230
128,128,0
107,142,35
255,165,0
255,69,0
218,112,214
238,232,170
152,251,152
175,238,238
219,112,147 papayawhip peachpuff peru pink plum powderblue purple red rosybrown royalblue saddlebrown salmon sandybrown
#ffefd5
#ffdab9
#cd853f
#ffc0cb
#dda0dd
#b0e0e6
#800080
#ff0000
#bc8f8f
#4169e1
#8b4513
#fa8072
#f4a460
255,239,213
255,218,185
205,133,63
255,192,203
221,160,221
176,224,230
128,0,128
255,0,0
188,143,143
65,105,225
139,69,19
250,128,114
244,164,96
Appendix A — References
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Appendix A — References
Named Numeric Hex rgb
#fffafa
#00ff7f
#4682b4
#d2b48c
#008080
#d8bfd8
#ff6347
#40e0d0
#2e8b57
#fff5ee
#a0522d
#c0c0c0
#87ceeb
#6a5acd
#708090
#708090
#ee82ee
#f5deb3
#ffffff
#f5f5f5
#ffff00
#9acd32
Color name
seagreen seashell sienna silver skyblue slateblue slategray slategrey snow springgreen steelblue tan teal thistle tomato turquoise violet wheat white whitesmoke yellow yellowgreen
Decimal
46,139,87
255,245,238
160,82,45
192,192,192
135,206,235
106,90,205
112,128,144
112,128,144
255,250,250
0,255,127
70,130,180
210,180,140
0,128,128
216,191,216
255,99,71
64,224,208
238,130,238
245,222,179
255,255,255
245,245,245
255,255,0
154,205,50
SVG Colors
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
483
SVG Colors
Appendix A — References
484
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary action
Glossary
action
Action is a slot that defines a behavior which can be invoked on a Component. See help-BajadocViewer Actions for more information.
administrator
Administrator Security Permissions are defined to be the functions required to configure a system. This person may need to view or edit all the features of the system. Administrator Edit includes creating
Components and Linking Components in addition to editing Properties. See Administrator Security for more information.
agent
An agent is a special Object type that provides services for other Object types. Agents are registered on their target types via the Module manifest and queried via the Registry interface.
alarm
Alarms provide the abiliity to be notified when a special event occurs. See AlarmConsole
or
AlarmPortal for more information.
animate
Animate allows you to change a property's value based on changing information. In the
right-click a property and select Animate.
API
API is a Application Programming Interface. It defines how software engineers access the capabilities of software like the Niagara Framework.
applet
A small Java program that can be embedded in an HTML page. Applets differ from full-fledged Java applications in that they are not allowed to access certain resources on the local computer, such as files and serial devices (modems, printers, etc.), and are prohibited from communicating with most other computers across a network. The common rule is that an applet can only make an Internet connection to the computer from which the applet was sent. See also BAppletView.bajadoc for more technical information.
archive
Archive is a History that is stored in a different station from where it originated.
audit
The Audit keeps a History of changes made by users. If enabled, it registers itself as the Auditor for the system when the service is started. One of the important aspects of security is the ability to analyze what has happened after the fact. See
history-AuditHistoryService for more information.
back
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
485
Glossary
BACnet
Back refers to the last location viewed by the browser. It is required in order to go
BACnet
BACnet refers to A Data Communication Protocol for Building Automation and Control Networks.
Developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning
Engineers (ASHRAE), BACnet is an American national standard, a European pre-standard, and an
ISO global standard. The protocol is supported and maintained by ASHRAE Standing Standard Project
Committee 135. See the BACnet Guide for more information on BACnet in the Niagara Framework.
Baja
Baja is a term coined from Building Automation Java Architecture. The core framework built by Tridium is designed to be published as an open standard. This standard is being developed through Sun's
Java Community Process as JSR 60. See Baja vs Niagara in the Developer Guide for more information.
Bajadoc
Bajadoc is the Baja reference documentation. Baja reference documentation includes both Java
API details as well as Baja slot documentation. See
help-BajadocViewer for more information.
binding
A Binding is used to bind a Widget to a data source. Bindings are bound to one Object using an
Ord. Subclasses are registered as Agents on the type of Objects to which they can be bound to. See also
BBinding.bajadoc for more technical information.
bog file
A Bog file contains Baja Components. It can be a complete Database or any Collection of Components.
A Bog File is a special file that can describe Components in a Database. All views can be used on Components in a Bog File just as if they were in a Station. See Bog Files in the Developer Guide for more information.
bookmark
Bookmark identifies a single bookmark. See
and About the bookmark side bar
for more information. Bajadoc is available at BBookmark.bajadoc.
BooleanPoint
BooleanPoint defines a read only control point with only an output element. Bajadoc is available at BBooleanPoint.bajadoc.
BQL
BQL is an acronym for Baja Query Language. BQL is which is similar to the select statement of Structured Query Language (SQL). It is typically used to provide programmable access to information in
Niagara. See BQL Guide for more information.
bql scheme
The "bql" Scheme is used to encapsulate a BQL query.
browser
A browser is a program used to access Web Pages from a Web Server. A special browser is used within
486
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary build the Workbench to access the Niagara Framework. Other common browsers include Microsoft Internet
Explorer, Mozilla and firefox.
build
The build tool is used to build the Niagara Framework itself. You may utilize this build tool to manage your own Niagara modules. See build.html in the Developer Guide for more information.
cancel
Stop the current Action or ignore changes. See Edit Cancel for more information.
chart
A chart is a graphical representation of data. The HistoryChart
is a view that allows you to view
and configure charts of histories. See “Types of history views” on page 178 for more information.
click
Click
means to press and release the primary or secondary mouse button.
client
The client part of a client-server architecture. Typically, a client is an application that runs on one computer and relies on a server to perform some operations. For example, an e-mail client is an application that enables you to send and receive e-mail.
clipboard
The clipboard contains the results of copy or cut operations and can be used for paste.
collection
A collection represents a group of objects, known as its elements. Some collections allow duplicate elements and others do not. Some are ordered and others unordered. See Collection.bajadoc for more technical information.
color
Color stores a color specification via an alpha, red, green, and blue component. See BColor.bajadoc for more information.
command
component
A Component is the primary building block of the Niagara Framework. See baja-Component for more information.
composite
A Composite allows you to expose child slots of a Component as slots on the parent. See
“About composites” on page 83 for more information.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
487
Glossary connect
connect
Connect refers to entering a valid Address for the SYSTEM to connect, User Name and Pass
Phrase. This creates an active session for use of the system.
console
Console provides a simple runtime console for managing and debugging the station. See
“About the console” on page 37 for more information.
container
Containers allow you to logically group Components. The current Container is the Component that contains the Components in the display window. See baja-Component Containers for more information.
context
Context is used in operations which may perform differently depending on their context. Examples include operations which may require auditing or localization.
control
The control module provides normalized components for representing control points. All control points subclass from the ControlPoint base class. Control points are typically used with the Driver framework to read and write points in external devices. See Control in the Developer Guide for more information.
control point
In the narrowest terms, control points refer to the 8 point types found in the Baja control palette under the “Points” folder. See
“About control points” on page 51.
In broader terms, control points include other components found in both the control and kitControl palettes. Most of these are "classed" from the 8 basic point types. See
“Other control components” on page 52.
ControlPoint is the base class for all point types in the Baja control architecture. A ControlPoint typically maps to one value being read or written via a driver. All ControlPoints have a StatusValue property called "out". ControlPoints inherit from BooleanPoint, EnumPoint, NumericPoint and
StringPoint.
If the predefined proxyExt is not a NullProxyExt then the point is considered a proxy point which means that it is a local representation of a point which actually exists in an external device. The driver framework is used to maintain synchronization.
copy
Copy places a copy of the Selection in the clipboard for a future paste operation. The shortcut is
Ctrl + C (hold down Ctrl and press C). See Edit Copy for more information.
credentials
Manage Credentials is available in the main Tools menu by selecting Manage Creden-
tials...
. You can Reset or Remove selected Credentials or Remove All Credentials. See
“New module wizard” on page 332 for more information.
488
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary
CSS
CSS
CSS is cascading style sheet.
CSV
The CSV ("Comma Separated Values") file format is used to exchange data between applications.
cut
Cut places the Selection in the clipboard for a future paste operation. It is deleted from its current location. The shortcut is Ctrl + X (hold down Ctrl and press X). See Edit Cut for more information.
daemon
Daemon typically refers to the Niagara platform daemon, the server process required by a Niagara host to run a station. There is also a separate“dialup daemon” to handle dialup modem functions.
database
Database is used to store information. Examples of databases include the Registry or a Station database.
debug
Debug refers to testing or correcting software. The Program Debugger provides debug capability for program Components.
delete
Delete removes the current Selection from its parent Container. The shortcut is Delete. See Edit
Delete for more information.
delete links
Delete Links removes the selected links from the parent Container.
dependencies
All Modules include zero or one dependencies element. This element contains zero or more dependency elements which enumerate the Module's dependencies. Dependencies must be resolved by the framework before the Module can be successfully used. Each dependency has one required attribute.
The name attribute specifies the globally unique name of the dependent Module. A dependency may also specify a bajaVersion and/or a vendor version. If the bajaVersion attribute is declared then it specifies the lowest bajaVersion of the dependent Module required. It is assumed that higher versions of a
Module are backward compatible, thus any version greater than the one specified in a dependency is considered usable. Likewise the vendor and vendorVersion may be specified to declare a dependency on a specific implementation of a Module. The vendor attribute may be specified without the vendor-
Version attribute, but not vise versa. The required embed attribute specifies whether the dependency should be enforced on embedded Niagara devices.
The
supports the ability to right click a Module and display all its dependencies.
These dependencies are as declared by the Module's manifest. To compute the dependencies needed to use a specific API a new Dependencies command has been added to the
. This command will compute all the classes and Modules required to use a specific class in the API.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
489
Glossary device extensions
device extensions
DeviceExt is the abstract base class for device extensions which provide feature integrations between the device's native protocol and model and the framework's normalized model. See BDeviceExt.bajadoc for more information.
directory
Directory is the File type used to represent Directories in File space implementations. See BDirectory.bajadoc for more information.
disabled
Status disabled means a user manually disabled the component using the enabled property (enabled = false). Disabled always propagates down. For example if you set the network disabled, that forces all
disconnect
You may logoff the system at any time by Right-clicking the connected system in the tree and select
Disconnect
. This allows you to close a session with a Station without removing it from the tree.
discover
Discover allows you to find items that are defined using a driver’s framework. See
“About Device Discover, Add and Match (Learn Process)” on page 109 and
“About Point Discover, Add and
Match (Learn Process)” on page 126 for more information.
domain
Security Domains may be assigned to any Component or set of Components in the system. For example, security domains may be used to assign Components into application domains such as hvac, fire, and lighting or security domains can be used to assign Components into customer groups such as tenant 1, tenant 2, etc.
double-click
Double-click
means to press and release the primary mouse button twice.
down
Down means a communication error at the network or device level. Down always propagates down.
Down is controlled by the pingFail and pingOk methods. The reason why a device is down is always stored in the health.lastFailCause property.
download
Download refers to passing data down to a device. You may download a Station from its supervisor.
drag
Drag means to move the mouse while pressing the primary mouse button.
driver
Drivers use "Managers" which provide a consistent look and feel for managing configuration and learning of devices and points. The cornerstone of the driver tools is the ability to support batch edits and Learns. See Driver Framework in the Developer Guide for more information.
490
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary duplicate
duplicate
Duplicate copies the current Selection and places a duplicate in the same Container. The shortcut is Ctrl + D (hold down Ctrl and press D). See Edit Duplicate for more information.
edit
Edit refers to changing software. Edit Mode allows you make changes to the system.
element
The elements define the hierarchical structure of a document. The majority of elements have opening and closing Tags. Among these Tags, pieces of text or even the whole documents can be found. There are empty elements which contains only opening Tags without any content.
An element may also model one single piece of information in the Baja control architecture. The most common types of elements are:
•
BooleanElement
•
NumericElement
•
EnumElement
•
StringElement
All elements regardless of their value type share common attributes. Every element has a status property which provides a consistent mechanism to convey point status. Each element also contains a priority level for informational purposes. If the priority is PriorityLevel.none, this is not a prioritized element.
Elements are basic building blocks from which larger, more sophisticated control points are created.
A control point contains one or more input elements and one or more output elements. Elements can also be linked between Baja Objects to move data.
enumeration
Enumeration represents a value data item which has a fixed set of possible values. This set of values is called the Enumeration's Range. The standard enumerations include:
• alarm:AlarmRecordTypes
• alarm:AlarmTransition
• baja:Month
• baja:Weekday
• control:AlarmState
• control:AlarmType
• control:CollectionState
• control:DisableAction
• control:LoopAction
• control:NotifyType
• control:PriorityLevel
• control:Reliability
• control:TotalizationInterval
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
491
Glossary
EnumPoint
• driver:ArchiveMode
• driver:ArchiveResult
• driver:ArchiveState
• driver:PollFrequency
• driver:ProxyState
or BEnum.bajadoc for more information.
EnumPoint
EnumPoint defines a read only control point with only an output element. Bajadoc is available at BEnumPoint.bajadoc.
export
Export refers to providing data from the system for external use. You can export any Table found in the workbench (anything built with bajaui:Table). The Table options menu (that little button to the right of the header), includes a Print and Export command. These commands allow you to export the table to PDF, HTML, or CSV (
ExcelFile ). The export uses the current sort order and visible columns
you have displayed. The Niagara Framework also exports its Database to XML for backup and conversion.
extension
Extensions allow plug-in functionality to support features such as alarming and historical data collection.
facets
Facets represents a facets in the system. See “Facets” on page 14 or BFacets.bajadoc for more
information.
fault
Fault means a configuration error. Faults always propagate down. The framework now performs "fatalFault" checking such as making sure your device is under the right network type. Fatal faults will also be the mechanism used to perform licensing checks. Developers can also manage their fault condition via the configFail() and configOk() methods. The reason why a component is in fault is always stored in the faultCause property.
feature
Feature encapsulates a feature specification for the licensing framework. A feature is uniquely identified by a vendor and feature name. It contains an expiration and a set of optional properties. See also
Feature.bajadoc for more technical information.
file
types.
File represents a file in the file system of a session. See
BogFile for some of the common file
file scheme
The "file" Scheme is used to identify files on the file system. All file ords resolve to instances of javax.baja.file.BIFile. File queries always parse into a FilePath. File ords come in the following flavors:
• Authority Absolute: "//hostname/dir1/dir2"
492
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary filter
• Local Absolute: "/dir1/dir2"
• Sys Absolute: "!lib/system.properties"
• Station Absolute: "^config.bog"
• Relative: "myfile.txt"
• Relative with Backup: "../myfile.txt"
Sys absolute paths indicate files rooted under the Niagara installation directory identified via Sys.get-
BajaHome(). User absolute paths are rooted under the user home directory identified via Sys.getUser-
Home(). In the case of station VMs, user home is the directory of the station Database.
filter find
Filter is used to select specified items. An example is the
Find allows you to search for the selected string. The shortcut is F5. See Search Find for more information.
find files
Find Files allows you to find the all occurances in the files. See Search Find Files for more information.
find next
Find Next allows you to find the next occurance of the selected string. The shortcut is Ctrl + F
(hold down Ctrl and press F). See Search Find Next for more information.
find prev
Find Prev allows you to find the previous occurance of the selected string. The shortcut is Ctrl
+ Shift + F (hold down Ctrl and Shift and press F). See Search Find Prev for more information.
Firefox
Firefox is a browser used to access Web Pages from a Web Server. See http://www.mozilla.org/index.htmlfor more information.
flag
Flags are boolean values which are stored as a bitmask on each slot in a Baja Object. Some flags apply to all slot types, while some only have meaning for certain slot types.
folder
Folder represents a Folder in the file system of a session. See Folder
for more information.
format
Format is used to format Objects into Strings using a standardized formatting pattern language. The format String is normal text with embedded scripts denoted by the the % percent character (use %% to insert a real %). A script is one or more calls chained together using the . dot operator. Calls are mapped
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
493
Glossary forward to methods using reflections. Given call "foo", the order of reflection mapping is:
• special call (see below)
• getFoo(Context)
• getFoo()
• foo(Context)
• foo()
• get("foo")
The following special functions are available to use in a script:
• time() calls Clock.time() to get current time as an AbsTime
• lexicon(module:key) gets the specified lexicon text
Examples of formats:
• "hello world"
• "my name is %displayName%"
• "my parent's name is %parent.displayName%"
• "%value% {%status.flagsToString%} @ %status.priority%"
• "%time().toDateString%"
• * "%lexicon(bajaui:dialog.error)%"
forward
Fox
Forward refers to the next location for the browser to return. It is only available after a back .
Fox is a proprietary protocol which is used for all network communication between Stations as well as between the Workbench and Stations. Fox is a multiplexed peer to peer protocol which sits onto of a TCP connection.
fox scheme
The "fox" Scheme is used to establish a Fox session. Fox is the primary protocol used by Niagara for
IP communication. A "fox" query is formatted as "fox:" or "fox:<port>". If port is unspecified then the default 1911 port is assumed.
FROM
FROM is the mechanism to choose the extent. This may be a History or a class in a Station. See
ExtentBuilder for more information.
gadget
Gadget is a visual representation of an arbitrary Object for views.
Gif
Gif stands for Graphical Interchange Format. It is a file format used for graphical images.
glyph
A Glyph is a visual representation.
GotoFile
Goto File allows you to go to a file that has been indexed with the file indexer. The shortcut is Ctrl +
F3 (hold down Ctrl and press F3). See Search Goto File for more information.
494
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary
GotoLine
GotoLine
Goto Line allows you to go to a line number in the file. The shortcut is Ctrl + G (hold down Ctrl and press G). See Search Goto Line for more information.
handle scheme
The "h" Scheme is used to resolve a Component by its handle. Handles are unique String identifiers for Components within a ComponentSpace. Handles provide a way to persistently identify a component independent of any renames which modify a Component's slot path.
Help
Help refers to the electronic documentation available. It includes electronic manuals as well as context specific help.
history
History is an ordered Collection of timestamped records. Each History is identified by a unique id. Histories can be periodically Archived to a remote History Database (Archive). A HistoryDatabase is a set of histories. History: is also used as a Scheme in Ords to refer to collected histories.
Home
Home refers to the originating page. Your home page in Niagara is the page that you see after you enter your password. It is programmed in your user Component.
host
Host is the navigation node used to organize navigation by hosts. Hosts are the first level of the navigation tree. Hosts represent a physical box. LocalHost is used to represent the local machine. Bajadoc is available at BHost.bajadoc.
HTML
HyperText Markup Language is the primary language for Web Servers. It is used in areas such as the electronic help. A thin client property sheet is available. This interface is built using only HTML,
CSS and JavaScript and doesn't require any Plugins. A Workbench style navbar with paths and drop downs is available, plus field editors for the core types: boolean, int, enum, float, abstime, and reltime.
HTTP
HTTP is short for HyperText Transfer Protocol, the underlying protocol used by the World Wide
Web (World Wide Web). HTTP defines how messages are formatted and transmitted, and what actions
Web Servers and browsers should take in response to various commands. For example, when you enter a URL in your browser, this actually sends an HTTP command to the Web Server directing it to fetch and transmit the requested Web Page. The other main standard that controls how the World Wide Web works is HTML, which covers how Web Pages are formatted and displayed.
HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. This is the main reason that it is difficult to implement
World Wide Web sites that react intelligently to user input. This shortcoming of HTTP is addressed in
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
495
Glossary icon a number of technologies, including Java, JavaScript and cookies.
icon
An icon is a graphical representation. Icons are used in the toolbar and in the tree.
image
Image is a representation of a raster image. Bajadoc is available at BImage.bajadoc.
import
Import refers to receiving data from an external source. The Niagara Framework imports its Database from XML for backup and conversion.
ip scheme
The "ip" Scheme is used to identify a BIpHost instance. Ords starting with "ip" are always absolute and ignore any base which may be specified. The body of a "ip" query is a DNS hostname or an IP address of the format "dd.dd.dd.dd".
Java
Java is a high-level programming language developed by Sun Microsystems. Java source code files (files with a .java extension) are compiled into a format called bytecode (files with a .class extension), which can then be executed by a Java interpreter. Compiled Java code can run on most computers because Java interpreters and runtime environments, known as Java Virtual Machines (VMs), exist for most operating systems, including UNIX, the Macintosh OS, and Microsoft Windows. Bytecode can also be converted directly into machine language instructions by a just-in-time compiler (JIT).
Java is a general purpose programming language with a number of features that make the language well suited for use on the World Wide Web. Small Java applications are called Java Applets and can be downloaded from a Web Server and run on your computer by a Java-compatible World Wide Web browser. For more information, seehttp://java.com andhttp://java.sun.com/.
JavaScript
JavaScript refers to the standard scripting language used in HTML documents. Microsoft Internet Explorer support is discussed at http://msdn.microsoft.com/scripting/jscript/default.htm. Mozilla support is discussed athttp://www.mozilla.org/js/index.htmlSee http://www.ecma-international.org/ publications/standards/Ecma-262.htmfor more information on the official Standard ECMA-262 EC-
MAScript Language Specification.
Jpeg
Jpeg stands for Joint Photographic Experts Group. It is often abbreviated to JPG when the file system is limited to a 3 character suffix. JPEG uses a Lossy compression method to create the final file.
language code
Language Code refers to ISO 639 language code -- two letter, lower-case preferred. See http:// www.loc.gov/standards/iso639-2/langcodes.html for the list.
learn
496
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary left-click
Learn allows you to discover and add items that are defined using the driver framework. See “About
Learn toggle” on page 109 for more information.
left-click
Click
or
Left-click
means to press and release the primary mouse button. For most systems, this is the left mouse button.
lexicon
Lexicon is used to provide support for other languages.
links
Links are the relationships defined between Components. Links provide the means to pass data between Components. See Linking Components in the User Guide or Links in the Developer Guide for more information.
local
Local is a Scheme used in Ords. It is both a Host Scheme and a session Scheme. It represents Objects found within the local VM.
log
Log is used to log events. The LogHistoryService
keeps a History of Niagara log records. If enabled, it registers itself as the LogHandler for the system when the service is started.
logoff
Logoff refers to removing a user from an active session so that a password will have to be entered to logon for use of the system.
logon
Logon refers to entering a valid Address for the SYSTEM to connect, User Name and Pass Phrase.
This creates an active session for use of the system.
match
Match allows you to match items that are discovered.
menu
A Menu is a list of choices. The Niagara Framework uses the main pull down menu and popup menus on the tree and Components. See menu for more information.
Microsoft Internet Explorer
Microsoft Internet Explorer is a browser used to access Web Pages from a Web Server. See http:// www.microsoft.com/iefor more information.
MIME
The Multipurpose Internet Mail Extensions (MIME) provide a mechanism to determine file type in a standardized way.
module
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
497
Glossary module scheme
The first step in understanding the Niagara architecture is to grasp the concept of modules. Modules are the smallest unit of deployment and versioning in the Niagara architecture. A module is:
• A JAR file compliant with PKZIP compression
• Contains a XML manifest in meta-inf/module.xml
• Is independently versioned and deployable
• States its dependencies on other modules and their versions
See baja-Module in the User Guide or Modules in the Developer Guide for more information.
module scheme
The "module" Scheme is used to access BIFiles inside the module jar files. The module Scheme uses the "file:" Scheme's formating where the authority name is the module name. Module queries can be relative also. If the query is local absolute then it is assumed to be relative to the current module. Module queries always parse into a FilePath.
monitor
Monitor refers to observing. The
PingMonitor periodically calls ping on all the Pingables to
monitor network and device health. PingMonitor provides builtin support to generate alarms when pingables are down.
mouse
The mouse is a device which allows you to control the on-screen pointer or cursor.
move
Move is the same as Cut and Paste in one operation. See Edit Move for more information.
Mozilla
Mozilla is a browser used to access Web Pages from a Web Server. See http://www.mozilla.org/index.htmlfor more information.
name map
Name Map defines a new Display Name for a Language Code. You can Add Name Map
to provide a new Display Name for a Language Code. A blank Language Code is used for all languages. You Rightclick on the Property displayNames to delete or rename Name Map and displayNames_xx to delete or rename Name Map (xx) where xx is the Language Code. Bajadoc is available at BNameMap.bajadoc.
nav file
Nav File stores XML nav markup. It allows you to define a navigation tree. You may use the
NavFileEditor to modify this file. Bajadoc is available at BNavFile.bajadoc.
Netscape
Netscape is a browser used to access Web Pages from a Web Server. See http://www.netscape.comfor
more information.
network
Network is a collection of devices.
DeviceManager provides a summary of an attached network.
See BDeviceNetwork.bajadoc for more information.
498
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary
Niagara Framework
Niagara Framework
The Niagara Framework is a system designed to manage and control information. Its primary application is for control systems because of its powerful and flexible integration capabilities. The system is made up of Stations that run the Components of the Niagara Framework and views that provide the ability to view and command these Components. See Baja vs Niagara in the Developer Guide for more information.
normalization
Normalization is the process of removing unnecessary "." and ".." segments from the path component of a hierarchical URI. Each "." segment is simply removed. A ".." segment is removed only if it is preceded by a non-".." segment. Normalization has no effect upon opaque URIs.
null
The null flag indicates that the associated value should not be used. It represents a don't care condition.
It is utilized in combination with priority arrays so that points may take or release control of their level in a priority array based on their current state. It is also utilized in math, logic and other application blocks that take a variable number of inputs. Any input with the null flag set is ignored.
NumericPoint
NumericPoint defines a read only control point with only an output element. Bajadoc is available at BNumericPoint.bajadoc.
object
An Object is the base class required for all objects which conform to the Baja model. See BObject.bajadoc for more technical information. See Object Model in the Developer Guide for more information on the model.
offline
Offline refers to accessing a Bog File file directly when the Station is not running.
open
Open allows you to open any of the following:
•
•
Ctrl + L
•
Ctrl + O
•
•
•
Ctrl + Shift + O
Open Daemon (Niagarad)...
See the File menu reference for more information.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
499
Glossary operator
operator
Operator Security Permissions are defined to be the functions required as a system operator who may need to view or edit only the lowest level features of Components. See Operator Security for more information.
options
Options allow you to customize the framework for the way you use it. It can be selected from the main Menu by selecting Tools > Options. See
“Workbench options” on page 46 for more
information.
ord
Ord is an "Object Resolution Descriptor". An ord is Baja's universal identification system for integrating heterogeneous naming systems into a single String. An ord is composed of one or more queries.
Each query has a Scheme which identifies how to parse and resolve the query into an Object.
ord := query (ws "|" ws query)* query := scheme ws ":" ws body scheme := alpha
(alpha | digit)* body := bodyChar (bodyChar)* alpha := "a"-"z" | "A"-"Z" digit :=
"0"-"9" bodyChar := 0x32 - 0x127 except "|" ws := (space)*
See Naming in the Developer Guide orBOrd.bajadoc for more technical information.
overridden
Overridden indicates that the user has manually overridden the component.
palette
Palette provides a hierarchical view of available components. See “About palettes” on page 16
for more information.
paste
Paste copies the contents of the clipboard to the selected location. The shortcut is Ctrl + V (hold down Ctrl and press V). See Edit Paste for more information.
pathbar
The pathbar is the line available in Workbench to see and select destination references. The pathbar provides two functions. It is automatically updated each time a new view is selected to teach you the
PDF refers to Adobe Portable Document Format (PDF) files.
permissions
Permissions are a property used to define the permissions given to users in a Profile.
pin slots
Pin Slots provides the capability to make Properties of a Component visible in the WireSheet view of the Component. See
in the WireSheet Plugin for more information.
500
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary platform
platform
Platform is the Niagara Platform Definition.
plugin
A Plugin is a visualization for a Component. A WbPlugin is a widget designed to provide plugin functionality in the Workbench tool environment.
Png
PNG stands for Portable Network Graphics. The PNG
ℑ format uses lossless compression .
point extension
Point extensions allow control point behavior to be extended in a consistent manner. Each property of a ControlPoint which subclasses from PointExtension is considered an extension on the point. Extensions allow plug-in functionality such as alarming and historical data collection via special hooks that ControlPoint provides to PointExtension.
Print provides automatic generation of a PDF for a view. Most standard widgets including labels, point widget, tables, Charts, and most layout panes are handled. Access to the PDF visualization is through the Print command in both Workbench and World Wide Web browser.
profile
Security Profile may be assigned to any Component or set of Components in the system. Users are assigned a security profile. The list of profile names map to Profile instances which are accessed
from the UserService . A user can be assigned one profile. Profiles provide a convenient way to con-
figure Security Permissions on batches of users. Each profile is configured with a set of privileges for each Security Domain.
properties
Properties are the visible data associated with a Component. They provide the primary means of interacting with Components. See help-BajadocViewer Properties for more information.
proxy
Proxy is used locally to represent a remote Object. See “About the proxy extension” on page 63 for
more information.
ProxyExt
ProxyExt is the point extension supported in ControlPoints which are proxies for point data in an external system. See
“About the proxy extension” on page 63.
Px file
A Px file contains Baja Components. It can be a complete Database or any Collection of Components. A Px File is a special file that can provide a visualization for Components in a Database. The
PxEditor is a Plugin used to create and modify Px files. All views can be used on Components in a PX
just as if they were in a Station. See Bog Files in the Developer Guide for more information.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
501
Glossary query
query
Query is part of an "Object Resolution Descriptor". An ord is composed of one or more queries. Each query has a Scheme which identifies how to parse and resolve the query into an Object. A query is made up of a Scheme and a body. See Naming in the Developer Guide orBOrd.bajadoc for more technical information.
range
Range of en Enumeration is a range of ordinal/name pairs. See Enum Range Dialog or BEnum-
Range.bajadoc for more information.
redo
Redo causes an Action to be redone. It is only available after an undo. The shortcut is Ctrl + Alt
+ Z (hold down Ctrl and Alt and press Z). See Edit Redo for more information.
refresh
Refresh a page after its HTML source has been edited or if you encounter a reason to reload.
registry
The registry is a term for a small Database built by Niagara Framework whenever it detects that a module has been added, changed, or removed. The registry may be used to interogate the system for summary information about the Modules, types, Ord Schemes, and Agents installed without loading
Modules into memory. See RegistryDatabase.bajadoc for more information.
rename
Rename allows you to change the name of a Component. It is available on a Component’s rightclick menu.
reorder
replace
Replace allows you to replace the next occurance in the file. The shortcut is Ctrl + R (hold down
Ctrl and press R). See Search Replace for more information.
replace files
Replace Files allows you to replace the all occurances in the files. See Search Replace Files for more information.
restart
Restart a Station. This causes a Station to be restarted.
right-click
Right-click
means to press and release the secondary mouse button. For most systems, this is the right mouse but-
502
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary save ton.
save
Save causes a program to be evaluated and saved in the Database if valid. The shortcut is Ctrl +
S (hold down Ctrl and press S).
scheme
Scheme is part of an "Object Resolution Descriptor". The scheme identifies how to parse and resolve the query into an Object. The scheme "local" is both a Host scheme and a session scheme. It represents objects found within the local VM. Some common schemes include:
• ip Scheme
• fox Scheme
• file Scheme
• module Scheme
• station Scheme
• slot Scheme
• handle Scheme
• spy Scheme
• bql Scheme
See Naming in the Developer Guide orBOrd.bajadoc for more technical information.
section
Section is a portion of a Print document that is capable of containing Gadgets.
security
Security in the Niagara framework covers some broad topics:
• Authentication: Logging in and verifying a user
• Encryption: When and how to use cryptography to secure data
• Permissions: Configuring and verifying user Permissions on objects
• Auditing: Logging user actions to create an audit trail
The heart of the Niagara security architecture is embodied by the
UserService . The UserService con-
tains a Table of SecurityDomains (see
Security model overview ), Profiles (see Security model overview ), and
s. Domains are used to build groups of objects with common security needs. Profiles are used to define
Permissions across zero or more Domains. Users are assigned to a Profile and used
to represent an entity (human or machine) requiring authentication and security checks. See Security in the Developer Guide for more information.
SELECT
SELECT is the primary statement used to access information in a Database. See
workbench:ProjectionBuilder for more information.
selection
The selection is the set of currently selected items. Most operations in the system act on the selected items.
servlet
A Java program that runs as part of a network service, typically an HTTP Web Server and responds to
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
503
Glossary sidebar requests from clients. The most common use for a servlet is to extend a Web Server by generating
World Wide Web content dynamically. For example, a client may need information from a database; a servlet can be written that receives the request, gets and processes the data as needed by the client and then returns the result to the client. Applets are also written in Java but run inside the JVM of an
HTML browser on the client. Servlets and Applets allow the server and client to be extended in a modular way by dynamically loading code which communicates with the main program via a standard programming interface. See also HttpServlet.bajadoc for more technical information.
sidebar
Sidebar allows you to choose whether to view sidebars by selecting Window > Side Bars
> Show Side Bar
from the main menu. You can also select which sidebars you would like to view.
See “About side bars” on page 27 for more information.
slot
Slots are the building blocks for defining Niagara Components. There are three types of slots:
• Property
• Action
• Topic
See Slots in the Object Model section of the Developer Guide for more information.
slot scheme
The "slot" Scheme is used to resolve a Value within a Complex by walking down a path of slot names.
Slot queries always parse into a SlotPath.
space
Space defines a group of Objects which share common strategies for loading, caching, lifecycle, naming, and navigation.
spy scheme
The "spy" Scheme is used to navigate spy pages. The javax.baja.spy APIs provide a framework for making diagnostics information easily available.
SQL
SQL is an acronym for Structured Query Language. SQL is an American National Standards Institute
(ANSI) standard for accessing Database systems.
stale
Stale indicates that a situation has occurred which renders data untrustworthy. How stale is determined is a driver specific issue. However the common case is that a period of time has elapsed without a successful read. TuningPolicy provides a staleTime property for configuring this period of time.
station
Station is the Component which represents a Station in the Baja framework. See baja-Station in the User Guide or Station in the Developer Guide for more information.
station scheme
The "station" Scheme is used to resolve the ComponentSpace of a station Database.
504
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary status
status
Status provides a bit mask for various standardized status flags in the Baja control architecture. Plus it provides for arbitrary extensions using facets.
See BStatus.bajadoc for more information.
statuscolors
StatusColors are configurable by the baja lexicon and accessible by the Status API. You may use the
LexiconEditor to change these values. Entries include alarm, disabled, fault, down, overridden and
stale :
Status.alarm.bg=#FFFF0000 Status.alarm.fg=#FFFFFFFF Status.disabled.bg=#FFD88AFF
Status.disabled.fg=#FF000000 Status.fault.bg=#FFFFAA26 Status.fault.fg=#FF000000
Status.down.bg=#FFFFFF00 Status.down.fg=#FF000000 Status.overridden.bg=#FF86BEFF
Status.overridden.fg=#FF000000 Status.stale.bg=#FF00FF00 Status.stale.fg=#FF000000
The WireSheet options allow you to choose whether to Show Status Colors
.
StatusFormat
StatusFormat is used to provide a simple pattern language for formating status values. Patterns are strings with script commands embedded using the % character:
"Value=%value% Status=%status%"
Examples:
• %value% = value using facets
• %value(precision=2)% = value using 2 decimal places
• %value(units=null)% = value using facets with no units
• %value(units=null|precision=i:2)% = combination of previous two
• %status% = status fully specified
• {%status.flags%} %status.facets% = same as %status%
• %status.flags% = status flags, but not facets
• %status.facets% = status facets, but not flags
• %status.activeLevel% = status active level
• %value% {%status.flags%} @ %status.activeLevel%
The BNF grammer for the pattern language:
script := valScript | statusScript valScript := "value" [ "(" valFacets ")" ] valFacets := valFacet [ "|" valFacet ]* valFacet := valAddFacet | valRemoveFacet valAddFacet := name "=" value valRemoveFacet := name "=null" value := DataUtil.marshal & unmarshal statusScript := "status" [ "." statusSubset ] statusSubset := statusFlags | statusFacets | statusFacetKey statusFlags := "status.flags" statusFacets
:= "status.facets" statusFacetKey := "status." name
See StatusFormat for more information.
StringPoint
StringPoint defines a read only control point with only an output element. Bajadoc is available at BStringPoint.bajadoc.
subclasses
Subclasses provides a subclass tree of all that are subclassed from this item. See help-BajadocViewer
Subclasses for more information.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
505
Glossary tab
tab
Tab allows you to view multiple views in the same Window. See
“Creating tabs in the view pane” on page 45 for more information.
table tag
Table displays a grid of rows and columns. See BTable.bajadoc for more technical information.
An Element bounded by the marks "<" and ">" is a Tag. Tags are used to mark the semantic or the structure of a document. HTML and XML use tags. A sample is the tag <title> to mark the be-
ginning of a title. See HTML Tags in the WbHtmlView
for more information on tags supported by the
HtmlView Plugin.
toolbar
A Toolbar is a row of button used to provide quick access to commonly used features. In the Niagara
Framework there are two rows of buttons on the toolbar. The first are the common buttons that are always available. The second are the buttons based on the current view, mode and Selection.
topic
Topic defines a Slot which indicates an event that is fired on a Component. See help-Bajadoc-
Viewer Topics for more information.
tree
The tree is the graphical representation of the hierarchy of the Components in the system. It provides a view of each Container and its contents when expanded. See Namespace Sidebar for more information.
undo
This reverses the last Action as if it had not been performed. In Niagara it is only available for some actions. The shortcut is Ctrl + Z (hold down Ctrl and press Z). See Edit Undo for more information.
up level
upload
Upload refers to receiving data from a device. In Niagara you may upload a Station to its supervisor so that you have a backup of its Database.
URI
Uniform Resource Identifiers (URIs, aka URLs) are short strings that identify resources in the World
Wide Web: documents, images, downloadable files, services, electronic mailboxes, and other resources. They make resources available under a variety of naming schemes and access methods such as HT-
506
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
Glossary
URL
TP, FTP, and Internet mail addressable in the same simple way. They reduce the tedium of "log in to this server, then issue this magic command ..." down to a single click.
It is an extensible technology: there are a number of existing addressing schemes, and more may be incorporated over time.
URL
Uniform Resource Locator (URL) is the standard way of addressing over the Internet. The Niagara
Framework uses this convention for many of its resource locations.
user
A User is a valid user name. It is used to logon to the system with a valid password.
vector
Vector is a dynamic Struct which allows Properties to be added at runtime. See
mation.
view
There are many ways to view your system. One way is directly in the tree. In addition, you can Right-
Web
Web refers to the World Wide Web. It is a system of Internet servers that support specially formatted documents. The documents are formatted in a markup language called HTML (HyperText Markup
Language) that supports links to other documents, as well as graphics, audio, and video files. This means you can jump from one document to another simply by clicking on hot spots. Not all Internet servers are part of the World Wide Web. There are several applications called World Wide Web browsers that make it easy to access the World Wide Web.
Web page
A Web Page is a document on the World Wide Web. Every Web page is identified by a unique URL
(Uniform Resource Locator).
Web server
A Web Server is a computer that delivers (serves up) Web Pages. Every Web server has an IP address and possibly a domain name. For example, if you enter the URL http://www.niagaraframework.com/ in your browser, this sends a request to the server whose domain name is niagaraframework.com. The server then fetches the page named index.html and sends it to your browser. Any computer can be turned into a Web server by installing server software and connecting the machine to the Internet.
There are many Web server software applications, including public domain software from NCSA and
Apache, and commercial packages from Microsoft, Netscape and others.
wheel
Wheel means to rotate the mouse wheel to scroll up or down.
WHERE
The Where clause is used to specify that only certain rows of the Table are displayed, based on the criteria described in that Where clause. See
workbench:QualifierBuilder for more information.
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
507
Glossary widget
widget
Widget is a class used to create light weight user interface components which can seamlessly be used in both the bajaui toolkit and in a 1.1 Applet environment.
window
A Window is a graphical area used to present a view of the system. This can refer to the primary
wizard
Wizards are used to guide the user through common tasks. Some common wizards include:
• New Station Wizard
• Commissioning Wizard
• New Module Wizard
Workbench
The Workbench is Niagara's Integrated Development Environment (IDE) for non-programmers.
XML
eXtended Markup Language (XML) is a standard for tagging data. It is a subset of the Standard Generalized Markup Language (SGML) like HTML. See XML in the Developer Guide for more information.
508
Niagara
AX
NiagaraAX User Guide Published: June 24, 2005
डाउनलोड
सार्वजनिक लिंक अपडेट किया गया
आपकी चैट का सार्वजनिक लिंक अपडेट कर दिया गया है. You may view and manage your chat links after registration here.
दस्तावेज़ सार्वजनिक लिंक
विज्ञापन
