Niagara LonWorks Integration Guide

Transcription

Technical Publications
Niagara LonWorks
Integration Guide
Revised: December 16, 2002
Tridium, Inc.
3951 Westerre Parkway • Suite 350
Richmond, Virginia 23233
USA
http://www.tridium.com
Phone 804.747.4771 • Fax 804.747.5204
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.,
3951 Westerre Parkway, Suite 350
Richmond, Virginia 23233.
The confidential information contained in this document is provided solely for use by Tridium employees, licensees, and
system owners. It 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 given herein. The information in this document is subject to change without notice.
The release described in this document may be protected by one of more U.S. patents, foreign patents, or pending
applications.
Trademark Notices: Microsoft and Windows are registered trademarks, and Windows 95, Windows NT, and Internet
Explorer are trademarks of Microsoft Corporation. Java and other Java-based names are trademarks of Sun Microsystems
Inc. and refer to Sun’s family of Java-branded technologies. Communicator and Navigator are registered trademarks of
Netscape Communications Corporation. Echelon, LON, LonMark, LonTalk, and LonWorks are registered trademarks of
Echelon Corporation. Tridium Niagara, the Niagara Framework, Vykon, WorkPlace Pro, Web Supervisor, JACE-4, JACE-5,
and JACE-NP are trademarks of Tridium Inc. All other product names and services mentioned in this publication that are
known to be trademarks, registered trademarks, or service marks have been appropriately capitalized and are the properties
of their respective owners.
© 2002, Tridium, Inc.
All rights reserved.
CONTENTS
About This Document
PREFACE
Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPTER
CHAPTER
CHAPTER
1
2
3
9
9
Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Important Information Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Commonly Used Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Introduction to Open Systems
1-1
Parts of a Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1
Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-3
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-3
Interconnectivity in Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-5
Gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-5
Host Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-7
Openness in Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-9
LonWorks Overview
2-1
LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-1
Echelon Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-2
Applications and Distribution Channels . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-3
LonMark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-3
LonWorks Design Concepts
3-1
LANs and LONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-1
LonTalk Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-2
Smart Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-2
Niagara Release 2.3
1
Contents
CHAPTER
CHAPTER
2
4
5
Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-3
Centralized Control System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-3
Fully Distributed (Flat) Control System . . . . . . . . . . . . . . . . . . . . . . . .
3-4
Semi-Distributed Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-5
LonWorks Architecture
4-1
Elements Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-1
The Neuron Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-2
Neuron Chip Data Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-2
Processing Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-3
Network Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-3
Domain Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-5
Address Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-5
Network Variable Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-5
Hosted Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-6
Transceivers, Media, and Network Topology . . . . . . . . . . . . . . . . . . . . . . .
4-6
FTT-10 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-7
Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-10
Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-11
Routers versus Repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-11
How Learning Routers Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-12
Learning Routers versus Configured Routers . . . . . . . . . . . . . . . . . . .
4-13
LonWorks Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-13
LonTalk Protocol
5-1
LonTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-2
A Closer Look at the LonTalk Protocol . . . . . . . . . . . . . . . . . . . . . . . .
5-2
Logical Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-4
Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-4
Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-5
Node Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-6
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-6
Addressing Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-7
Routing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-7
Communications Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-7
Acknowledged Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-8
Request/Response Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-8
Niagara Release 2.3
Contents
CHAPTER
CHAPTER
6
7
Repeated Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-8
Unacknowledged Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-8
Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-9
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-9
Free Buffer Wait Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-9
Transaction Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-10
Receive Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-10
Repeat Timer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-10
Optional Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-10
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-11
Interoperability
6-1
LonMark Interoperability Association . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-1
Network Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-2
Network Variable Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-3
Standard Network Variable Types (SNVTs) . . . . . . . . . . . . . . . . . . . .
6-3
Structured SNVTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-4
Enumerated Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-5
Configuration Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-5
Explicit Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-6
Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-6
Pre-Programmed (Configurable) Devices. . . . . . . . . . . . . . . . . . . . . . .
6-6
Programmable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-6
Functional Profiles and Application Interface. . . . . . . . . . . . . . . . . . . . . . .
6-7
LonMark Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-8
Network Variable Typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-10
Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-10
Program IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-11
Network Management Tools
7-1
About Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-1
System Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-2
Structure of a Network Management Tool . . . . . . . . . . . . . . . . . . . . . . . . .
7-3
Network Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-4
LonWorks Network Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-4
Network Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-5
LNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-6
Niagara Release 2.3
3
Contents
CHAPTER
CHAPTER
4
8
9
Third Party Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-7
Application Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-8
Configurable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-8
Programmable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-9
Application Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-9
Niagara LonWorks Service
8-1
Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-1
Device Manager View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-2
Device Manager Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-3
Link Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-5
Link Manager View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-6
Message Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-7
Link Manager Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-8
Utilities Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-8
Utilities Manager View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-9
LON Utilities and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-9
Status Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-32
LonWorks Service Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-32
General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-32
Poll Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-33
DeviceStatus Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-34
Netmgmt (Network Management) Properties . . . . . . . . . . . . . . . . . . .
8-35
LonComm Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-37
LonWorks Service Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-38
dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-38
bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-38
find. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-39
enAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-39
disAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-39
Niagara LonWorks Tree Structure
9-1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-1
LonTrunk Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-1
LocalLonDevice (LLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-2
LocalLonDevice Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-3
Replacing a Deleted LocalLonDevice. . . . . . . . . . . . . . . . . . . . . . . . . .
9-6
Niagara Release 2.3
Contents
CHAPTER
CHAPTER
CHAPTER
10
11
12
LonTemp Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-6
Local Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-7
Niagara LonWorks Shadow Objects
10-1
Shadow Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1
General Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1
Node Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-2
Controller Type Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-2
Shadow Object Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-5
fetch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
download. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
enableCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
disableCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
wink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
readProperty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-6
Niagara LonWorks Dynamic Device
11-1
When Using the Dynamic Device Object . . . . . . . . . . . . . . . . . . . . . . . . .
11-1
Dynamic Device Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11-2
LON Schema Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11-2
LonSchemaManager Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11-3
Building Niagara LonWorks Solutions
12-1
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-1
Planning Network Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-2
Determine Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-2
Determine Station Database Structure . . . . . . . . . . . . . . . . . . . . . . . .
12-3
Guidelines for Structuring a LonWorks Database . . . . . . . . . . . . . . .
12-3
LonWorks Network Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-4
Addressing a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-4
Binding Network Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-5
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-5
Network Installation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-6
Niagara Release 2.3
5
Contents
Using the Niagara LonWorks Service to Establish LON Nodes for a New
Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Using the Niagara LonWorks Service to Learn an Existing LonWorks
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPTER
APPENDIX
APPENDIX
6
13
A
B
User Interface
12-7
13-1
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-1
Building a User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-1
Create the Necessary Logic for Passing Data . . . . . . . . . . . . . . . . . . .
13-2
Create the Necessary Logic to Expose Values and Status . . . . . . . . .
13-3
Create the Necessary Logic to Push Commands . . . . . . . . . . . . . . . . .
13-4
Advanced LonWorks Procedures
A-1
Resolving Duplicate Subnet/Node Address . . . . . . . . . . . . . . . . . . . . . . . .
A-2
Changing Subnet/Node Address of a Node. . . . . . . . . . . . . . . . . . . . .
A-2
Setting a Node’s Status to Unconfigured . . . . . . . . . . . . . . . . . . . . . .
A-3
Discovering Nodes on Other Domains . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-3
Discovering the Working Domain of a LonWorks Device . . . . . . . . .
A-4
Changing the Domain ID of the LonWorks Service . . . . . . . . . . . . . .
A-5
Devices on Different Domains, But the Same Channel. . . . . . . . . . . . . . .
A-5
Working With Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-7
About Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-7
Niagara Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-8
Working with an Unmanaged Routed Network . . . . . . . . . . . . . . . . .
A-9
Working with a Managed Routed Network. . . . . . . . . . . . . . . . . . . . .
A-10
Troubleshooting a LON Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-11
Link Status Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-11
Troubleshooting LonWorks Devices and Twisted Pair Networks . . .
A-12
SNVT Reference
B-1
Standard Network Variable Types (SNVTs) . . . . . . . . . . . . . . . . . . . . . . .
B-1
Network Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-1
SNVTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-2
Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-3
Naming Convention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-4
Engineering Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-4
Working With LonWorks Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-5
Niagara Release 2.3
Contents
Niagara Shadow Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-9
Shadow Object Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-10
Getting Some Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-13
SNVT Master List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-17
Working With SNVTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-19
SNVT_temp_p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-20
SNVT_lev_percent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-20
SNVT_lev_disc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-21
SNVT_switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-22
SNVT_hvac_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-23
SNVT_hvac_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-24
SNVT_hvac_overid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-26
SNVT_hvac_emerg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-27
SNVT_temp_setpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-28
SNVT_occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-30
SNVT_date_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-32
SNVT_time_stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-32
Converting LonWorks Data Using Program Objects . . . . . . . . . . . . . . . .
B-33
About Conversion Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-33
Creating Your Own Conversion Objects . . . . . . . . . . . . . . . . . . . . . .
B-33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Examples
B-37
Niagara Release 2.3
7
Contents
8
Niagara Release 2.3
P R E F A C E
About This Document
This document is intended to help you use the LonWorks service for a Niagara
station. Included is detailed background information about LonWorks®, including
design concepts, architectures, the LonWorks protocol, interoperability issues, and
LonWorks network management tools.
Later chapters provide explanations of the Niagara LonWorks service, including the
various “manager” views, as well as various container, device, and shadow objects.
Included are procedures to build Niagara LonWorks solutions, with appendixes
covering advanced LonWorks procedures and SNVT reference material.
This preface includes the following sections:
•
•
•
•
•
Intended Audience
Document Summary
Formatting Conventions
Related Documentation
Commonly Used Terms
Intended Audience
The following people should use this document:
• Vykon systems integrators and installers responsible for initial setup and
ongoing configuration of JACE controllers that are part of a LonWorks
integration.
• Vykon application programmers.
Reading this guide will give you a basic familiarity with these applications as you
follow along with the basic procedures. It is recommended you use this guide in your
pre-course studies before attending formal training in Tridium, Richmond, VA.
Niagara Release 2.3
9
About This Document
Document Summary
Document Summary
This document contains a table of contents, preface, 13 chapters, and two appendixes,
summarized below:
This preface, including a small glossary (see “Commonly Used Terms,” page 13).
Chapter 1, “Introduction to Open Systems,”—Introduces typical HVAC control
system components and discusses general connectivity.
Chapter 2, “LonWorks Overview,”—Introduces LonWorks technology. Includes
background information about the Echelon Corporation and LonMark Association.
Chapter 3, “LonWorks Design Concepts,”—Discusses design concepts central to the
LonWorks technology.
Chapter 4, “LonWorks Architecture,”—Explains the various elements of LonWorks
technology, including the Neuron chip, hosted nodes, transceivers and media.
Chapter 5, “LonTalk Protocol,”—Explains LonTalk protocol components. Includes
topics on logical addressing, message services, timers, priority, and authentication.
Chapter 6, “Interoperability,”—Discusses different levels of interoperability.
Includes information about network variables, SNVTs, configuration properties,
LonMark objects and functional profiles, naming conventions and program IDs.
Chapter 7, “Network Management Tools,”—Discusses the design and purpose of
various LonWorks network management tools, including information on network
databases and application programming.
Chapter 8, “Niagara LonWorks Service,”—Starting point for Niagara-specific
LonWorks information. Explains the different manager views of the LonWorks
service, including the Device Manager, Link Manager, and Utilities Manager. Also
discusses properties and commands for the LonWorks service.
Chapter 9, “Niagara LonWorks Tree Structure,”—Explains the Niagara station
structure for LonWorks, including containers, LocalLonDevice, and local library.
Chapter 10, “Niagara LonWorks Shadow Objects,”—Explains universal topics for
various Niagara shadow objects, including properties and commands.
Chapter 11, “Niagara LonWorks Dynamic Device,”—Discusses the special
DynamicDevice object, including its LonSchemaManager view.
Chapter 12, “Building Niagara LonWorks Solutions,”—Discusses different
planning, design, and installation techniques for a Niagara LonWorks network.
Chapter 13, “User Interface,”—Discusses the general techniques for exposing
LonWorks data in a user interface for monitoring and control.
Appendix A, “Advanced LonWorks Procedures,”—Discusses advanced networking
techniques such as resolving duplicate device addresses, discovering nodes on other
domains, working with routers, and basic troubleshooting concepts.
Appendix B, “SNVT Reference,”—Working with SNVTs and shadow objects in a
Niagara station, using specific examples. Includes reference data on popular SNVTs.
10
Niagara Release 2.3
About This Document
This document uses the following text-formatting conventions:
• Bold text indicates an important keyword, a keyboard key name, or an
interface object name. For example, the ENTER key, or the File menu.
• CAPITAL letters are used for acronyms, such as WPP (WorkPlace Pro). They
are also used to identify keyboard keys in instructions. For example, “Press
ENTER.” or “Press CTRL+C.”
• Italic text is used for emphasis. It is also used to refer to the titles of other
publications and document filenames. For example, The Microsoft Manual of
Style or Niagara Web Solutions Guide.
• Italic text is also used for non-literal text that represents a variable. For
example, station_name or DONOFF_n.
• “Quotation marks” are used to refer to the names of sections within the current
document. For example, see “Paragraph Styles” for additional information.
• <Text between brackets> is used as a placeholder for user-supplied values.
For example, <password>.
• <Text between brackets> is also used to indicate a variable in contexts where
italic text is not appropriate or is not easily discernible from other text.
For example, D:\niagara\<release number>\stations.
Important Information Indicators
In addition to text formatting, this document uses important information indicators,
as listed below:
Note
Caution
Tip
Refer to
Notes typically contain significant details related to the topic in the nearby text.
They alert you to important information that might otherwise be overlooked.
Cautions remind you to be careful. There is a chance that you could perform an
action that cannot be undone, might produce unexpected results, or might cause lost
data. Cautions typically explain why the action is potentially problematic.
Means a best practice or other helpful instruction. Tips typically contain
recommendations that will help you use the product more effectively.
“Refer to” references point to other documents that contain additional information
on the current topic. The reference includes the name of the document, and if
applicable, the chapter name and number where the additional information appears.
Niagara Release 2.3
11
About This Document
For general information on networking and connectivity, refer to the Niagara
Networking & Connectivity Guide.
Other related documents are listed in sections below.
Sources
The following sources were used in the preparation of this document, and are
gratefully acknowledged.
• LonWorks Based Controls for Building Automation Systems, University of
Wisconsin-Madison, Las Vegas, NV, March 2000.
• LonWorks Technology Device Data, DL159/D Rev.1, 1996, Motorola Inc.
• LonMark Application Layer Interoperability Guidelines (078-0120-01) 1996.
LonMark Interoperability Association, Palo Alto, California.
• LonMark Layer 1-6 interoperability Guidelines (078-0014-01). 1996.
LonMark Interoperability Association, Palo Alto, California.
• Echelon Corporation, “LonWorks Glossary of Technical Terms”, available at
http://www.echelon.com/Support/KnowledgeDB/FAQ_Glossary/default.htm.
• Distributed Intelligence Control Networks (302581). 1994. National Electrical
Contractors Association, Bethesda, Maryland.”
Additional Information
For a further understanding of related topics, refer to the various LonMark
documents for interoperability guidelines available for download from the LonMark
Interoperability Association, San Jose, CA.
At the time of this writing, the hyperlink to these documents is:
http://www.lonmark.org/products/guides.htm#guidelines
12
Niagara Release 2.3
About This Document
Commonly Used Terms
Commonly Used Terms
Throughout this document, references are made to acronyms and terms encountered
with a LonWorks integration. This section provides definitions for these terms and is
intended to ensure their consistent use.
address table
A table loaded into a Neuron chip that defines the groups to which the LonWorks
device belongs and the destinations to which it can send bound network variables and
explicit messages.
application image
The portion of memory of a LonWorks device that contains the executable form of
an application program and its hardware, I/O, and transceiver configuration
information. Devices from different manufacturers can have the same application
image. For example, in a factory automation system, all conveyor belt motor devices
could contain the same application image. The application image for a device can be
loaded when the device is manufactured or it can be loaded over the network at
installation time using a network management tool.
authentication
In addition to using authentication as it relates to password access, the term also has
meaning in the LonWorks domain. As it relates to Echelon devices, authentication
means one of two things. First, if authentication is enabled on an Echelon device,
only network management tools using authentication messages can change that
device's configuration. Next, network variables can be configured to accept only
authenticated updates.
binding
The process that defines logical connections between LonWorks devices. Bindings
define the data that devices share with one another.
channel
The communications media that connect LonWorks devices. Segments connected via
a physical layer repeater are considered a single channel. LonWorks routers are used
to connect two channels.
configuration network
variable
A special class of network variable used to store network-modifiable application
configuration data. Configuration network variables are always inputs (NCIs). For
Neuron-based nodes, the contents of configuration network variables can be stored
in on-chip EEPROM, off-chip EEPROM, flash, or NVRAM. For hosted nodes, it is
the responsibility of the host to store configuration values.
configuration properties
Configuration properties are used to configure the operation of a device.
Configuration properties may be implemented using configuration network
variables, or they may be implemented as configuration parameters stored in a data
block that is read and written using the LonTalk file transfer protocol or direct
memory access.
configured device
A device state where the device has both an application image and a network image.
This state indicates that the device is ready for network operation.
Niagara Release 2.3
13
About This Document
Commonly Used Terms
distributed control
system
A system of dividing automation control into several areas of responsibility, each
managed by its own controller or processor, with the whole interconnected to form a
single entity usually by communication buses of various kinds.
domain
A logical collection of devices on one or more channels. Communications can only
take place among devices configured on the same domain.
domain ID
The top level of the LonTalk addressing hierarchy of domain, subnet, and node. The
domain ID can be 0, 1, 3, or 6 bytes long.
enumeration
Enumerations are integer lists, where each included integer corresponds to a specific
state, command, priority, or other entity. In Niagara, variable types (data types or data
species) often include one or more data fields using an enumeration. Each
enumeration type is defined, for example, the enumeration WeekdayEnum is: Sun
(0), Mon (1), Tue (2), Wed (3), Thu (4), Fri (5), Sat (6).
explicit message
Low-level messages that application devices use to communicate with one another.
Each message contains a message code that identifies the type of message and the
action to be taken when the message is received. Unlike implicit messaging, the
device is responsible for building, sending, and responding to messages.
external interface
The logical interface to a device, which specifies the number and types of LonMark
objects, the number, types, directions, and connection attributes of network variables,
and the number of message tags. The program ID field is used as the key to identify
each external interface. Each program ID uniquely defines the static portion of the
external interface for a device. However, it is possible for two devices (through the
use of dynamic network variables) to have the same program ID, but different
external interfaces.
fan in
A connection where the outputs on multiple devices are directed to a single input on
another device.
fan out
A connection where the output on a single device is directed to an input on multiple
other devices
field bus
Refers to an all-digital, serial, two-way communications architecture that includes
sensors and actuators, smart devices and controllers, stand-alone processors, and user
interface appliances interconnected on a single, fully interoperable network.
functional profile
Functional profiles are developed through a review and approval process that defines
functionality for devices. Profiles determine which network variables are used in a
device and they define the programmability of a device. Some devices are completely
programmable, meaning you can use a field programming tool to completely redefine
the application for the device. Other devices are only configurable, meaning you
cannot program them outside of their application bounds. Typically, NCIs are used to
configure how device I/O is used.
14
Niagara Release 2.3
About This Document
Commonly Used Terms
group
A logical collection of devices within a domain. Unlike a subnet, devices are grouped
together without regard for their physical location in the domain. The number of
groups to which a device may belong is determined by the number of available
address table entries on it, which is set by the Neuron application, but cannot exceed
15. Groups and group membership are defined during binding.
implicit message
A form of messaging in which the Neuron chip firmware builds and sends network
variable update and explicit messages using information contained in tables stored in
its EEPROM. Implicit addressing is established during binding. Also see explicit
message.
interoperability
The ability of multiple vendors' products to be integrated into one flexible system
without using custom integration products. There are varying degrees of
interoperability.
link
A link is a binding between two properties—it is the standard mechanism to associate
objects with one another in the Niagara Framework. To establish a link, you go
through a process whereby you attach an output property of an object to an input
property of another object. Links are only established from an object and a property
to another object and a property. Linked properties must use the same variable type
(data type or data specie).
LNS
LonWorks Network Services architecture.
LON
Local Operating Network. LON is an acronym coined by Echelon Corporation and
refers to an intelligent control network that facilitates communication between a
group of devices that sense, monitor, communicate, and control. LON networks are
being used today in various market segments including building automation,
industrial automation, power/utility automation, and transportation. Common
applications include HVAC systems, lighting systems, alarms and security devices,
medical safety equipment, power metering, load management, and so on.
There are a variety of LON-related terms that are used and confused within the
industry today. These include:
LonMark: Refers to the mark signifying that a product has met LonMark guidelines
that allow it to interoperate with other LonMark devices on a LON. LonMark
certification is granted through the LonMark Interoperability Association.
LonTalk: Refers to Echelon's open-architecture communications protocol used by
all LonWorks-based devices. The LonTalk protocol implements the entire seven
layers of the OSI model using a mixture of hardware and firmware on a device known
as a Neuron chip developed by Echelon.
LonWorks: Refers to the collective hardware and software technology developed by
Echelon to provide an off-the-shelf, peer-to-peer networking technology platform for
designing and implementing interoperable control networks.
Niagara Release 2.3
15
About This Document
Commonly Used Terms
LonWorks router
A LonWorks device that physically connects two LonWorks channels, which can be
used join segments of different media types. A LonWorks router contains two
Neurons and two transceivers, each watching a separate channel. Each side of the
router can receive a packet, make a decision as to whether the packet needs to be
transmitted, and transmit the packet on the other side's channel if required. LonWorks
routers impose some propagation delay in the transmission of a packet.
LonWorks routers can be configured to be one of the following:
Repeater: All packets are forwarded. Subnets can span permanent repeaters.
Bridge: All packets in a given domain are forwarded. Subnets can span permanent
bridges.
Learning router: Packets are routed only for a given domain. The router starts as a
bridge and reduces forwarding as it learns network topology. Learning routers are
vulnerable to failures if configured devices are incorrectly moved within the
topology.
Configured router: Packets are routed only for a given domain. Forwards packets
based on configured tables. This is the most reliable and efficient form of router.Each
side of a router can be addressed either by its Neuron ID or by its subnet/node
address. The side of the router that can communicate with the network management
tool is referred to as the near side and the other side is referred to as the far side.
master/slave
communications
The relationships of nodes that have a central control system manage their efforts.
message tag
Generally, nodes use network variables to communicate with one another—this
method is more efficient. In some instances, though, nodes use logical input and
output ports to send and receive explicit messages.
Nodes always contain a msg_in tag and may contain declared message tags as well.
Declared message tags are bi-directional (the node can both send and receive
messages with them). The msg_in message tag can only be used to receive messages.
network management
In the context of LonWorks control networks, network management refers to the
tools and services that support the process of discovering nodes, logically addressing
nodes, configuring them, and binding their network variables.
network variable
High-level objects that application devices use to communicate with one another. The
types, functions, and number of network variables in each node are determined by the
application code within the device. Network variables make it easy to develop
networked control applications by eliminating all of the low-level and tedious work
of building and sending down-link messages, and receiving and responding to
up-link messages.
Related terms include:
16
Niagara Release 2.3
About This Document
Commonly Used Terms
Network variable configuration table: A table that maps network variable indices
to network variable selectors and, for output network variables, to an address table
entry. For Neuron-based nodes, the table is stored in EEPROM on the Neuron chip.
For hosted nodes, the table is stored on the host.
Network variable index: A number used to identify a network variable. Network
variables indices are assigned by the Neuron-C compiler in the order in which they
are declared. The first network variable declared is index 0, the second index 1, and
so on. Neuron-based nodes can declare a maximum of 62 network variables (indices
0 to 61). Hosted nodes can support up to 4096 network variables (indices 0 to 4095).
Network variable selector: A 14-bit number used to identify connected network
variables. Network variable selectors are assigned during binding.
Network variable types: Network variable type defines the NV's structure and
contents. A network variable type can be either a SNVT or user-defined.
neuron chip
Neuron chip contains three 8-bit, in-line CPUs, on-board memory, eleven
general-purpose I/O pins, and a complete interoperable implementation of the
LonTalk protocol.
neuron ID
Unique 48-bit identification number set at time the chip is manufactured and cannot
be changed.
node (hosted)
A device in which layer 7 of the LonTalk protocol runs on a processor other than the
Neuron chip. The Neuron is used as a communications co-processor.
node (neuron based)
A node is a control device composed of a Neuron chip, a power supply, and a
communications transceiver. The Neuron chip alone does the vast majority of the
work performed by the node.
object
Within the context of Niagara, the term object refers to a node that resides at the
lowest level of the station database hierarchy, that is, a control object or app object.
Node is more generic term that applies to an “object” that resides at any database
level.In still wider terms, object refers to an object-programming software construct
that contains both code and data (information on which the code operates).
OSI
Open Systems Interconnection. See protocol stack.
peer-to-peer
communications
The ability of nodes to communicate directly with one another rather than have a
central control system manage those efforts.
polled network variable
An output network variable that never sends its value unless it is explicitly polled. An
alternative to binding network variables.
primitive
Primitive is a term that refers to subordination. In programming, primitives are the
basic operations supported by the language from which procedures are built.
Primitives can be low-level objects from which higher-level, more complex objects
Niagara Release 2.3
17
About This Document
Commonly Used Terms
are constructed (composites). Primitives can also refer to the properties that define
an object, but more importantly their component data types. In this case, primitives
are integers, floating-point values, Boolean values, or other data that constitute the
data store known as a property.
property
Each (Niagara) object/node contains a collection of properties, including
configuration properties and typically linkable properties (input properties and
output properties). Properties are categorized by type, each type has a specific
definition.
When using WorkPlace Pro, a Properties sheet is available for each object. The
Properties sheet shows the object's configuration properties, status properties, and
other properties. When linking two objects, a Link Properties dialog displays the
input and output properties available in each object. A link is possible between an
input property and output property if the variable types (data types or data species)
match.
protocol stack
Protocols define a common method for communications between computers. In
general, a network protocol defines how communication should begin, how
communication should end, and the sequence of events that occur in between.
Protocols are established by standards committees then implemented by hardware
and software manufacturers in their products.
At the transmitting computer, protocols break down data that is to be transmitted into
smaller segments called packets. These smaller segments can be transmitted much
quicker, resulting in significant response time improvements when large amounts of
data are to be transmitted. Protocols are also responsible for adding addressing
information and preparing the data for transmission through the network interface
card (NIC) and the transmission media (wire, fiber, etc.).
At the destination computer, protocols are responsible for collecting packets, striping
off formatting information, copying the data portions of the message to a memory
buffer, then reassembling the message in the proper order and checking it for errors.
The work of several protocols must be coordinated to prepare, transfer, receive, and
act upon data transmissions. This is referred to as layering. The OSI (Open Systems
Interconnection) Reference Model is one such combination of protocols where each
layer is responsible for handling a function or subsystem of the communication
process.
router
Refer to LonWorks router.
segment
A portion of a channel. A single channel can be comprised of multiple segments
connected by physical layer repeaters.
SNVT
Standard Network Variable Type. SNVTs facilitate interoperability by providing a
well-defined interface for communication between devices made by different
manufacturers.
18
Niagara Release 2.3
About This Document
Commonly Used Terms
station
The Niagara station is a JVM that hosts the running of nodes. It provides the
environment to configure, manage, and run a single database of nodes and the
services required to support a control application. Since the database is composed of
JavaBean-like objects, the JVM can easily run on multiple computing platforms.
subnet
A logical collection of up to 127 devices within a domain. Up to 255 subnets can be
defined within a single domain. All devices in a subnet must be on the same segment.
Subnets cannot cross non-permanent type routers.
tag
In WorkPlace Pro, tags are graphic elements that appear on object shapes to indicate
data that is (or can be) shared with another object-in other words, inputs and outputs.
By default, tags shown on an object represent only a subset of available input and
output properties. However, once you make a link to an input or output of an object,
the corresponding tag is always displayed.
transceiver
A device that is both a transmitter and a receiver—it can transmit and receive signals
on a communications medium.
unconfigured device
A device state where the device has an application image, but no network image. The
device must be configured before it can operate on the network.
workspace
Refers to the whole of the WorkPlace Pro window.
xif file
The text version of an external interface file, which documents a device's external
interface.
Niagara Release 2.3
19
About This Document
Commonly Used Terms
20
Niagara Release 2.3
CHAPTER
1
This chapter serves as an introduction to open systems. It has two main sections:
Parts of a Control System—Discusses the components of a classic HVAC
control system including hardware components, typical system architecture,
software components, and system configuration.
• Interconnectivity in Control Systems—Discusses interconnectivity in control
systems including gateways, host bridges, and third party integrations.
•
Parts of a Control System
Each component part of a control system plays a role. Hardware is used to measure
real-time values and cause control actions and software is utilized to manipulate
system hardware for the purpose of monitoring and controlling system functions.
This section discusses hardware components of a classic HVAC control system
including hardware, system architecture, software, and the specific role that each
component part of a control system plays in overall system functionality.
Hardware
The physical devices that are commonly found in an HVAC control system include:
•
•
•
•
•
Refer to
Sensors
Control Devices
Controllers
Networks
Operator Interface PC
For more information and an introduction to DDC control systems, refer to
www.energy.iastate.edu/ddc_online.
Niagara Release 2.3
1–1
Chapter 1
Sensors
Sensors are hardware devices that measure controlled medium or other control input.
Commonly, HVAC sensors measure temperature, pressure, relative humidity, flow,
etc. and generate a corresponding electrical signal in the form of voltage, current,
resistance, capacitance, and so on.
Control Devices
A control device is a device that responds to a signal from a controller, which changes
the condition of the controlled medium or the state of a controlled load. Control
devices include valves, dampers, electrical relays, fans, pumps, and more.
Controllers
Controllers read input values, apply logic of the control application programmed
therein, and generate output actions. The output function is often referred to as a
controlled response, which is typically one of the following:
Two-position (on/off control): A good example of two-position control is a home
heating system, where a thermostat measures space temperature and energizes
heating equipment when the temperature falls below a set value, then turns the
equipment off when the temperature rises above a set value.
Floating control: In floating control, the control response produces two digital
outputs based on the input variable. One output increases the signal to the controlled
device, perhaps driving an actuator open, the other decreases the signal, driving the
actuator closed. Often, there is a deadband region (in the middle) where neither
output is energized.
Proportional control: This type of control produces a variable output signal that is
proportional to the input variable. In a direct acting application, as the input variable
increases, the output signal increases. Similarly, as the input variable decreases, the
output signal decreases. In an effort to minimize error and maximize responsiveness
in modern control systems, controllers introduce two additional signals: integral,
which integrates error over time and derivative, which dampens the control response
to reduce overshoot.
In addition to their primary role of monitoring and controlling field hardware,
controllers often perform supervisory functions including a real-time clock for timed
operations, global control strategies, data collection and alarm archival, database
storage, and more. These devices are often referred to as area controllers.
Networks
Networks provide the means to glue devices together to form a system.
Communications between devices on a network can be either peer-to-peer or polled.
On a peer-to-peer network, devices freely communicate with one another. On a
polled network, individual controllers cannot pass data directly—they must pass data
to an interface device, which manages communications between devices on the
network.
The network is the medium that connects these devices and allows them to
communicate, share information, monitor and display control system data, and store
collected data for trend analysis.
1–2
Niagara Release 2.3
Chapter 1
Operator
Interface PC
This is where the user accesses system data for monitoring and control purposes.
Often referred to as HMIs (human-machine interface) or front ends, these are
typically PCs on which proprietary software is loaded, providing the following
functions.
View real-time control system data in both tabular format and dynamic
graphical interface.
• Exercise real-time control commands and adjust setpoint.
• Application data storage and retrieval including trended data, alarm histories,
and audit logs.
• Real-time database backup that supports the installation, configuration, and
maintenance of control system devices.
•
Software
The software installed on a user's PC, which is required to support installation and
operation of the control system, is often proprietary. Manufacturers over the years
have marketed software using three common designs. Older designs were based on a
line-programming structure similar to Basic where HVAC applications were actually
written and compiled much like computer programs. More graphical designs
followed. These included menu-driven templates to program common control
functions. But, today, object-oriented designs are providing pre-configured function
blocks with specific behavior that can be placed on the workspace and connected
visually. The process of connecting these objects produces graphical control
diagrams whose component parts can be customized on detailed configuration views.
Typically, control system software supports the following functions.
Network configuration: These functions are used to identify, install, and configure
component parts of the control system. In other words, these functions are used to
define system architecture.
Develop and edit control logic: Typically used with programmable controllers,
this software is used to develop control applications that can be downloaded into
programmable controllers.
Provide human-machine interface (HMI): Graphical user interface that provides
these functions: real-time data display (both text and graphic), trending and data
collection, alarming, remote communications (modem dial-up and Internet), and
more.
Architecture
System architecture is the term used to describe the overall network structure of a
control system. In many instances, a primary LAN, using a standard protocol such as
TCP/IP, provides connectivity for operator interfaces to remotely access control
system data. A router and/or area controller acts as a bridge between the primary
LAN and the fieldbus on which DDC controllers exist.
Niagara Release 2.3
1–3
Chapter 1
Figure 1-1
Typical system architecture.
Operator Station
Operator Station
Primary LAN
Router or
Area Controller
Router or
Area Controller
Operator Station
Operator Station
Controller
Controller
Controller
Controller
The PC: Although PC configuration specifications change almost daily, the HMI of
choice (desktop or technician's laptop) will most certainly run on the following:
Operating system: Operating system revision information and service pack
information. For instance, Microsoft Windows NT 4.0 with Service Pack 4 or higher,
Internet Explorer 5.0 or later, or Netscape Communicator 4.5 or later.
HMI: What is desired is a single GUI and engineering environment in which the user
can operate the system, edit control logic, support historical data collection and
reporting, as well as archival of trended data and alarms. The HMI should support
both local and remote connectivity.
Often, proprietary systems give way to multiple programming and/or user interface
tools.
Platform: PC de jour including a Pentium 4 CPU (2-GHz), some memory
requirement (512 to 1024-MB of RAM), X-gigabyte hard drive, display and adapter
capable of some resolution (1024 x 768 or higher), NIC (Ethernet adapter, LON
adapter, other), CD-ROM, other.
Communications Interface: Typically, the network interface card (NIC) provides
connectivity between the HMI and the primary (or secondary) LAN. The NIC
provides protocol translation (type and speed) and may include additional memory
for temporarily storing data.
Primary LAN: The horizontal line onto which workstations (HMIs) and area
controllers connect.
NIC: Resources connected to the primary LAN connect by way of their network
interface. This usually takes the form of a 10/100-Mbit Ethernet adapter.
1–4
Niagara Release 2.3
Chapter 1
Interconnectivity in Control Systems
TCP/IP: Transmission Control Protocol/Internet Protocol. More often than not, the
protocol used in support of the primary LAN is TCP/IP.
Fieldbus: This network is different from the primary LAN in that it typically
connects area controllers to field bus devices, where proprietary protocols are
involved. Due to the closed (proprietary) nature of many fieldbus communications
protocols, communications between different manufacturer's devices is difficult at
best and often not practical.
Controller: A direct digital controller (DDC) with a control application and an I/O
compliment that is capable of interfacing to a variety of sensors and control devices.
•
•
•
•
•
•
•
•
Sensor inputs
Controlled device outputs
Firmware
Database and control logic
Clock
Some capacity for storing trend data (that is, memory)
RS-232 connection that supports either local or remote connectivity
Proprietary port for connecting a service tool
As we venture into the realm of third party integrations from a completely proprietary
design, gateways have been used to link (or bridge) two different types of networks.
Gateways
In the most generic sense, gateways are a combination of hardware and software that
link two different types of networks. In control systems, gateways are often used to
connect systems from different manufacturers—they act as an interface between
proprietary control systems, allowing equipment using different proprietary
protocols, communication speeds, and/or data formatting to exchange data.
Closed-To-Closed Gateway
Figure 1-2 shows an architecture with a primary LAN, area controller, and
proprietary fieldbus devices connected to third party devices via a gateway.
Niagara Release 2.3
1–5
Chapter 1
Figure 1-2
Closed-to-closed gateway configuration.
Operator Station
Operator Station
Primary LAN
Router or
Area Controller
LAN (Closed Protocol)
Gateway
Proprietary
Communications Trunk
(Closed)
Controller
Controller
3rd Party Device
Closed-To-Open
Gateway
Figure 1-3 shows “back-to-back” gateways using an open protocol being used
between two closed architectures. This is also known as an open protocol bridge.
Figure 1-3
Closed-to-open gateway configuration.
Operator Station
Operator Station
Primary LAN
Router or
Area Controller
Open Protocol
Gateway
Gateway
Proprietary
(Closed)
Controller
Controller
3rd Party Device
1–6
Niagara Release 2.3
Chapter 1
Characteristics
of Gateways
Some of the characteristics associated with using gateways include:
•
•
•
•
•
Involve multiple vendors, which assumes cooperation between all parties
involved.
Often involves significant cost (for example, $5,000—$25,000) relating to
custom driver development, extensive engineering time for commissioning
and service, specialized training, and more.
Migration and revision control can be a hassle. If either side migrates to a new
revision, new interfaces are often required and each client needs to be
upgraded.
Service can be an issue. Each instance is a special case, documentation is often
limited, and there is a high learning curve.
Gateways often provide only a low level of data transfer and flexibility. Third
party devices are typically pre-configured with fixed logic and functionality.
Host Bridges
A host bridge combines the functions of a user interface with those of a gateway to
provide a high-end workstation that communicates with multiple vendors'
proprietary control system equipment. In this architecture, software drivers replace
separate gateways. The workstation is typically capable of displaying real-time data,
allowing control commands and setpoint changes, and handles alarms and error
messages, but detailed editing of control logic still requires knowledge and use of
underlying proprietary software.
Host Bridge
Architecture
Figure 1-4 shows an architecture of an HVAC control system interconnected to a fire
or CCTV system from a different manufacturer via a PC.
Figure 1-4
Host bridge architecture.
Operator Station
Primary LAN
Host Bridge (PC)
Router or
Area Controller
Proprietary
(Closed)
Controller
CCTV or
Fire System
Niagara Release 2.3
Controller
1–7
Chapter 1
Overlay
Systems
Figure 1-5 shows an architecture that looks like a single system, which is actually
integrating functionality from two different vendors.
Figure 1-5
Overlay system configuration.
Overlay System
with HMI that looks like
a single system
Operator Station (A)
Operator Station (B)
Vendor(A) LAN
Vendor(B) LAN
Router or
Area Controller
Router or
Area Controller
DDC System (A)
DDC System (B)
Controller
Controller
Controller
Controller
Examples include:
Unity from Electronic Systems USA (ESUSA)
• Wonderware
• Intellution
•
These PC-based integration platforms strive to provide a single graphical user
interface that functionally replace multiple front-end host systems from third party
manufacturers, designed to combine various legacy building automation
technologies with more open systems protocols available from many manufacturers
today.
Characteristics
of Host Bridges
1–8
Some of the characteristics associated with using host bridges include:
Often implemented on a proprietary system operator interface (PC) as an
additional software driver—the driver acts in place of a gateway.
• Some of the same cost and support issues exist—migration and revision
control, documentation, and training.
• Often requires proprietary programming tools to edit logic that exists below the
host bridge.
•
Niagara Release 2.3
Chapter 1
Openness in Control Systems
There are three classifications of protocols: closed, open, and standard. Historically,
designs have been protected by their manufacturer, which have resulted in very little
cooperation and far less interoperability. Recently, though, in the interest of
promoting vendor independence, the market has been pressuring vendors to pursue
designs that are more open. As a result, varying degrees of openness are emerging.
These range from designs that merely support coexistence on the same network to
designs that support full interchangeability.
Closed Protocol
Closed protocols are typically developed and used by a single vendor. The vendor
does not publish the protocol and keeps details of its design and use confidential.
Every controls manufacturer has created a proprietary communications design to
support their hardware platforms.
Open Protocol
Open protocols are public protocol definitions, published by the vendor in hopes that
they will gain widespread popularity. They are typically proprietary and they do not
necessarily ensure interoperability. An example of an open protocol is LonTalk.
Standard
Protocol
Standard protocols are defined, developed, and promoted by a standards organization
made up of representatives from multiple vendors. Although a standard protocol does
not necessarily create interoperability, from a user's standpoint, standards are
extremely important because they (theoretically) allow products from different
manufacturers to be combined to create a customized system. An example of a
standard protocol is the ASHRAE SSPC 135 BACnet standard.
Coexistence
Different devices that exist on the same media may coexist, use the same media, and
communicate using the same transceiver type and speed, but not actually
communicate with one another. Therefore, coexistence does not necessarily result in
interoperability.
It is also important to consider the impact that a vendor's gear will have on overall
network bandwidth. An example of coexistence can be found with devices from
different manufacturers sharing connections on a common Ethernet network, but not
necessarily sharing data. Figure 1-6 is an example diagram of two different DDC
systems that coexist.
Niagara Release 2.3
1–9
Chapter 1
Figure 1-6
Network diagram of coexistence.
Operator Station
Operator Station
Systems share a common LAN, but they do
not necessarily talk to one another.
Primary LAN
Router or
Area Controller
Router or
Area Controller
DDC System (A)
DDC System (B)
Controller
Operator Station (A)
Controller
Operator Station (B)
Controller
Interoperable
Devices
Controller
For devices to be interoperable, they must be able to exist on the same media, use a
common communications protocol, and share data using a common format.
Typically, this type of configuration consists of a network of interoperable devices
operating under a single GUI.
There are varying degrees of interoperability. At one level, device (A) is able to read
data from device (B) and at another level, device (A) is able to read data AND cause
an action in device (B).
Interchangeable
Devices
The highest degree of interoperability comes with interchangeable devices. A device
is interchangeable if the user has the option to change the device with a device from
a different vendor without changing the physical I/O instrumentation (use the same
field devices) and it has the ability to receive and transmit the same specified data.
Examples of interchangeable devices include telephones and printers. From an
end-user's perspective, you need to have the option to replace a device with one from
a different manufacturer without sacrificing functionality or creating work for
yourself.
Open System
Hierarchy
Figure 1-7 illustrates levels of openness in control system architectures. At the lowest
level (where the user can expect the least in terms of interoperability), you find only
open protocols. At this level, the architecture is built using communications protocols
that are published by their vendors in hopes that they gain widespread acceptance and
use. This level of openness tends to promote the open systems initiative, but does
little to ensure interoperability.
1–10
Niagara Release 2.3
Chapter 1
The next level of the open system hierarchy actually puts open protocols into use.
Communications transceivers, installed in complimentary devices manufactured by
different vendors, allow them to share a place on standard transmission media using
common communications characteristics. Beyond mere coexistence, the next level of
openness allows devices to actually share data. By adopting standard input and
output variables, devices from different vendors begin to interoperate.
Although there are varying degrees of interoperability (from devices that can simply
pass data between proprietary networks to flat architectures that allow a mixture of
devices from multiple vendors), true openness rejects the proprietary nature of most
designs. Finally, interchangeability offers the highest degree of openness. Here,
device designs are standard from their hardware definition and data formats to the
tools that are used to install and commission the networks on which they exist.
Figure 1-7
Open System Hierarchy.
Interchangeability
y
Ultimate in openness - allows the user to let price and
performance dictate choice.
y
Standard hardware deinitions
y
Standard input and output variables
Open System
(No proprietary devices - integrates devices from various vendords)
Data Sharing
(Uses standard input and output variables)
Transceivers
(Incorporates standard media and characteristics)
Protocol (i.e., LonTalk)
The Vendor's
View of Open
Systems
From the vendor's perspective, a move towards the production of hardware and
software products that support open systems carries major risk:
Products become commodities, which drives margins down.
• A move away from proprietary designs poses a threat to incremental work.
• Customers have the ability to move more easily to alternative vendors.
•
A good halfway position is to move towards using open or standard protocols within
a closed system environment. In other words, market your products as being open,
but employ proprietary network configurations, thick clients, and specialty
programming tools. This increases the potential for incremental work and restricts
customer mobility.
Niagara Release 2.3
1–11
Chapter 1
The Customer's
View of Open
Systems
From the customer's perspective, a move towards openness allows them to utilize a
systems integrator to install control systems composed of devices selected solely on
price and function.
•
•
•
•
•
1–12
All incremental work should be best of breed.
Changing SIs should be possible at minimal cost.
Long-term relationships with SIs are based on consistent value delivered
project to project.
Service after the installation is the basis for continuing those relationships.
New opportunities beyond the offerings of a single vendor for new products
and diverse sub-systems.
Niagara Release 2.3
CHAPTER
2
LonWorks Overview
This chapter introduces the LonWorks technology, the company that created it
(Echelon), and the LonMark Association, which is devoted to developing standards
for interoperability in control system networks.
The following main sections are included:
LonWorks
• Echelon Corporation
• Applications and Distribution Channels
• LonMark
•
LonWorks
LonWorks is the name given to the collective technology developed by the Echelon
Corporation for implementing control system networks. The root term, LON, is an
acronym for local operating network, which refers to an intelligent control network
that facilitates communications between devices or nodes that communicate with one
another over a variety of transmission media using a common, message-based control
protocol. Echelon's design endeavors to provide an off-the-shelf method for
manufacturers to build devices that can coexist and operate as peers on a flat,
interoperable control network.
Components often found in a LonWorks control network include:
Local Control Nodes: These are network devices that monitor and control the
operation of attached sensors and/or actuators based on local and remote stimuli.
Supervisory Nodes: These are network devices that collect and pass data from one
or more local control nodes. Supervisory nodes may also coordinate the operation of
one or more local control nodes.
Network Management Tools: These are the software tools and services that are
used to logically address nodes, configure them, and bind their network variables.
Network management tools are also used to monitor nodes, diagnose
communications errors, and effect repair or replacement of devices on a control
network.
Niagara Release 2.3
2–1
Chapter 2
LonWorks Overview
Echelon Corporation
Routers: Routers provide transparent connectivity between two LonWorks network
channels.
The overall LonWorks design approach is to:
Define the nodes required in the system.
• Define the relationships between the nodes.
• Develop the application-specific programming for each node, which defines its
behavior.
•
With the proper design, the nodes become generic, re-usable building blocks that can
be applied in various ways to perform virtually any task, in many different
configurations, using a variety of transmission media. The overall application
performed by a group of nodes is determined by how each individual node has been
configured and the relationships that have been established between it and other
nodes. But, because the hardware design, software design, and network design are all
independent, the behavior of a node can be defined without concern about the
specifics of the network topology in which they are used.
LonWorks has quickly evolved to become the defacto standard for interoperability in
control networks including the building automation market, industrial automation,
power/utility automation, and transportation industries. Among others, LonWorks is
included in the ANSI-approved BACnet building automation control standard and
has been adopted for use in building automation systems worldwide in HVAC
systems, lighting systems, alarm and security devices, power metering, load
management, and more.
Echelon Corporation
Echelon Corporation, based in Palo Alto, California, was founded in 1988 by the
co-founders of Apple Computer and ROLM Corporation (A.C. Markkula and M.
Kenneth Oshman, respectively). They report over 3,500 users for their 80-plus
products and, as of March 1999, the company had received 71 United States patents,
with 18 additional applications pending for technologies relating to their initial
design. The company employs approximately 166 employees based primarily in the
Untied States, with a lesser presence in Japan, the Netherlands, and the United
Kingdom.
Echelon develops and markets hardware components and software development
tools targeted at original equipment manufacturers (OEM) and systems integrators
(SI) to design and implement open, interoperable, distributed control networks based
on the LonWorks design.
2–2
Niagara Release 2.3
Chapter 2
LonWorks Overview
Applications and Distribution Channels
Applications and Distribution Channels
Fundamental to the LonWorks design is its support of multi-vendor control products
communicating across different types of transmission media in a single system. As a
result, LonWorks provides a highly functional control networking scheme to meet the
special needs of a widely diverse collection of application purposes including
building and industrial automation, transportation, home/utility automation, and
more. Using standardized data types, devices designed for different application
purposes by a variety of manufacturers can share information and also be monitored
from a common PC interface, allowing interoperability and integration.
For example, in an office building containing a LonWorks network the subsystems
will work together as one system providing integration of HVAC, Lighting, Security,
and Access Control.
Imagine a tenant of the building needs to work after hours or on a weekend. They
walk up to the front door and present their access card; the reader verifies their
credentials and opens the door. The security system disarms the interior motion
sensors and allows perimeter access for a short delay period. Behind the scenes the
lighting controls system is notified not only of occupancy but specifically who has
entered the building, it then lights the common area hallways and eventually the
actual office for the tenant. Meanwhile the HVAC system has restored the personal
temperature settings for the tenants VAV box to occupied mode. The corresponding
central station air handler and mechanical systems are also called into operation.
After the tenant has completed their work task the process reverses itself as they leave
the building!
In support of a broad range of industries and markets, Echelon seeks to develop
strategic partnerships with industry-leading OEMs and work closely with them
during their product design process. Echelon believes this strategy will continue to
accelerate the transition of highly focused and targeted industries towards a more
open, interoperable mindset. As a complement to its OEM distribution channel,
Echelon recruits independent systems integrators as an additional channel to
implement highly functional and distributed control networks for end users, which
demand more and more the flexibility of choice offered by interoperable,
multi-vendor control solutions.
LonMark
If a device is designed to use the LonWorks technology, depending on the
implementation, it may or may not interoperate with other LonWorks devices.
Simply using the LonWorks technology does not guarantee interoperability.
The LonMark certification is granted through the LonMark Association, which is a
large, relatively independent organization of manufacturers, suppliers, and end users
from around the world. The organization develops technical product specifications
and guidelines that promote interoperability among participating equipment
manufacturers. Participation of this nature promotes interconnection and
Niagara Release 2.3
2–3
Chapter 2
LonWorks Overview
LonMark
intercommunication with other products. LonMark refers to the mark signifying that
a product has met LonMark guidelines that allow it to interoperate with other
LonMark devices on a LON.
2–4
Niagara Release 2.3
CHAPTER
3
Echelon began developing the LonWorks technology in 1988 with the goal to
develop a universally accepted standard for control networks. As such, LonWorks
would become the standard platform on which control system devices could
communicate on a peer-to-peer fashion to monitor sensors, control actuators, and
provide complete access to control system data.
In many ways, LonWorks control networks resemble typical local area networks.
Using your knowledge of standard network design and communications
methodologies, this chapter looks to introduce the LonTalk protocol and relate that
technology to the design and support of distributed control systems.
This chapter includes the following main sections:
LANs and LONs
• LonTalk Protocol
• Smart Devices
• Network Architecture
•
LANs and LONs
Communications networks are for sharing data. A network of computers that serves
users within a limited geographical area is referred to as a local area network
(LAN). In a networking scheme, where peer-to-peer communications is used, each
computer on the LAN has equal responsibility for initiating, maintaining, and
terminating a session. The structure of the LonWorks communications protocol is
similar to a LAN in that computers or nodes on a common network share data
continually using peer-to-peer communications. But, because LonWorks devices
operate according to a special set of rules or protocol (different from what is typical
for LANs), the network has been termed a local operating network (LON).
The primary distinction between LANs and LONs is their purpose. Traditionally,
LANs are designed to move large amounts of data from one computer to another over
a network connection. The performance of a LAN is viewed in terms of throughput,
which is the amount of data transferred from one location to another, and it is often
measured in megabits per second (Mbps). A LON, on the other hand, is designed to
transmit sensing and control messages, which are typically very short and relate
Niagara Release 2.3
3–1
Chapter 3
LonTalk Protocol
specifically to monitoring real-time status and triggering a control action. Therefore,
LON performance is not measured in terms of throughput, but in terms of completed
transactions per second and response time. For a LON, the critical performance factor
is assuring that relatively small messages are rapidly delivered from one location to
another. A real-time control system does not necessarily need to handle vast amounts
of data, but it does require timeliness, dependability, and accuracy.
LonTalk Protocol
A LON, which is a control system field bus, allows intelligent devices, such as
actuators and sensors, to share data directly, using a standard protocol. The protocol,
known as LonTalk, is Echelon's open-architecture communications protocol used by
all LonWorks-based devices. It allows intelligence and communication capabilities
to be embedded into individual control devices that can be connected together
through a variety of transmission media including twisted pair data cable, existing
power lines, radio frequency (RF), coax, fiber, and others.
The core of this embedded intelligence is a mixture of hardware and firmware on a
device known as a Neuron chip, which is an integrated circuit manufactured under
license by Cypress, Motorola, and Toshiba. Almost 10 million Neuron chips have
been shipped since 1992 on devices from Echelon and roughly 4,000 other
manufacturers worldwide.
The Neuron chip implements the LonTalk protocol and performs a variety of local
sensing and control functions. In addition, each node includes a physical interface or
transceiver that couples the node to its transmission medium. A typical node in a
LonWorks control network performs a simple task, such as measuring a temperature,
monitoring equipment status, or controlling a motor. When combined together with
complementing nodes, the overall network can perform rather complex control
applications, such as running a manufacturing line or automating a building.
Smart Devices
A LonWorks control network enables a group of electrical devices, or nodes, to be
connected together to implement sensing, monitoring, control, and communications
capabilities for a variety of applications. Each node contains a Neuron chip, a power
supply, and a communications transceiver. The communications transceiver couples
the Neuron chip to the transmission medium and the Neuron contains the firmware
and software required for sending, receiving, and acting upon a variety of control
signals.
In addition to these components, each node has a physical ID, a timer, a computation
unit, device controllers, I/O ports, and communications and control software. In
effect, each node is a rather sophisticated computer, which is why they are often
referred to as intelligent or smart devices.
3–2
Niagara Release 2.3
Chapter 3
Network Architecture
The network architecture of a LON can be best understood by examining three
different models of a distributed control system. These include:
A centralized control system.
• A fully distributed (flat) control system.
• A semi-distributed control system.
•
Centralized Control System
A centralized control system uses a single supervisory processor that directly and
individually connects to low-cost, non-intelligent I/O devices. In this model of a
centralized control system, the supervisor hosts all system operations. It creates a
Master / Slave relationship between the Supervisors and the non-intelligent I/O
devices.
Figure 3-1
Centralized architecture (non-distributed).
Server
LAN
Workstation
Niagara Release 2.3
3–3
Chapter 3
Fully Distributed (Flat) Control System
A fully distributed control system is the opposite of a centralized system. This flat
architecture is Echelon's vision of control system network architecture. In this model,
intelligence is distributed to each device on the network—to every switch, each
sensor, and to every controlled device. In a fully distributed control system, every
field device contains a Neuron, a communications transceiver, and the other firmware
and software required of a LonWorks node.
Each node exchanges data on the LON with its peers and the tasks it performs are
defined individually in that node. Peer-to-peer communications is the ability of nodes
to communicate directly with one another rather than have a central control system
manage those efforts.
Figure 3-2
Distributed control system architecture.
Workstation
LAN
Router
Router
Workstation
3–4
Niagara Release 2.3
Chapter 3
Semi-Distributed Control System
In between the centralized and fully distributed control systems is the
semi-distributed control system (Figure 3-3). Many control system manufacturers
have chosen this model as the best combination of economy and usability in
delivering LonWorks-based control.
Figure 3-3
Semi-distributed control system architecture.
Workstation
LAN
Area Controller
Area Controller
Workstation
In this model, application-specific controllers use their own processing power to
provide interoperability combined with onboard I/O to interface with low-cost
sensors and actuators that do not contain a Neuron. Managing collections of the
application specific controller are area controllers, they provide global control
strategies and over all coordination of the system. This architecture allows for the
best of both worlds by supporting the peer-to-peer communication at the application
specific level while maintain control of the big picture at the area controller level.
Niagara Release 2.3
3–5
Chapter 3
3–6
Niagara Release 2.3
CHAPTER
4
This chapter discusses the design of the Neuron chip, which is the communications
and control processor on which manufacturers develop interoperable LonWorks
nodes and thereby implement interoperable control networks.
Also covered are communications transceivers, routers and repeaters, network
topology, and means by which users can interface to LonWorks networks.
The following main sections are included:
•
•
•
•
•
Elements Overview
The Neuron Chip
Hosted Nodes
Transceivers, Media, and Network Topology
LonWorks Network Interface
Elements Overview
The LonWorks technology includes all of the elements required to design, develop,
and deploy control system networks. These include:
The Neuron Chip.
• LonTalk protocol.
• LonWorks communications transceivers and network interface.
• Network management tools.
•
In addition to the Neuron chip, LonWorks devices require a transport system that they
can use for communications. As part of the LonWorks technology, Echelon has
defined and provides much of the infrastructure needed to implement these networks.
Niagara Release 2.3
4–1
Chapter 4
The Neuron Chip
The Neuron Chip
The central component of an Echelon node is the Neuron chip. Each Neuron chip
contains three 8-bit, in-line CPUs, on-board memory, eleven general-purpose I/O
pins, and a complete interoperable implementation of the LonTalk protocol. In fact,
on Neuron-based nodes, the Neuron chip alone does the vast majority of the work
performed by the node. Except for the power supply, I/O devices, and some of the
transceiver functions, all work performed by the node is done by the Neuron chip.
Figure 4-1
Neuron chip functions.
LonTalk
Network
Transceiver
Comm
Port
Optional Ext
Memory (3150)
I/O Devices
(sensors, actuators)
I/O
Conditioning
Protocol Firmware
(Layers 3-6)
Media Access
CPU
RAM / ROM /
EPROM
Network
CPU
RAM / ROM / EPROM
I/O Resources
(i.e., counters, drivers, etc.)
Xtal
Power
Regulator
Protocol Firmware
(Layers 1-2)
Neuron Chip
Application
CPU
RAM / ROM / EPROM
Node-Specific
Program
ID# 010031EFEA00
As shown in Figure 4-1, the Neuron chip performs several different duties at once. It
is a processor, a device controller, a memory chip, and it has built-in EEPROM that
contains network configuration and addressing information, a unique permanently
programmed 48-bit serial number, and optional user-written application code.
There are two models of the Neuron chip available from Echelon: the 3120 and the
3150. Both models provide three processors (two dedicated to communications and
another dedicated to applications processing), I/O device controllers that support
connection to applications hardware, timing and counting hardware, and a
transceiver interface. Both chips include on-board memory. The 3120 includes RAM
(1K) and ROM (10K), where the 3150 includes 2K of RAM (no ROM) and an
external memory interface for more complex applications processing.
Neuron Chip Data Structures
Figure 4-2 depicts the various data structures that may be stored in on-chip
EEPROM, off-chip EEPROM, flash, or NVRAM.
4–2
Niagara Release 2.3
Chapter 4
The Neuron Chip
Figure 4-2
Neuron chip data structures.
Neuron FIXED STRUCTURE
This node's 48-bit ID and Program
ID
DOMAIN TABLE
This node's domain ID,
authenticationkey, subnet ID, and
node ID
ADDRESS TABLE
Message destination subnet/nodes
or groups used for implicit
addressing
NETWORK VARIABLE FIXED TABLE
NETWORK VARIABLE CONFIGURATION TABLE
Points to NVs data in RAM or
EEPROM
Points to NV selector number and
address table
SELF-DOCUMENTATION
CONFIGURATION STRUCTURE
Contains transceiver parameters
Processing Units
The three processors contained on the Neuron chip include the Media Access Control
(MAC) processor, the Network Processor, and the Application Processor.
The MAC processor drives the communications subsystem. It communicates
with the Network Processor using network buffers located in shared memory.
• The Network Processor handles network variable processing, addressing,
authentication, network management, and more. It communicates with the
MAC processor using network variables and with the Application Processor
using application buffers.
• The Application Processor executes user-written code together with operating
system services called by that code. Applications code is primarily written in
Neuron-C, which is a derivative of the ANSI C language optimized for
LonWorks-based distributed control applications. Depending on the device, its
application may be fixed by the manufacturer at production or be downloaded
from a PC after the fact.
•
Network Image
A node's network image describes how the node appears to all other nodes on the
network. It contains the address assignments of the LonWorks node, binding
information connecting network variables and message tags between nodes on the
network, parameters of the LonTalk protocol that may be set at installation time, and
configuration variables of the application program.
Niagara Release 2.3
4–3
Chapter 4
The Neuron Chip
Portions of a node's network image can be set by the manufacturer at production and
others are downloaded over the network by a network management tool into
EEPROM when the node is installed.
Network images contain the following data: Neuron ID, Mfg Data, Node Type, Node
Address, Address Table, Location ID, NV Configuration Table, NV Fixed Table,
Comm Data, Mode Table, and SI-SNVT/SD.
Neuron ID: This is set at the time the chip is manufactured and it cannot be changed.
It is a 48-bit identification number that is unique to the node. Some manufacturers
label their devices with a bar code label that contains the Neuron ID.
Devices can be queried for their Neuron ID (using a network management tool) or a
technician can use a barcode reader to scan the ID from its label. Network
management tools use a domain/Neuron ID addressing format at installation time to
assign each node to one or two domains and to assign a subnet and node address.
Mfg Data: This is set at the time the chip is manufactured and it cannot be changed.
It identifies the model number of the device (for example, Motorola 3120).
Node Type: This is set at application compile time. In LonMark devices, it contains
the manufacturer's ID, the node type and sub-type, etc. In non-certified nodes, it
contains the Neuron-C program name.
Node Address: One or two structures, each containing a domain, an authentication
key, a node number, and a subnet number. There are two node addresses if the node
has been assigned to two domains.
Address Table: The address table is used to send and receive messages.
Location ID: This can be set at the time the device is installed and it is intended to
correspond to a physical location represented on a floor plan. Location ID contains a
channel number and location string.
NV Configuration Table: This table contains an entry for each network variable
including priority bit, direction (input or output), network variable ID (assigned by
the binding device), protocol service to use, authentication bit, and address table
index.
NV Fixed Table: This table contains an entry for each network variable describing
the compile-time attributes of the NV including SI-SNVT/SD data index, network
variable length, and network variable address.
Comm Data: The number of priority slots on this channel, this node's priority slot,
bit rate, and transceiver parameters.
Mode Table: This is a table of node configuration properties including the number
of domains, address table entries, application buffers, network buffers, receive
transaction structures, and network variables.
SI-SNVT/SD: Self-Identifying Standard Network Variable Type /
Self-Documentation. This information includes SNVT index, if standard network
variable types are used, and optional self-documentation for the node.
4–4
Niagara Release 2.3
Chapter 4
The Neuron Chip
Domain Table
The domain table contains an entry for every domain to which a node belongs. For
more information, refer to “Logical Addressing,” page 5-4.
Address Table
The address table defines the network addresses to which a node can send messages
and network variables. It also defines the group(s) to which the node belongs. For
each address table entry, the first byte contains the type of address table entry
including group, subnet/node, broadcast, turn-around, or not in use.
Group addressing is used for multi-casting, when a network variable or
message tag is used in a connection that has more than two members. A group
entry has entries for the group size (the number of acknowledgements to
expect), which domain to use, what group number the node belongs to (so other
nodes understand who is sending an acknowledgement), a transmit timer, a
repeat timer, a retry count, a receive timer, and a group ID.
• A subnet/node address is used when a message is to be sent to only one other
node. A subnet/node entry has entries for domain, destination node number,
destination subnet number, a repeat timer, a retry count, and a receiver timer.
• Broadcast addressing is not typically used, but it is supported by the protocol
to allow explicit messaging. A broadcast entry has entries for the domain and
destination subnet (zero implies all subnets), a repeat timer, a retry count, and
a receive timer.
A turnaround address is used for network variables that are bound to other network
variables in the same node.
•
Network Variable Tables
Network variables have three associated tables: the network variable configuration
table, the network variable alias table, and the network variable fixed table.
Network Variable Configuration Table: Defines the configurable attributes of the
network variables in the node. The table is located in EEPROM so that it can be
modified and it becomes part of the network image written to the node during
installation.
Network Variable Alias Table: Defines the configuration attributes of the alias
network variables in the node. This table is also located in EEPROM, immediately
following the network variable configuration table.
Network Variable Fixed Table : Defines the compile-time attributes of the network
variables in the node. The table may be located in ROM and it is part of the
application image written at the time the device is downloaded.
Niagara Release 2.3
4–5
Chapter 4
Hosted Nodes
Hosted Nodes
In addition to Neuron-based nodes, where the application layer (OSI layer seven)
runs in the Neuron chip, control devices can also use a separate dedicated
microprocessor to run the layer seven application. Nodes that off-load the application
layer to a separate host processor are referred to as hosted nodes.
Hosted nodes merely use the Neuron chip as a communications co-processor. For
hosted nodes, additional firmware is loaded into the Neuron to provide
communications interface between the host and the LonWorks network.
Three different communications interface modules are available:
Microprocessor Interface Program (MIP): This module supports custom network
interfaces.
The Network Services Server (NSS) engine: This module is used in the LNS
architecture to process network services, maintain the network database, and enable
and coordinate multiple points of (PC) access. It is the NSS engine that allows the
LNS Server to support multiple client workstations that log into the server to access
the shared LNS database. The NSS engine is installed on only one local server
workstation for the LonWorks network.
Network Services Interface (NSI): This module is used in the LNS architecture to
provide connectivity to the LonWorks network from multiple clients. NSI manages
transactions with the NSS engine, locally or remotely. It is NSI that runs in the
PCC-10 interface card installed in a laptop.
In addition to the Neuron chip, LonWorks devices require one of several transceiver
modules for communications. These devices are manufactured by Echelon and they
provide connectivity for virtually every transmission media including twisted pair,
power line, RF, infrared, coaxial cable, and fiber.
Probably the most versatile and popular transceiver is the FTT-10 Free Topology
transceiver, which supports twisted pair, unshielded, polarity-insensitive,
peer-to-peer communications at 78 Kbps. Examples of FTT-10 network topologies
are illustrated in Figure 4-3 and Figure 4-4.
4–6
Niagara Release 2.3
Chapter 4
Figure 4-3
Free topology networks.
Node
Termination
Module
A network segment in a free topology network is any part of the network in which
each conductor is electrically continuous. Each of the four diagrams above is a
segment. Some application may require two or more segments. If necessary,
segments can be joined with physical layer repeaters.
FTT-10 Topology
As illustrated in Figure 4-3 and Figure 4-4, there are two broad categories of wiring
topologies supported by FTT-10: the Free Topology approach and the Doubly
Terminated approach.
The Free Topology approach allows any number of tees, stars, loops, or bus
combinations in a wiring segment.
• The Doubly Terminated approach, although it supports greater wiring lengths,
is significantly more restrictive in terms of wiring topology. For more
information, see “Doubly-Terminated Bus Topology,” page 4-9.
•
Niagara Release 2.3
4–7
Chapter 4
Wiring Segment: The combined lengths of cable connecting the various devices on
the LonWorks network in a Free Topology approach is limited to 500 meters and
requires a single termination module installed anywhere on the segment.
In a Doubly Terminated approach, all twisted pair wiring is done in a linear bus or
daisy-chain fashion that does not support wiring tees of any sort. Each physical end
of the segment must be terminated using a termination module and the maximum bus
length is 2700 meters.
Refer to
Refer to the LonWorks FTT-10A Free Topology Transceiver User's Guide
(078-0156-01F) for specific details on cabling and connections. This document can
be downloaded from Echelon's web site.
A single wiring segment supports up to 64 nodes (FTT-10 transceivers), but a channel
can span multiple segments that employ physical layer repeaters to expand both the
number of nodes and the length of the control network. Depending on the application
and expected network performance (in terms of response time), the maximum
number of nodes supported by a LonWorks network is 32,385.
Both the JACE-NP and JACE-5 have a LonWorks port using an FTT-10 transceiver.
The FTT-10 transceiver allows for free topology network wiring schemes using
unshielded, twisted pair cable and polarity insensitive terminations at each node. This
combination of features greatly simplifies installation and reduces network
commissioning problems. It also allows nodes to be added in the future with little
regard for existing cable routing. The communications rate on an FTT-10 network is
78 Kbps.
Free Topology
Restrictions
4–8
Although free topology wiring is very flexible, there are a few restrictions including:
The maximum number of nodes per segment is 64.
• The maximum node-to-node distance is 1640 feet (500m) when using Belden
85102 cable or 1312 feet (400m) when using Belden 8471. The longest cable
path between any possible pair of nodes on a segment must not exceed the
maximum node-to-node distance. If two or more paths exist between a pair of
nodes (that is, a loop), the longest path should be considered. Note that in a bus
topology, the longest node-to-node distance is equal to the total cable length.
• The maximum total cable length is 1640 feet (500m) unless you use TIA
Category 5 cable, in which case total wire length cannot exceed 1476 feet
(450m). The total length of all cable in a segment must not exceed the
maximum cable length.
• One 52.3 ohm (0.25W, 1%) termination resistor is required in each segment. If
you install a repeater and another segment, you need to install a termination
resistor in that segment. The termination resistor can be located anywhere in
the segment.
•
Niagara Release 2.3
Chapter 4
Doubly-Terminated Bus Topology
You can extend the maximum total cable length (of a free topology network) without
using a repeater by using a doubly-terminated bus topology. The trade-offs are
1.
This topology must be rigorously adhered to during installation and for all
future retrofits, and
2.
Two termination resistors are required (at the ends of the bus).
Figure 4-4
Doubly-terminated bus topology network.
Termination
Module
Termination
Module
The restrictions on a doubly-terminated bus topology include:
The maximum number of nodes per segment is 64.
• The maximum total bus length depends on the wire size.
•
Wire size
Maximum cable length
24 AWG
2951 feet (900m)
22 AWG
4590 feet (1400m)
16 AWG
8853 feet (2700m)
The maximum stub length is 9.8 feet (3m). A stub is a piece of cable that is
wired between the node and the bus—if the bus is wired directly to the node,
there is no stub. If you are wiring to a field terminal strip, be sure to account
for any factory wiring between the terminal strip and the device.
• Two 105 ohm (0.25W, 1%) termination resistors are required in each segment.
One resistor must be located at each end of the bus.
•
Cable
Specifications
The following specifications are derived from the latest information available from
Echelon. Consult the Junction Box and Wiring Guideline for Twisted Pair LonWorks
Networks (005-0023-01) for more detailed information.
Echelon has qualified five cable types for the TP/FT-10 channel for use with the Free
Topology Transceiver. These include:
Cable type
AWG
Diameter
TIA 568A Category 5
24
0.5mm
Belden 8471 (PVC jacket)
16
1.3mm
Belden 85102 (Tefzel jacket)
16
0.65mm
Level IV
22
0.65mm
20.4
0.8mm
JY (st) 2x2x0.8
Niagara Release 2.3
4–9
Chapter 4
TIA 568A Category 5: For TP/FT-10 channels in a bus topology, the maximum bus
length is 2951 feet (900m), with a maximum stub length of 9.8 feet (3m).
For TP/FT-10 channels in a free topology, the maximum node-to-node distance is 820
feet (250m) and 1476 feet (450m) maximum total wire length.
Belden 8471: For TP/FT-10 channels in a bus topology, the maximum bus length is
8853 feet (2700m), with a maximum stub length of 9.8 feet (3m).
For TP/FT-10 channels in a free topology, the maximum node-to-node distance is
1312 feet (400m) and 1640 feet (500m) maximum total wire length.
Belden 85102: For TP/FT-10 channels in a bus topology, the maximum bus length
is 2948 feet (900m), with a maximum stub length of 9.8 feet (3m).
For TP/FT-10 channels in a free topology, the maximum node-to-node distance is
1640 feet (500m) and 1640 feet (500m) maximum total wire length.
Level IV: The Level 4 cable specification used by Echelon is as originally defined by
NEMA and differs from the Category 4 specification proposed by EIA/TIA.
For TP/FT-10 channels in a bus topology, the maximum bus length is 4590 feet
(1400m), with a maximum stub length of 9.8 feet (3m).
• For TP/FT-10 channels in a free topology, the maximum node-to-node distance
is 1312 feet (400m) and 1640 feet (500m) maximum total wire length.
•
JY (st) 2x2x0.8: JY (st) cable is available only in Europe and can be used only with
the TP/FT-10 channel.
For TP/FT-10 channels in a bus topology, the maximum bus length is 2948 feet
(900m), with a maximum stub length of 9.8 feet (3m).
• For TP/FT-10 channels in a free topology, the maximum node-to-node distance
is 1050 feet (320m) and 1640 feet (500m) maximum total wire length.
•
Channels
The term channel is an Echelon term used to describe the physical medium to which
a node is attached and the transceiver type it uses to communicate. Although the
LonTalk protocol supports networks with segments using different media (channels),
all devices on a given channel must communicate using the same type of transceiver.
Every LonWorks node is physically connected to a channel. The physical form of a
channel depends on the medium: a twisted pair channel is a twisted pair wire; an RF
channel is a specific radio frequency; a power line channel is a continuous section of
AC power wiring, and so on. Multiple channel types are connected by routers.
4–10
Niagara Release 2.3
Chapter 4
Routers
Routers are used to manage network message traffic, extend the physical size of a
channel (both in terms of length and the number of devices attached), and to connect
channels that use different media (transceiver types). Routers attach to two channels
and route packets between them. They can be configured using one of four routing
algorithms that employ varying degrees of intelligence.
The first routing algorithm defines the device as a simple, physical layer repeater,
which has no intelligence and merely forwards every packet it receives—even
damaged packets. The second method, known as a bridge, forwards only packets for
a given domain.
Next, a learning router starts as a bridge, then reduces forwarding as it learns network
topology. The difficulty with learning routers, though, is that they may incorrectly
route packets if configured devices are incorrectly moved within the topology.
However, this vulnerability can be overcome by using a configured router, which
routes packets based on known destinations deciphered from configuration data
stored in the device.
Note
The most common use a router when applied with the Niagara Framework is to join
two channels of different media types, for example: wire to fiber.
A repeater forwards all packets received on one channel onto the other channel.
A bridge forwards all valid packets received on one channel to the other channel if
the packet is sent on a domain to which the bridge belongs. In a single domain
network, a bridge functions much like a repeater.
A configured router determines which packets to forward based on internal routing
tables—if no members of a group are on the far side of the router, a message
addressed to that group is not forwarded. This type of router is often recommended
since it optimizes network traffic. Configured routers have their routing tables stored
in non-volatile memory and thus are retained after a reset.
A learning router, like a configured router, determines which packets to forward
based on internal routing tables. Learning routers have their routing tables in volatile
memory, so that after reset the router must relearn its network topology.
Routers versus Repeaters
Physical layer repeaters are low-cost devices that join two segments of wire and
operate as if it were the same CSMA channel. The device filters out a certain level of
electrical noise, but it does not do any selective routing. Additionally, repeaters
introduce propagation delay, which can adversely affect bandwidth performance. As
a result, the number of repeaters on a LonWorks network must be restricted.
Routers consist of a pair of Neurons and transceivers each watching a separate
(independent) channel. Each packet of data is received by the router and only
re-transmitted to the alternate channel if the router determines the target address of
Niagara Release 2.3
4–11
Chapter 4
the message requires that operation. Although routers introduce a 2.5 millisecond
delay in forwarding a message, the overall effect (on bandwidth) is negligible since
the router only transmits what needs to go across the junction. Where the use of
repeaters must be limited, you can use as many routers as you need to support
multiple segments and media types.
How Learning Routers Work
Learning routers are used to selectively route packets between two channels. Initially,
learning routers set their internal routing tables to indicate that all subnets exist on
either side of the router, but as messages are passed, they learn (and record) on which
side of the router subnets actually exist. Within a very short period of time the router
knows whether to pass messages or simply ignore them.
Figure 4-5
Learning Routers.
Channel
1
2
3
R1
R
Channel
Subnet 1
R2
R
4
Channel
7
5
6
Subnet 2
8
9
Learning
Router
Subnet 3
Referring to Figure 4-5 above, suppose that node 2, which is assigned to subnet 1,
generates a message bound for node 3, which is assigned to the same subnet. Initially,
router one (R1) examines the message and finds that subnet 1 lies above it, notes that
in its routing table, and forwards the message onto the downstream channel. When
node 3 sends its acknowledgement, R1 picks up that message, finds that node 3 is on
the same subnet (above it), and records that information in its routing table. But, since
the source and destination subnets are the same, the router does not pass the
acknowledgement onto the downstream channel.
In a subsequent transmission, node 3 generates a message bound for node 6, which
is assigned to subnet 2. R1 now knows that node 3 is on a subnet above it, but it does
not know to which subnet node 6 is assigned. R1 passes the message onto the
downstream channel. When node 6 responds, R1 inspects the acknowledgement and
finds that the source and destination subnets are different. The router notes that
subnet 2 lies below it and passes the acknowledgement onto the upstream channel.
4–12
Niagara Release 2.3
Chapter 4
Learning Routers versus Configured Routers
When choosing between a learning router and a configured router, take into account
the following:
The initial flood of traffic that occurs while a learning router is learning the
network may cause congestion problems.
• Network topology may include loops that prevent a learning router from
accurately learning the network. This is particularly common in power line and
RF networks.
• A learning router is always learning. It will update its internal routing table for
changes it finds in network topology.
• Learning routers do not learn about groups, but configured routers can be
configured to selectively forward group addressed packets.
•
Standard network interfaces are available to support direct and remote connection
between a workstation running LonWorks-aware software and the LonWorks
network. The workstation connects to the LonWorks network (as a node) using an
Echelon LonTalk adapter, also known as an NSI (Network Services Interface), which
is available in a variety of form factors depending on the channel type used, the
architecture of the PC bus, and the functions that are to be performed by the PC.
Regardless of physical characteristics of the installation, the workstation requires
LonWorks API software and drivers to interface to LonWorks nodes.
LonTalk adapters are available in the following form factors:
PCC-10: A type II PC (formerly PCMCIA) card that includes an integral FTT-10
transceiver, although other transceiver types can be connected using external
transceiver “pods.” The PCC-10 is best suited for use with laptops and embedded
platforms.
PCLTA-10: A ½ size 16-bit, ISA adapter that includes a twisted pair transceiver
onboard, which supports the Windows plug-and-play standard. The PCLTA-10 is
best suited for use on a desktop PC.
PCLTA-20: Is the 32-bit PCI version of the PCLTA-10 adapter.
PCNSI: A ½ size ISA adapter that includes a standard modular transceiver (SMX).
The PCNSI is best suited for use on a PC that attaches to a channel type other than
twisted pair or one that requires the ability to easily switch between media types.
SLTA-10: A serial interface with built-in twisted pair transceiver that connects
(directly) to any host using RS232 or remotely using a Hayes compatible modem.
The SLTA-10 is best suited for remote connectivity or if your laptop does not contain
a type II PC slot.
Niagara Release 2.3
4–13
Chapter 4
4–14
Niagara Release 2.3
CHAPTER
5
LonTalk Protocol
The Neuron chip implements the LonTalk protocol, which is a complete networking
protocol that allows applications running therein to communicate with applications
running on other Neuron-based nodes elsewhere on the same network. The protocol
is a layered, packet-based, peer-to-peer communications protocol that follows the
OSI reference model, but it is optimized for the specific requirements of a control
system rather than those of a data processing system.
This chapter includes the following main sections:
•
•
•
•
•
•
LonTalk, as it relates to the OSI model—This section discusses how each layer
of the OSI model was used to implement the LonTalk protocol.
Logical Addressing—This section describes how the protocol defines a
hierarchical form of address to logically address each node. The hierarchical
structure of the protocol supports domains, subnets, and groups.
Communications Services—The LonTalk protocol offers four basic message
services that provide varying degrees of responsiveness, security, efficiency,
and reliability. This section discusses those options.
Collision Detection—The media access control algorithm implemented by the
protocol provides a collision avoidance methodology that strives to increase
bandwidth utilization at the same time it reduces collisions.
Timers—There are a number of trade-offs relating to network efficiency and
response time in selecting a communications service type. This section
describes how the various message service timers are used to increase
responsiveness and reliability without degrading network efficiency.
Optional Priority and Authentication—These sections discuss options for
implementing priority messaging—to ensure optimal response time for
priority messages—and security measures used to prevent unauthorized access
to modes and their applications.
Niagara Release 2.3
5–1
Chapter 5
LonTalk Protocol
LonTalk
LonTalk
LonTalk is Echelon's open-architecture communications protocol that defines the
rules for communicating on a LonWorks network. The protocol follows the OSI
reference model developed by the International Standard Organization (ISO) and it
uses all seven layers of that model, as shown in Table 5-1.
Table 5-1
Seven-layer OSI protocol model used with LonTalk protocol.
OSI Protocol Model
Layer Number
LonTalk Purpose Summary
Application Layer
7
Provides application compatibility.
Presentation Layer
6
Supports messaging between applications.
Session Layer
5
Supports remote actions, network management, and
authentication.
Transport Layer
4
Ensures reliable delivery of message packets by
providing four different messaging services.
Network Layer
3
Provides destination addressing to ensure messages
are delivered to the correct address.
Data Link Layer
2
Provides channel management, collision avoidance,
and an optional priority mechanism to improve the
response time of critical packets.
Physical Layer
1
Defines the physical connection to the transmission
medium.
A Closer Look at the LonTalk Protocol
Neuron chip hardware and firmware implement the complete OSI model as follows:
Application
Layer
Purpose: Defines the language and syntax that applications use to communicate with
one another.
The layer provides application compatibility by defining standard variable types and
a common object model. For example, two nodes that need to exchange a
temperature can use a standard network variable type to ensure that both nodes
interpret the temperature using the same engineering units (that is, degrees C).
Presentation
Layer
Purpose: Negotiates and manages the way data is represented and encoded, useful
whenever data is transmitted between different types of devices.
This layer supports messaging between applications by interpreting message packets
as network variables, explicit messages, or foreign frames.
Session Layer
Purpose: Starts, stops, and maintains order during communications sessions.
LonWorks messages can use a request-response service to invoke an action on a
remote node. As such, an application passes a message to the receiving application,
which generates a response. It is the session layer that defines the standard message
codes for exchanging network variables.
5–2
Niagara Release 2.3
Chapter 5
LonTalk Protocol
LonTalk
Network management messages facilitate the installation, monitoring, diagnoses,
and maintenance of LonWorks nodes by providing commands that can be used to
remotely define the network image of a device. Again, it is the session layer that
ensures that all LonWorks nodes can be installed using compatible network
management tools.
Lastly, the session layer also defines an authentication protocol that allows a
receiving application to determine if the sender is authorized to send it messages. It
is this service that can prevent unauthorized access to a node and its applications.
Transport Layer
Purpose: Ensures delivery of the entire message. The lower layer (Data Link) is only
responsible for delivering individual packets.
The transport layer ensures reliable delivery of messages by providing four different
messaging services including unacknowledged, acknowledged, repeated, and
request/response. If messages are exchanged using the acknowledged service, the
sending node waits for an acknowledgement from the receiver and resends the
message if the acknowledgement is not received. The sending application is informed
if an acknowledgement is not received after a user-configurable number of retries. If
duplicate messages are sent (due to a lost acknowledgement), the transport layer
rejects those.
Alternatively, the service can use unacknowledged or repeated services to send a
message once or a configurable number of times without waiting for an
acknowledgement.
Network Layer
Purpose: Establishes the route between the sending and receiving applications.
The network layer manages the delivery of messages to their correct destination(s).
Messages can be addressed to a single node, to a group of nodes, or to all nodes.
Addresses are formed using a domain/Neuron ID addressing format that supports the
use of routers for selective routing and filtering of messages based on their
destination. Routers use the network layer to confine traffic to segments on large
networks, thereby increasing the total capacity of the network.
Data Link Layer
Purpose: Transmits message packets from node to node based on device address.
The data link layer manages media access and determines timing of the message
transmission. Prior to transmitting a message, the data link layer waits for the
communications channel to become idle. Since multiple nodes may be waiting
simultaneously for the channel to become idle, the layer waits for a random interval
before attempting to transmit. If another node starts transmitting during this wait
period, the process is repeated. The random wait period is one of 16 different
intervals known as randomizing slots. A unique feature with LonTalk protocol is
that the number of randomizing slots increases as network traffic increases, which
tends to lessen the chance of collision even on networks that are heavily loaded.
Physical Layer
Purpose: Passes data bits onto and receives them from the channel.
Refer to “Transceivers, Media, and Network Topology,” page 4-6, for more details.
Niagara Release 2.3
5–3
Chapter 5
LonTalk Protocol
Logical Addressing
Logical Addressing
Since each Neuron ID is unique, it could be used as an address. But, such an
addressing scheme would support only one-to-one transactions (meaning no groups).
To simplify routing, the LonTalk protocol defines a hierarchical form of address to
logically address each node. In the process known as network management,
software is used to associate the node's unique 48-bit Neuron ID to a logical domain,
subnet, and node number.
The components of a logical address include:
Domain—The highest level of the addressing hierarchy is the domain level.
Nodes must be on the same domain to communicate, but if different network
applications exist on the same transmission medium, different domain
identifiers can be used to keep the applications separate. Each node can be a
member of up to two domains.
• Subnet—The second level of addressing is the subnet. A subnet is a logical
grouping of up to 127 nodes from one or more channels. Each domain can have
up to 255 subnets.
• Node Address—Each node must have a unique node number on a subnet. Up
to 127 nodes can exist on a subnet.
The transmission medium (channel) does not affect the way a node is logically
addressed. Domains can contain several channels as can subnets and groups.
•
All communications consist of one or more packets that are exchanged between
devices. Every node on the channel looks at every packet transmitted on the channel
to determine if it is intended for that node. If the node finds that the packet is
addressed to that node, it dissects the message to determine if it contains data for an
application running in the node or if it contains network management information.
Depending on the content of the message, the receiving node responds with an
acknowledgement, a response, or an authentication message.
Domain
A domain is a logical collection of nodes on one or more channels, but
communications can only take place between nodes configured on a common
domain. Therefore, a domain forms a virtual network that allows multiple domains
to occupy the same channel. This arrangement prevents nodes on different logical
networks from interfering with one another although they are on the same channel.
Although the LonTalk protocol does not support communications between domains,
a node can be a member of (no more than) two domains and act as a gateway between
two networks.
Domains are identified by a domain ID, which can be defined as 0, 1, 3, or 6 bytes.
Just as (48-bit) Neuron IDs are unique, an equivalent (six-byte) domain ID could be
used to ensure uniqueness. However, since the logical address of the sending and
receiving node is part of every message, six-byte domain IDs would add significant
overhead to each message.
5–4
Niagara Release 2.3
Chapter 5
LonTalk Protocol
Logical Addressing
It is quite uncommon to use lengthy domain IDs. In fact, if the applications using the
channel do not conflict and cause interference between networks, it is very common
to configure domain ID as zero bytes. In other words, if only one application is using
the channel, it is very possible that the devices on that channel will have their domain
IDs configured as zero bytes. These devices are considered as communicating on the
zero-length domain. A JACE communicates on the zero-length domain by default.
Subnet
The following rules apply to subnets:
A subnet is a logical collection of up to 127 nodes within a domain.
• Up to 255 subnets (32,385 total devices) can be defined within a single domain.
• Subnets cannot cross intelligent routers.
• If a node is configured to belong to two domains, it must be assigned to a
subnet for each of the domains. A node has one subnet and one node address
per domain to which it belongs.
•
Figure 5-1
Multiple subnets on a common channel (one domain).
Channel
1
2
3
4
Subnet 1
Figure 5-2
5
6
Subnet 2
Subnets cannot span intelligent routers (one domain).
Channel
1
2
3
4
R
5
Subnet 2
Subnet 1
Channel
4
5
6
Subnet 3
Niagara Release 2.3
5–5
Chapter 5
LonTalk Protocol
Logical Addressing
Figure 5-3
A node configured in two domains has subnet assignments for each.
Node (112):
Domain 1, Subnet 1,
Device 2
111
Channel
112
114
211
113
Domain 1, Subnet 1
212
213
214
Domain 2, Subnet 1
Node Address
Every node within a subnet is assigned a unique node number from 1—127, by the
network management tool at the time of commissioning.
Groups
Group addressing can supplement subnet/node addressing as a means of passing
messages to one other node. When you define a group number in the address table
for a node, you are providing the means to logically group nodes without regard to
their physical location on the domain—nodes within a group can span any number of
channels, routers, or bridges.
The following rules apply to groups:
A group can contain up to 64 nodes (acknowledged services only—there are
no node limits on groups using unacknowledged services).
• One LonWorks network can support up to 256 groups.
• A node can belong to 15 different groups (utilizing acknowledged messaging
service).
•
Figure 5-4
Group membership can span any number of channels, routers, or bridges.
Channel
1
2
3
Nodes 1—3 and 9
belong to a
common group.
R
Channel
Subnet 1
R
4
Channel
7
5
6
Subnet 2
8
9
Subnet 3
5–6
Niagara Release 2.3
Chapter 5
LonTalk Protocol
Communications Services
In addition to the obvious physical advantages of using a group structure, this
approach allows a number of nodes to be reached at only one address (multi-cast
messaging). This method keeps message record keeping inside each Neuron to a
minimum and is a very efficient way to use network bandwidth for one-to-many
network variable connections.
Addressing Formats
Nodes are addressed using one of five addressing formats.
If the address data specified is… The nodes that receive the message are…
Domain:X, Subnet equals zero
All nodes assigned to Domain:X
Domain:X, Subnet:Y
All nodes assigned to Domain:X and Subnet:Y
Domain:X, Subnet:Y, Node:Z
That specific logical node
Domain:X, Group:G
All nodes assigned to Group:G
Unique Neuron ID
Specific physical node
Routing Messages
As previously discussed, a router or bridge is a special purpose node that contains
two Neuron chips and transceivers, each connected to a separate channel. As
illustrated in Figure 5-4, routers and bridges pass packets back and forth between two
channels.
A physical layer repeater is the simplest form of a router, merely forwarding
all packets it receives. Using a repeater, a subnet can exist across multiple
channels.
• A bridge forwards messages for a given domain ID. Using a bridge, a subnet
can exist across multiple channels.
• A learning router monitors network traffic and learns the topology at the
domain/subnet level and it uses that knowledge to selectively route packets
between channels. Subnets cannot cross routers—the two sides of a router
must belong to separate subnets.
•
The LonTalk protocol offers four basic types of message service. The first two,
acknowledged and request/response, are end-to-end acknowledged and the other
two, repeated and unacknowledged, are unacknowledged. In addition to the LonTalk
message service options, the protocol offers a priority mechanism to improve
response time for critical messaging and authentication for security.
System design should employ the most effective use of network efficiency, response
time, security, and reliability, but, generally speaking, the LonTalk protocol defaults
to that which provides the greatest level of safety and verification for all network
Niagara Release 2.3
5–7
Chapter 5
LonTalk Protocol
communications. Although using the acknowledged service is the most reliable, it
does use greater network bandwidth than does unacknowledged or repeated.
Prioritized packets ensure that the packets are sent in a timely fashion. And, adding
authentication to designated transactions adds a level of security, but requires twice
the number of packets to complete a transaction than non-authenticated transactions.
The JACE defaults to the unacknowledged message service, but each bind can be
modified as needed.
Acknowledged Service
The most reliable message service is acknowledged. With this service, messages are
sent to a node or a group of nodes, and individual acknowledgements are expected
from each receiving node. If an acknowledgement is not received from all nodes, the
transmitting node repeats the transaction. The number of retries and the timeout are
both user-configurable.
Request/Response Service
The request/response service is as reliable as the acknowledge service, in fact, it is
the same as the acknowledged service, except a response is sent rather than an
acknowledgement. This is an important difference—the application processor on the
receiving side (of a request/response message) processes the incoming message
before it returns a response, which may include data, to the source node. The same
retry and timeout options are available as with the acknowledged service (that is, a
transaction timer and a retry counter are used).
Repeated Service
Also referred to as the unacknowledged/repeated service, this service sends a
message to a node or a group of nodes multiple times (n times at intervals of m
milliseconds) and expects no response. This service may be used when broadcasting
to a large number of nodes to avoid network overload (caused by an excessive
number of responses from the receiving nodes).
Unacknowledged Service
The least reliable message service is unacknowledged. With this service, the message
is sent one time and no response is expected. The unacknowledged service is
typically used when the highest level of network performance is needed, network
bandwidth is limited, and the application is not sensitive to the loss of messages. A
timer, called the free buffer wait timer, is used to determine how long the node waits
for a free message buffer prior to sending its message.
5–8
Niagara Release 2.3
Chapter 5
LonTalk Protocol
Collision Detection
Collision Detection
All networking protocols use a media access control algorithm to allows devices to
determine when they can safely send a packet of data. These algorithms are designed
to reduce the number of collisions that occur when two or more nodes on the network
attempt to send data at the same time. Packets that collide cannot be successfully
delivered, which results in a delay in response time.
The LonTalk protocol implements a unique collision avoidance algorithm that allows
an overloaded channel to carry close to its maximum capacity, rather than have its
performance degrade due to excessive collisions. This is of particular importance
when the medium being used lends itself to collisions (for example, twisted pair).
In such a case, the LonTalk protocol:
1.
Optionally cancels transmission of a packet as soon as a collision is detected, and
2.
Waits a random period of time before attempting to retransmit.
This allows the node to immediately retransmit any packet that may have been
damaged by a collision, rather than wait the entire duration of the retry time to notice
that no acknowledgement was received, then retransmit the packet. Also, by
randomizing the access delay time, subsequent transmissions are less likely to
collide.
In the case of nodes that use the unacknowledged message service, undetected
collisions result in lost messages.
Timers
There are several timers used with the LonWorks messaging service. Typically, these
timers are automatically configured by a network management tool.
Also known as layer 4 timers, these include:
Free Buffer Wait Timer
• Transaction Timer
• Group and Non-Group Receive Timers
• Repeat Timer
•
Free Buffer Wait Timer
When the unacknowledged message service is used, the only timer that is involved
is the free buffer wait timer. The free buffer wait timer determines the maximum
length of time a node waits for a free buffer when sending a message. The timer can
be deactivated (by setting it to zero), which causes the node to wait forever on a free
buffer.
Niagara Release 2.3
5–9
Chapter 5
LonTalk Protocol
Optional Priority
Transaction Timer
When the acknowledged message service is used, several timers are involved. In
addition to the free buffer wait timer, the transaction timer is used to determine how
long a node waits for an acknowledgement before re-transmitting the message. If an
acknowledgement is not received, the sending node will continue re-transmitting the
message up to 15 times (determined by retry count).
The request/response message service uses the same set of timers as the
acknowledged message service.
Note
Packets may go through routers to reach their final destination. When determining
the transaction timer value, allow sufficient time for the packet to reach its
destination and an acknowledgement to be returned.
Receive Timers
This timer is used for detecting duplicate messages. When a packet reaches its final
destination, the receiving nodes attempt to allocate receive transaction records and
they start receive timers. If the address mode of the packet uses group addressing, the
receiving node uses the group receive timer. If any other addressing mode is used, the
node uses its non-group receive timer. When the receive timer expires, the transaction
record is deleted and any new packets from the same source address are discarded as
duplicates.
Repeat Timer
When using the repeated message service, the repeat timer determines how
frequently the message is repeated. The transmitting node sends the message n times
at an interval of m milliseconds, where n is the retry count and m is the repeat timer
value.
Optional Priority
The LonTalk protocol supports an optional priority messaging service that gives
priority messages earlier access to the transmission medium. The protocol allows the
user to allocate priority time slots on a channel dedicated to priority nodes and
because there is no contention for the medium during the priority portion of a packet
cycle, those packets realize improved response time over non-priority nodes.
The priority slot assigned to a node applies to all priority packets sent from that node.
One, all, or some portion of the packets sent from that node can be marked as using
the priority service. Priority designation within a node is made for each individual
network variable or message tag at compile time, and, in the case of network
variables, can optionally be changed by the user during and/or after installation.
5–10
Niagara Release 2.3
Chapter 5
LonTalk Protocol
Authentication
Lower priority numbers indicate a higher priority. For instance, a priority packet sent
from a node assigned priority slot #2 is transmitted before a packet sent from a node
assigned priority slot #4. Priority slots are governed by the following:
Setting a node's priority slot to zero indicates that none of its packets are to be
transmitted in the priority slot.
• Slot 1 is reserved for a network management tool to ensure that no application
can render a channel incapable of being interrupted by a network management
tool.
• Slots 2—127 (depending on the medium and the number of slots allocated on
the channel) are then available for prioritized packets.
•
When a priority packet is generated within a node, it travels out of the node on the
priority queue ahead of any pending non-priority packets buffered for transmission.
Similarly, when a priority packet reaches a router, it goes to the head of the router
queue (behind any other queued priority packets) and is forwarded to the far channel
using the router's priority slot if one has been configured.
Authentication
Authentication is the process used to verify the integrity of a transmitted message.
The LonTalk protocol supports authenticated messages to prevent unauthorized
access to nodes and their applications. Authentication is configured individually for
each network variable (as part of its messaging service type) as well as for network
management transactions (enable/disable authentication network-wide).
Authentication is achieved by distributing 48-bit keys to the nodes at installation,
with a sender and receiver of an authenticated message both requiring the same key.
The authentication process includes the following steps:
1.
A message requiring authentication is sent.
2.
The receiving node challenges the sending node to provide authentication
information. Each time a challenge is made, the receiving node uses a random
64-bit challenge number.
3.
The sending node uses its authentication key and the data from the original
message to transform the challenge message, and then it responds. The
receiving node transforms the challenge message, as did the sending node. The
receiving node compares the result of its transformed message with the value
received from the sending node. If both match, the message is accepted.
4.
The receiving node sends an acknowledgement to the sending node.
Refer to Figure 5-5 for an illustration of the flow of a network variable update from
an application in a source node to a group of destination nodes. This illustration
depicts how the source node uses its NV tables and address table to get information
about destination nodes, then format outbound messages. Figure 5-5 also illustrates
how destination nodes receive and process inbound messages.
Niagara Release 2.3
5–11
Chapter 5
LonTalk Protocol
Authentication
Figure 5-5
Network Variable Update Flow Diagram.
Source
Node
NV Config Table
(typical for 62)
pri
dir
select - hi
The NV selector is a 14-bit
number assigned by a
network management tool.
The selector is the same for
all NVs bound together.
APPLICATION
MODIFIES
NETWORK
VARIABLE
select - lo
turn
svc type
auth
addr tbl index
NV CONFIG
TABLE
(NV selector &
Addr Table Index)
GET SELECTOR
FROM NV
CONFIG TABLE
ADDR TABLE
(Addr Table Entry)
GET
DESTINATION
ADDR FROM
ADDRESS TABLE
Group Address Format
1
size (2-64)
dom
member id (0-63)
repeat timer
retry count
receive timer
transmit timer
There are 15 address table
entries per node. Each NV
is associated with an entry
in the address table. Group
addressing is typically used
for NV bindings. The limits
of group addressing are:
255 groups per domain and
64 members per group. A
single node can be a
member of multiple groups.
NV UPDATE
MESSAGE
FORMATTED
group (0-255)
Packet Format
DOMAIN
ID
SOURCE
ADDR
0-6
bytes
subnet/
node
DEST
ADDR
NV
SEL
DATA
subnet/
node,
group, or
bcast
14-bit
number
1-31
bytes
TRANSMIT
MESSAGE
MESSAGE SENT TO
GROUP
ADDRESS
TABLE
(Group
Numbers)
NV CONFIG
TABLE
(Selectors)
Tareget
Node 1
5–12
RECEIVE
MESSAGE
RECEIVE
MESSAGE
GROUP
MEMBER?
GROUP
MEMBER?
YES
YES
SELECTOR
MATCH?
SELECTOR
MATCH?
YES
YES
UPDATE DATA
UPDATE DATA
NOTIFY
APPLICATION
NOTIFY
APPLICATION
DONE
DONE
ADDRESS
TABLE
(Group
Numbers)
NV CONFIG
TABLE
(Selectors)
Target
Node 2
Niagara Release 2.3
CHAPTER
7
This chapter includes the following sections:
•
•
•
•
•
About Network Management—A high-level view of network management.
System Overview—A list of functions needed for a LonWorks network.
Structure of a Network Management Tool—The structure and purpose of a
LonWorks network management tool and how it is used to install nodes.
Network Database—Introduces Echelon's LNS operating system and
accompanying network database design and some of the tools that are available
to support (LNS) network design and system management. In addition, this
section offers discussions of third party database designs and tools.
Application Programming—This section discusses some of the tools that are
available to create control applications and download them into programmable
controllers on the network.
About Network Management
Network management defines the architecture of the LonWorks network, including
channels, routers, nodes, and more. During the network management process, each
device is queried and information about that device is recorded including its name,
program ID, Neuron ID, its network variables, and binding information. All of that
information is used to construct what is known as a network database.
Network management tools typically provide graphical, applications-oriented views
of the system and allow the user to develop control solutions in that environment.
This protects the user from the specific complexities of the underlying technology as
they design, commission, manage, and maintain LonWorks networks.
Network management tools often provide the following:
Device programming
• Device installation and configuration
• Device monitoring and control
• General purpose support
•
Niagara Release 2.3
7–1
Chapter 7
System Overview
Device programming: Programmable devices require application software to be
downloaded with a field programming tool. Typically, this software presents control
functions as function blocks and allows the user to logically connect them to create
system-level capability. The programming tool then takes the high-level
representation of the system and transforms it into application code that is
downloaded into the programmable device when it is installed.
Device installation and configuration: Configurable devices are typically
delivered in an unconfigured state, which means they have not been assigned a
network personality. Although the devices come from the manufacturer with an
application embedded in the Neuron chip, they must be assigned a unique address,
they must have addresses of the other devices on the network defined, and the
selectors of the network variables they use for communicating NV updates must be
identified.
Device monitoring and control: In systems where supervisory functions are
required, device monitoring and control software is often used. This software
provides operator interface, timed control, global data passing, data collection and
archival, alarm routing, and more.
General purpose support: These tools include network diagnostics, protocol
analyzers, simulation tools, and network design and system integration tools.
There are a variety of network management tools from various manufacturers
including LonMaker by Echelon, VisualControl by VisualControl Inc., System
Integrator by Circon, the Niagara Framework by Tridium, and other proprietary
systems.
System Overview
The major functional areas of a LonWorks system include the following.
•
•
•
•
•
Network database—A collection of information about the nodes that exist on
the network including name, Neuron ID, program ID, network image, and so on.
Network management—The services that are needed to install and maintain
nodes on the network.
Application programming—Software that is used to create Neuron-C code
that is loaded into a programmable device, which defines its control logic.
User interface—Human/machine interface used to monitor and control
LonWorks devices.
Network interface—That which provides connectivity for each node on the
network.
Figure 7-1 shows the relationship between these functional areas.
7–2
Niagara Release 2.3
Chapter 7
Structure of a Network Management Tool
Figure 7-1
System diagram.
Human Machine
Interface
Network
Management
Tool
Network
Database
Application
Programming
Tool
Network
Interface
LonWorks Network
Theoretically, the structure of a network management tool, regardless of
manufacturer is identical. This structure is represented in Figure 7-2 below.
Figure 7-2
Structure of a network management tool.
User Interface
Add-On
Plug-In Interface
Tool Kernel
Database
LonWorks Interface
Niagara Release 2.3
7–3
Chapter 7
The tool kernel represents all of the functionality of the tool itself—it is the core
runtime components of the network management tool. The user accesses these
functions through a user interface component. The tool communicates with the
LonWorks network through an interface, which implies hardware of a particular
design and the corresponding software drivers.
The database contains all of the information about the LonWorks network—the
devices that exist on the wire, their configuration parameters, and the data shared
between them (bindings). And, plug-in interfaces are provided to add
application-specific features or services to the core software.
Note
The phrase “the wire” is used herein to describe the channel. In the Niagara
architecture, which supports FTT-10 topology, the channel is indeed a segment of
wire. In other architectures, however, the transmission medium may be something
other than wire.
Network Management Services
LonWorks network management services are a formal part of the LonTalk protocol.
Support for these services is contained in each LonWorks node. This guarantees that
all nodes, regardless of manufacturer, can respond to LonTalk commands from nodes
designed to perform network management functions.
Network management functions typically include:
•
•
•
•
•
•
•
•
•
•
•
Discovering new nodes as they are physically attached to the network.
Network configuration and commissioning of nodes.
Receiving service pin messages.
Importing node self-documentation and self-identification information.
Importing node external interface files.
Copying configuration network variable values from one node to another.
Installing, removing, and replacing nodes.
Connecting and disconnecting network variables and message tags.
Loading application images into nodes.
Querying and setting node properties, such as locations, priority slots,
self-documentation, and network variable attributes.
Resetting, winking, and testing nodes.
LonWorks Network Installation
The network installation process determines how each device will be ultimately used
in the system and establishes the relationships between it and other devices on the
network. Among the details defined for each device at installation time, a network
management tool tells a device what its logical address is, what type of internal
configuration the device has, where the device resides on the network, and with
which other devices it is required to talk.
7–4
Niagara Release 2.3
Chapter 7
Network Database
Addressing
Addressing is the first step in the installation process—the network management tool
first needs to know the unique Neuron ID of the device. There are a number of ways
to acquire a device's Neuron ID.
If it is printed on the device label, it can be entered via the keyboard.
• Service pin the device.
• If a barcode is printed on the device label, it can be scanned with a barcode
reader.
• Query and wink the device.
•
Binding
Binding tells each node what other nodes to talk to—it tells the node to where it can
send data and from where it should expect data. Bindings are established between
network variables (network variable outputs to network variable inputs) for the
purpose of passing data.
Fan in. NVIs can read one or more network variable outputs.
• Fan out. NVOs can write to one or more network variable inputs.
• Network management tools enforce type checking for each network variable
binding. Standardized data types provide the basis for interoperability.
•
External
Interface Files
(XIF)
All LonMark devices contain self-documentation that describes how the device is to
be used and what its network variables mean. The file is generated by the device
manufacturer and its contents can be uploaded to a network management tool to
understand how to interface to that device. External interface files (the text version)
have a .xif extension. These files include device self-documentation, the number of
address table entries, the number of message tags, and the number, types, and
directions of network variables. For more information on using external interface
files refer to the LonMark External Interface File Reference Guide.
Network Database
As a by-product of installation, network management tools create a network
database. The database contains comprehensive descriptions of all network devices
including channels, routers, nodes, network variables, binding information, and
more. Since an image of the network resides in each of the nodes, the network
database may not be needed for normal operation—nodes will continue to be able to
share data. But, access to the network database is necessary for network monitoring
and control applications, modification, and maintenance.
There is no single database structure in use today. Echelon has created an operating
system (and accompanying database structure) that they refer to as LNS (LonWorks
Network Services), but several other vendors have created different types of database
structures. Since LonWorks technology is an evolving technology, there is no way to
tell which structure will become the industry standard, if any.
Niagara Release 2.3
7–5
Chapter 7
Network Database
LNS
Echelon has developed an architecture called LNS that provides a foundation for
installation, maintenance, monitoring, and control tools. Their design revolves
around the requirement for a network database to maintain network configuration
data for each node on the network. Any tool or node that needs to change the
configuration or read/write a property of a node sends a service request to the device
where the network database is maintained.
LNS is a client-server operating system with a single LNS server that supports
multiple interoperating client applications. There is only one LNS network database
per LonWorks network and it is always located on the PC that is running the LNS
server. The LNS server can run standalone on a PC attached to a LonWorks network,
where multiple remote clients log on to access the shared LNS database. Or, on larger
systems, it may be necessary to split the database into multiple segments running on
multiple servers or supervisory controllers. Remote clients can communicate with the
LNS server via the LonTalk protocol or via IP.
To speed commissioning of devices from different manufacturers, LNS defines a
plug-in standard. This standard allows sensor, actuator, and device manufacturers to
provide customized applications for their products. When those products need to be
configured, an LNS-based tool presents a configuration screen that the manufacturer
has tailored to the device being configured. Regardless of the LNS tool being used,
configuration of the device is consistent.
Note
It is important to note that when using the LNS architecture, Echelon requires
vendors to pay royalty fees on a per-node basis for each node installed.
Two issues arise with this type of (server-based) design.
Refresh rates are typically slow. The larger the database and the more widely
dispersed it is, the more sluggish response is likely to be. LNS is limited to 40
transactions per second (20 requests—20 responses).
• Server-based HRDBs (hard disk resident database) are notorious for becoming
unsynchronized. In other words, when a technician makes a change to the
network database (on his laptop), all subsequent modifications must have
access to that copy of the database. Otherwise, the databases become
unsynchronized.
•
LonMaker for
Windows
There are a number of LNS-based network management tools on the market.
LonMaker for Windows is Echelon's LNS-based integration tool that supports
network engineering and installation using Visit as a graphical interface. LonMaker
includes:
Network design tool, which allows you to design LonWorks networks off-line.
• Network installation tool, which allows you install nodes on site once the
network has been engineered (off-line).
• Network documentation tool, which uses a Visio drawing to represent the
installed network, making it useful for as-built reports.
•
7–6
Niagara Release 2.3
Chapter 7
Network Database
•
Network management tool, which allows you to commission, manage, and
maintain LonWorks devices.
Echelon's LonMaker network management tool uses the client-server capabilities of
LNS to allow multiple LonMaker tools (running on different PCs) to simultaneously
access the same LNS server.
Refer to
VisualControl
Network
Manager
(VCNM)
See http://www.echelon.com/lonmaker/ for complete description.
VCNM is an LNS-based network management tool marketed by VisualControl, Inc.
There are a number of versions of VCNM ranging from standard to enterprise-level,
which include:
•
•
•
•
•
Concurrent engineering of a single, server-based LNS database
Remote management via dial-up connection or IP
Plug-in support
Alarming and trend data collection
Logging and security
The standard VCNM package includes a 256 node license. Additional nodes can be
purchased.
Refer to
See http://www.visualcontrol.com/vcnet.htm for a complete description
Third Party Designs
Proprietary network database designs exist, as do proprietary user interfaces and
network management tools. Both server-based and embedded designs are supported.
These designs eliminate the Echelon royalty fee and each of them has their own
advantages and disadvantages.
Niagara
Framework
The Niagara Framework by Tridium, Inc. The Niagara JACE station database runs
within a Java virtual machine (JVM) that provides an embedded, controller-level
environment in which to configure, manage, and run the nodes and services required
by a control system application.
In addition to its embedded design, the Niagara Framework provides network
management support for both open standards devices (LonWorks and BACnet) and
legacy products, as well as a comprehensive applications development environment.
The engineering environment (Java Desktop Enviroment, or WorkPlace Pro) provides:
Full graphical user interface
• Synchronization of controller databases and database storage and backup
• Password protected access
• Data collection and enterprise-level information exchange
•
Niagara Release 2.3
7–7
Chapter 7
Application Programming
Synchronization of global time functions and central scheduling
• Alarm processing and routing
• Extensive support for all standard energy management functions
• Customization for non-standard control applications
•
Icelan 2000
Refer to
Circon SI
Peak Component's network management tool.
See http://www.ieclon.com/tutorial.html for a complete description.
Circon's network management tool.
Refer to
See http://www.circon.com/products/default.asp for a complete description.
The programming language for LonWorks devices is Neuron-C. Most modern
LonWorks application programming tools provide a graphical development
environment that allows the user to create control strategies, compile that logic into
Neuron-C, then download it into programmable controllers on the network.
LonWorks devices come in varying degrees of programmability including:
Configurable Devices—These devices are application-specific, in that they
come from the manufacturer with an application, but require some degree of
customization.
• Programmable Devices—Also known as general purpose controllers, these
devices are provided with only the code that is necessary to enable I/O—actual
control logic must be created with a software tool.
• Hybrid Devices—Hybrids are a mix between application-specific devices and
general purpose controllers. When using hybrid devices, a general purpose
application is created by binding data within a node from a collection of
application-specific algorithms. Each algorithm is represented in the controller
as a plug-in, and the plug-ins are pieced together to form an application.
Echelon's Lampooned devices are examples of hybrids.
•
Configurable Devices
Application-specific devices come from the vendor with a Neuron-C application
embedded in the Neuron chip. The application exposes a set of network variable
inputs and network variable outputs that are used to create bindings between the
controller and other devices on the network. Typically, these canned applications
require some level of configuration for things like setpoint, alarm limits, tuning
properties, and so on.
7–8
Niagara Release 2.3
Chapter 7
Plug-Ins
A plug-in is a piece of software that can be accessed by a network management tool
to perform a specialized task. Plug-ins do not have to be specific to a device or
functional block, in fact, some plug-ins provide generic services that can be used with
multiple devices at the system level. But, quite often, plug-ins are created by
manufacturers as visual representations (that is, objects) with the network variables
and configuration properties for an application-specific node.
In the case of LonMaker for Windows, plug-ins are Active-X components that plug
into LNS and provide some simple functionality (for example, data logging).
Programmable Devices
A general purpose controller is provided with only the code necessary for it to
interface to its I/O. In order for a general purpose controller to perform work, it must
be programmed using an application programming tool that produces Neuron-C
code, which is compiled then downloaded to the controller.
Typically, vendors provide graphical programming tools that insulate the user from
the details of Neuron-C. These tools are generally object oriented—software objects
or function blocks that represent pre-configured functionality are selected from a
library to build control sequences. Some of these tools support devices from different
manufacturers, but many of them are device and/or manufacturer-specific.
Application Programming Tools
This section introduces some of the more popular application programming tools that
are used by system integrators to create control logic and download the application
into programmable LonWorks devices.
LonBuilder and
NodeBuilder
Echelon markets two LNS-based software products for programming LonWorks
devices. These are LonBuilder and NodeBuilder. LonBuilder is an engineering
environment for developing and debugging applications for multiple nodes, a
network manager to install and configure the nodes, and a protocol analyzer to
examine network traffic to ensure adequate network capacity and to debug errors.
NodeBuilder is a subset of the aforementioned used by manufacturers to design and
test individual nodes.
VisualControl
Graphical
Programming
(VCGP)
VCGP is a graphical development system that allows you to program general purpose
LonWorks nodes using its 90+ pre-defined function blocks. It also includes a utility
for creating custom control blocks. VCGP generates and compiles Neuron-C that can
be downloaded to any node with either flash or EEPROM memory and it supports
over 30 different types of controllers from various manufacturers.
Refer to
See http://www.visualcontrol.com/vcgra.htm for a description with screen capture.
Niagara Release 2.3
7–9
Chapter 7
Niagara
Framework
The core of Tridium's patent-pending technology is the Niagara Framework object
model, which allows real world devices to be modeled in a consistent manner through
reusable software objects. Then device integration services provide the glue between
the physical device and its software object. These services allow the objects to
communicate with the actual devices using their native protocols and their respective
networks. The software objects use their integration services to read real-time data,
send commands to the device, and provide support for reconfiguration and
reprogramming.
The Java Desktop Environment (JDE), also known as WorkPlace Pro, is a
comprehensive set of engineering tools combined into one, common, easy-to-use
applications development environment that supports Niagara Framework solutions.
It supports rapid device integration using open industry standards, plus:
Comprehensive network management and application programming tool that
integrates LonWorks, BACnet, Modbus, third-party legacy products, and
more.
• Non-LNS based.
• An object-oriented programming tool that can be used to create supervisory
application logic that resides in a supervisory controller (JACE).
• Supports plug-ins from a wide variety of application-specific controllers.
•
7–10
Niagara Release 2.3
CHAPTER
6
Interoperability
Although there are varying degrees of interoperability, the basic desire is for an open
system design with the ability for multiple vendors' products to be integrated into one
flexible system without the need for custom integration products. The LonWorks
design is one that supports media independence and does not prescribe a strict
structure for device applications. As a result, simply assembling a collection of
LonWorks devices does not guarantee interoperability—devices that are to operate
together must be designed according to a consistent set of rules. These are provided
in the LonMark Interoperability Guidelines published by the LonMark Association.
This chapter includes the following sections:
•
•
•
•
•
•
LonMark Interoperability Association—An introduction.
Network Variables—The LonTalk protocol implements standard data
structures known as network variables that are used to exchange data between
nodes. This section discusses how nodes share data using network variables
and the logical connections between them, which are called bindings.
Configuration Properties and Explicit Messages—These discussions describe
how configuration properties are used to customize applications running in
nodes and how these applications can send and receive non-standard messages.
Applications—Configurable devices versus programmable devices.
Functional Profiles and Application Interface, LonMark Objects, and Program
IDs—These sections describe how manufacturers use functional profiles to
publish device functionality. These details are expressed in an external
interface file, which defines the network variables and configuration data
exposed to the outside world used to create relationships with other devices.
Network Variable Typing and Naming Conventions.
LonMark Interoperability Association
The LonMark Interoperability Association (the LonMark Association), through
member dues, is instrumental in developing standards for interoperability, certifying
products to those standards, and promoting the benefits of interoperability. The
association employs a rigorous review and approval process that includes a
cross-functional review team to ensure that profiles not only interoperate within an
Niagara Release 2.3
6–1
Chapter 6
Interoperability
Network Variables
individual subsystem, but also provide interoperability to other subsystems. For
example, a smoke detection device might incorporate an Alarm network variable that
is an essential characteristic of the fire system, but is also available elsewhere in the
building for coordination of elevator control, damper control, and exit lighting.
Only LonWorks devices that have been certified by the association can carry the
LonMark logo—LonMark devices represent the highest level of interoperability.
LonMark products that incorporate approved HVAC, Lighting, and Fire profiles are
available on the market from market leaders such as Circon, Electronic Systems
USA, Helvar, Honeywell, Hycal, Invensys, Johnson Controls, Lexel, Lighthouse,
Philips, Safegard, TAC and others. An up-to-date listing of all available LonMark
products is available on the LonMark Association's Website.
Network Variables
Echelon defines a network variable as a data item that a particular device application
program expects to get from other devices on a network (an input network variable)
or expects to make available to other devices on a network (an output network
variable). Network variables can be any single data item, or they can be data
structures. Examples of network variables may include temperature, switch positions
(binary), or actuator position (analog). An example of a network variable that uses
data structures is SNVT_temp_setpt—this one variable contains 6 setpoints.
Applications running in LonWorks devices do not need to know anything about
where input network variables come from or where output network variables go.
When the application changes a value, it simply passes the new value to firmware.
Using a process that takes place during installation called binding, the device
firmware is configured to know the logical address of the other devices on the
network—the device is then able to assemble a message and send it to the devices
that need the information. In a similar fashion, when the device firmware receives an
updated value for an input network variable needed by the application, it passes that
data to the application.
The binding process creates soft wiring between nodes that represent logical
connections between an output network variable (NVO) on one node and an input
network variable (NVI) on one or more other nodes. A typical node on the network
may have multiple connections, both inbound and outbound. When the application
running in the sending node writes a new value to an NVO, the value is automatically
propagated to the network and received by all nodes that have a bound NVI. In this
way, network variables are continuously updated.
A simple example of soft wiring can be seen in Figure 6-1. One node monitors the
position of a switch and exposes that value using the output network variable called
switch_on_off. Another node controls the on/off state of a light bulb. The second
node has an input network variable called lamp_on_off. A binding between
switch_on_off and lamp_on_off, creates a connection between the two devices that
can be used by device firmware that has the same effect as physically connecting a
wire between the switch and the lamp.
6–2
Niagara Release 2.3
Chapter 6
Interoperability
Network Variables
Figure 6-1
Network Variable Connection.
Network Variable Updates
Switch
Controller
Lamp
Controller
Network variable connections:
Can create virtual wiring
• Can be deleted and added with a network management tool
• Can be changed without reprogramming the device
• Make adds, moves, and changes easy.
•
Network Variable Restrictions
There are some restrictions on network variable bindings (that is, only so many
bindings can be made in given situations).
A Neuron-based node can have up to 62 network variables bound.
• A Hosted node can have up to 4096 by using a LonWorks network interface.
•
Standard Network Variable Types (SNVTs)
Every network variable is defined by a data type. Data type defines the units, scaling,
and structure of the data contained within a network variable. The LonMark
Association has defined and published definitions for at least 145 common data types
(version 10.00) including standard network variable types (SNVTs, pronounced
“sniv-its”). When programmers program Neuron chips using the Neuron-C
programming language, they declare inputs, variables, and outputs using SNVTs.
Alternatively, manufacturers can define their own user-defined network variable
types (UNVTs).
Note
Most SNVTs use System Internationale (SI) units (metric) rather than their English
equivalents. Any necessary conversion to English units is performed by logic in the
node or at the PC interface to it.
Niagara Release 2.3
6–3
Chapter 6
Interoperability
Network Variables
SNVTs are expressed as either fixed-point numbers, floating-point numbers,
enumeration lists, or structures. For a complete listing of all the different SNVTs,
refer to the LonMark SNVT Master List document.
The naming convention for a SNVT is:
SNVT_name
The above can be extended to indicate data species or other delimiters. For example:
SNVT_name_f
denotes floating-point data.
A specific example of a SNVT that is commonly used in HVAC applications is the
standard network variable type SNVT_temp_p. This SNVT is used to pass
temperature data in building control applications. The SNVT exposes a fixed decimal
value in the range -273.17 to 327.66, is displayed in degrees C, with a resolution of
0.01ºC.
Structured SNVTs
Many SNVTs are expressed as fixed-point or floating-point values, which means
they accommodate a single integer or floating-point number. Refer to the SNVT
Master List for details on type definitions for these values.
Data type translators that convert data from one type to another are available. For
instance, if an application can read only floating-point data and the available SNVT
is an integer value, it would be necessary to convert the value—a conversion object
could be used to read an integer value on its NVI and write a floating point value out
on its NVO.
In addition to single-fielded variables, SNVTs are defined for structured data,
meaning they will accommodate more than one data field. For example,
SNVT_switch has two fields: state and value.
State indicates binary status (either 0 for Off or 1 for On).
• Value provides a discrete step indication (0 to 100%). For example, a value of
0%, 33%, 66%, and 100% can respectively represent fan speeds of Off, Low,
Medium, and High.
•
In the case of structured SNVTs, it may also be necessary to dissect an NVO or
construct an NVI. Some manufacturers provide “demultiplexing” objects that read in
a structured SNVT on a single NVI, break it down into its component parts (fields),
and make available multiple NVOs (as primitive data) for use in the device's
application. Conversely, they may also provide “multiplexing” objects that read in
multiple values from the application (on NVIs), assemble that into a structure, and
expose the structure as a single NVO.
6–4
Niagara Release 2.3
Chapter 6
Interoperability
Configuration Properties
Enumerated Lists
SNVTs that are defined as enumerated lists accommodate integers that have an
enumeration type definition. For example, SNVT_date_day stores a value from zero
(Sunday) to six (Saturday).
Also, it is worth mentioning that you might encounter a structured SNVT with one
or more of its fields being enumerated. For instance, SNVT_hvac_status includes a
field (Mode) that stores a value from 0 to 11. The enumeration definition for Mode is:
0: HVAC_AUTO
1: HVAC_HEAT
2: HVAC_MRNG_WRMUP
3: HVAC_COOL
4: HVAC_NIGHT_PURGE
5: HVAC_PRE_COOL
6: HVAC_OFF
7: HVAC_TEST
8: HVAC_EMERG_HEAT
9: HVAC_FAN_ONLY
10: HVAC_FREE_COOL
11: HVAC_ICE
Nodes exchange information using network variables, but most nodes also require
some level of customization. Data structures called configuration properties
provide documentation standards for these properties as well as standards for
network message formats used to download configuration data to a device. Similar
to SNVTs, the LonMark Association has defined a standard set of configuration
property types called standard configuration property types (SCPT, pronounced
“skip-its”).
SCPTs are defined for a variety of configuration properties that specify default
behavior, minimum and maximum limits, gain settings, and all other customizable
properties. In situations where SCPTs are not defined for a particular feature,
manufacturers can define their own configuration property types. These are referred
to as user configuration property types (UCPTs).
Refer to
For an in-depth discussion of configuration properties, refer to Section 4 of the
LonMark Application Layer Interoperability Guidelines (078-0120-01C).
Due to the highly specialized nature of the messaging scheme required for using
SCPTs, some manufacturers elect to provide read/write access to configuration
properties using network configuration inputs (NCIs). An NCI is typically a constant
configuration value that is infrequently changed and is implemented using SNVT
data types. While NVIs and NVOs exist in RAM, configuration property values
typically reside in non-volatile memory on the node (typically EEPROM or flash).
Because of this, NCIs are not typically bound to NVOs in other nodes.
Niagara Release 2.3
6–5
Chapter 6
Interoperability
Explicit Messages
Caution
Non-volatile memory such as EEPROM and flash will support a finite number of
writes. Care must be taken to avoid excessively writing to persistent storage when
these technologies are used—it is possible to “wear out” memory. For this reason, it
is not recommended to bind NCIs, or otherwise have them continuously changed.
Explicit Messages
Applications that require a different data interpretation model then network variables
can send and receive explicit messages. Explicit messages use LonTalk messaging
services, but with minimal data interpretation. Each explicit message contains a
message code that can be used by the application to determine the type of data
contained in the message.
Applications
Every device must contain an application. Applications may be pre-configured at the
factory or downloaded (file extensions .APB and .NXE) in the field during
installation. The application determines the actual control algorithm that reads
network variable inputs, makes calculations based on some level of intelligence, and
writes network variable outputs.
Applications in LonWorks devices are divided into one or more functional blocks,
which are collections of network variables and configuration properties that perform
a common task. Network variables that exist in different devices pass data between
nodes using connections called bindings. To be connected, the network variables
must be of the same type, one must be an input, and the other must be an output. The
process of connecting network variables is known as binding.
Pre-Programmed (Configurable) Devices
Simple LonWorks devices have embedded application firmware installed at the
factory. The application typically resides in ROM, but that does not necessarily
prevent a developer from altering the functionality of the device. Using a network
management tool, the developer can change configuration data stored in EEPROM
to modify the operation of the application program.
Programmable Devices
An even greater level of functionality can be realized when the device application
firmware can be downloaded in the field. For these types of devices, the
manufacturer provides simple I/O drivers to interface with hardware attached to the
device and the systems integrator adds custom applications programming by
6–6
Niagara Release 2.3
Chapter 6
Interoperability
Functional Profiles and Application Interface
downloading (to firmware) custom algorithms over the network. Such programmable
devices are typically implemented using flash memory, which provides high density,
non-volatile storage at low cost.
Functional Profiles and Application Interface
Where standard network variable types define the data within network variables, a
higher level of standardization defines functionality for devices (for example, a
thermostat). This level of standardization is referred to as a functional profile.
Device manufacturers use profiles to make public the network variables,
configuration properties, default behavior, and power-up behavior for the devices
that they manufacture.
Profiles standardize functional behavior, not products, and no matter who
manufactures a complimentary LonMark device, the two devices will be able to share
data. Moreover, interface to the device becomes more predictable and consistent.
The standards for developing an interface to an interoperable device application are
contained in the LonMark Application Layer Interoperability Guidelines. The
guidelines are based on functional profiles (implemented as LonMark objects) that
describe in detail the external interface of the node to the network. The interface
includes some combination of the node object (also referred to as node object zero),
specialized LonMark objects that are defined by functional profiles, generic
LonMark objects, configuration properties, and LonTalk file transfer protocol.
Components of an application interface may include the following:
•
•
•
•
•
•
•
Node Object Zero
Data Transfer
LonMark Objects
Device Documentation
SNVTs (Standard Network Variable Types)
Non-Standard Network Variables and Explicit Messages
Node Object Zero: This optional object can be used to report status of objects
within the node. It also includes network variables and configuration properties
relating to the node as a whole.
Refer to
For an in-depth discussion of the Node Object, refer to Section 3 of the LonMark
Application Layer Interoperability Guidelines (078-0120-01C).
Data Transfer: Data logging and monitoring applications can require sending files
between nodes on the network. In addition, some host-based applications as well as
Neuron chip-based applications receive their configuration data in a file. All of these
files are transferred using LonTalk file transfer protocol, which breaks up data files
into 32 byte packets and sends them sequentially.
Niagara Release 2.3
6–7
Chapter 6
Interoperability
LonMark Objects
LonMark Objects: LonMark objects form the basis of interoperability. They
describe standard formats for how information is shared between devices. LonMark
objects are defined as a set of one or more network variable inputs and network
variable outputs (implemented as SNVTs) and configuration properties.
In addition to the node object (object type zero), the are generic object definitions for
a sensor object, an actuator object, and a controller object. These objects can be used
by developers as building blocks to assemble an application layer interface for a
broad range of applications. More specialized object definitions are detailed in the
LonMark Functional Profile documents published by the LonMark Association.
Configuration Properties: Applications developers have a choice of how
configuration properties are set at installation time. They can use configuration
network variables for relatively small changes or they can use file transfer protocol
to download a device when more significant number of changes need to be made.
Using configuration network variables is preferred in that this method provides
self-identification, self-documentation, external interface file support, and simplified
methods for sending and receiving data.
Device Documentation: To support ease of installation, LonMark nodes contain
self-documentation that identifies a number of key pieces of information including:
manufacturer, device type, Neuron ID, the functional profiles supported by the node,
any generic objects used within the device, their object type, and any data type
information related to additional network variables supported outside the standard
objects.
SNVTs (Standard Network Variable Types): Data within a device is converted to
the particular data definition of the SNVT after a raw measurement has been made,
linearized, calibrated, and filtered. This allows specific hardware characteristics to be
hidden from the network and measured values to be shared freely. A master list of
SNVT definitions is available from the LonMark Association.
Non-Standard Network Variables and Explicit Messages: Beyond providing an
object-based interoperable interface, a LonWorks node can support a
non-interoperable interface comprised of non-standard network variables and/or
explicit messages. The non-interoperable interface is subject to some constraints,
related primarily to message size, but this feature allows manufacturers to provide
some level of proprietary functionality in their devices if they so desire.
LonMark Objects
As discussed above, a device's profile describes the general application purpose and
the network image of the device—it defines the collection of standard network
variables (inputs and outputs) and configuration properties exposed to the outside
world for the purpose of creating relationships with other devices. The graphical
representation of a LonMark object is shown in Figure 6-2.
6–8
Niagara Release 2.3
Chapter 6
Interoperability
LonMark Objects
All standard network variables and configuration properties are separated into
mandatory, optional, and manufacturer-defined.
Figure 6-2
Input network variables
(NVIs) appear on the left
and show values entering
the object.
Example functional profile (LonMark Interoperability Guidelines).
Input network variables,
including nv#, name and
SNVT type.
Output network variables
(NVOs) appear on the right
and show values exiting
the object.
nv1
The SNVT type of the
NVI/NVO appears below
each nviName and
nvoName.
nv5
nv6
Associated configuration
properties (NCIs) are
shown in the lower section
of the object.
nv7
nviSpaceTemp
Mandatory
Network
Variables
SNVT_temp_p
nviAppliMode
nviOccCmd
SNVT_occupancy
nv3
nv10
SNVT_hvac_mode
nviSetptOffset
SNVT_temp_p
Output network variables,
including nv#, name and
SNVT type.
Object Type and Index
(i.e., Heat Pump: Type 8051)
nvoSpaceTemp
SNVT_temp_p
nvoEffectiveSetpt
SNVT_temp_p
Optional
Network
Variables
Mfg-defined
network variables
and types. May
include proprietary,
non-interoperable
interface.
nc49 - nciSndHrtBt SNVT_time_sec
nc48 - nciRcvHrtBt SNVT_time_sec
nc60 - nciSetPnts
SNVT_temp_setpt
Device Documentation
Manufacturer
Defined Section
Explicit Messages
As illustrated above, a device profile may include the following:
Object Type: Type of object, including the LonMark type number.
Mandatory network variables: These inputs and outputs define the minimum
number of network variables (NVIs and NVOs) that must be defined (using SNVTs)
to make the device LonMark compliant. They define the fewest number of inputs and
outputs that allow the function to perform work. In the case of a thermostat profile,
mandatory network variables might include setpoint, heating stages, cooling stages,
and space temperature.
Niagara Release 2.3
6–9
Chapter 6
Interoperability
Network Variable Typing
Optional network variables: These inputs and outputs expand the functionality of
the device beyond that which is required for LonMark certification. In the case of a
thermostat profile, optional network variables might include fan speed/mode,
occupied/unoccupied, and humidity. If the manufacturer elects to implement optional
network variables, they must use the SNVT data type documented in the profile.
Configuration properties: Configuration data may be defined for various device,
object, and/or network variable properties. These, too, may be subclassed as
mandatory, optional, and/or manufacturer-specific. However, if a manufacturer uses
NCIs, they must be implemented using SNVT data types.
Manufacturer-specific network variables: These network variables are declared
by the manufacturer to support value-added functions for a particular application.
Similar to optional network variables, the manufacturer must use the SNVT data type
documented in the profile, but they have the freedom to customize the network
variable names.
Network Variable Typing
For each LonMark object, its non-configuration network variables are numbered
from zero to n in the node's self-documentation. The numbering provides a means to
differentiate between two network variables (within an object) of the same data type.
The configuration network variables are numbered using the associated SCPT index.
Naming Conventions
Network variables are often referenced using two very different contexts: one by the
programmer developing Neuron-C code and another by the installation technician.
The programmer often uses Neuron-C naming conventions, whereas the installation
technician requires more user-friendly and end-use associated conventions.
Both the programming reference and the end user reference may be determined when
the application is written, if the final use for the node is known. However, when a
node's use is not fixed until installation time, only the programming reference can be
determined. The convention used with programming references for network
variables includes a prefix that identifies its storage class. Network variable storage
classes include the following:
nvi
network variable input
nvo
network variable output
nci
configuration network variable input (EEPROM)
nro
network variable output (ROM)
An example of a programming reference might be:
nviValue Refers to a network variable input stored in RAM with a functional
name of Value.
6–10
Niagara Release 2.3
Chapter 6
Interoperability
Program IDs
Program IDs
A program ID is a unique identifier for the device functionality that is included in a
LonWorks device. Devices that have been certified by the LonMark Association
contain program IDs in a standard format that includes manufacturer, device
functionality, the transceiver type used, and documentation relating to the intended
use of the device. Program IDs are used by network management tools to identify
nodes on the LonWorks network.
Program IDs are 8-byte identifiers (for example: 80:0:C:50:5A:3:4:12) that include:
Format, Manufacturer ID, Device Class, Device Subclass, and Model Number.
Format: A 4-bit value that defines the structure of the program ID. Formats include:
Formats 8 and 10—15 are reserved for interoperable LonMark devices that
have already passed a certification review.
• Format 9 is reserved for devices that have applied for but not passed a
certification review. These devices are typically in development, prototype, or
field test.
•
Manufacturer ID: Identifies the manufacturer of the device using their assigned
manufacturer number. Manufacturers are assigned an ID when they join the LonMark
Association. Manufacturers that do not yet belong to the association can use ID zero.
Device Class: Device class is drawn from a pre-defined registry of class definitions
that indicate the primary function of the device. If a new device class is needed, the
manufacturer can apply to the LonMark Association.
Device Subclass: Device subclass is drawn from a pre-defined registry of subclass
definitions within a given device class. Device subclass indicates the transceiver type
used and the intended use of the device. If a new device subclass is needed, the
manufacturer can apply to the LonMark Association.
Model Number: Models numbers are assigned by the manufacturer and must be
unique within the device class and subclass for the manufacturer. This model number
does not have to necessarily need to conform to the actual model number used by the
manufacturer.
Niagara Release 2.3
6–11
Chapter 6
Interoperability
Program IDs
6–12
Niagara Release 2.3
CHAPTER
8
The LonWorks service is the hub of LonWorks network management in the Niagara
Framework. The Niagara LonWorks service includes:
The LON Device Manager, used to display status information about nodes on
the network, and to perform device-level network management operations.
• The LON Link Manager, which is used to manage network bindings.
• The LON Utilities Manager, which includes a collection of commands and
utilities for you to query and manipulate the status of nodes on the network.
• LonWorks Service Properties and LonWorks Service Commands used for
network configuration.
•
Device Manager
The Niagara LON Device Manager provides a view to manage LonWorks devices,
including commands to find, commission, replace, match, learn, and upload devices.
The view also displays information about each of the nodes on the network
(including the Niagara station's hosted node, known as the Local LON Device).
The Device Manager is the default view for the LonWorks service—it displays when
you double-click the LonWorks service in the JDE Tree View, or you can select it
from the Go menu (Figure 8-1).
Figure 8-1
Niagara Release 2.3
LON Device Manager.
8–1
Chapter 8
Device Manager
Device Manager View
The LON Device Manager view displays the status of each node found on the
network. From left-to-right, this view includes the following column headings:
status, deviceName, subnet/lonNode, manufacturer, programID, and neuronID.
status: Lists the current device status of each node, described in Table 8-1 below.
Table 8-1
Device statuses.
Status
Meaning
config_online
The device is set configured and on-line. The device is
communicating properly.
unknown
When a shadow object is placed in the station database, its
status is set to 'unknown' until Niagara applies network
management to it.
config_offline
The device is configured, but has been set offline.
device_error
Indicates that Niagara has attempted to communicate to the
device, but that attempt has failed.
comm_error
Indicates that Niagara is talking with the device, but an error
occurred somewhere in the message—some portion of the
message was garbled.
deviceName: This field displays the name of the device for which a shadow object
appears in the station database. The Local LON Device is the name of the local
hosted node to which network variables are bound to the JACE station.
Otherwise, this column displays the name of the shadow object as it was copied out
of the local applications library. Devices that appear without a name indicate that the
LON Device Manager found a device on the network for which an object does not
appear in the station database. The names that appear here can be changed to
something more user-friendly.
subnet/lonNode: Displays the subnet and node addresses assigned to the
device/object by the LON Device Manager.
manufacturer: This field displays the manufacturer of the device, if the information
is known. Otherwise, the column remains blank (or displays 'unknown'). Knowing
the device manufacturer assumes that the node uses self-documentation and the
manufacturer is defined in that documentation. Generally speaking, if there appears
a shadow object in the Niagara library, and we place that object in the station
database, the manufacturer will be known and listed here.
Dynamic devices, which are generic devices that allow us to learn the configuration
of a LonWorks node for which a shadow object is not pre-defined, display their
manufacturer as Tridium and their device name as a dynamic device.
8–2
Niagara Release 2.3
Chapter 8
Device Manager
programID: Program ID is part of the identification of the device and it is where we
learn manufacturer. In addition, it defines the application (profile) of the device.
Program IDs must match (for an actual device and its shadow object) in order for the
LON Device Manager to correctly match the device as part of adding it to the station
database.
neuronID: The Neuron ID of a device is its hardware address. Before network
management is applied to a device, all messaging is done via this address. At
installation time, the LON Device Manager maps a device's Neuron ID, which is
unique to each node, to the corresponding shadow object that appears in the station
database. Once that mapping is complete, all messaging is done via subnet/node
address.
Device Manager Commands
Several buttons appear towards the bottom of the LON Device Manager view
(Figure 8-2). These buttons invoke the various LON Device Manager commands
used to install and maintain the network.
Figure 8-2
Device Manager commands appear as buttons near the bottom of the view.
Status Line can display
information.
Click to open a Status Line History window.
From left-to-right, these command buttons are:
Find, Match, Commission, Replace, Learn, and Upload.
In addition, a Status Line area at the bottom of view provides additional information.
Find
Use this to discover the nodes that are communicating on the network. This assumes
that these devices are not already in the station database. Furthermore, the Find
command assumes the devices are communicating on the zero-length domain.
This command is typically used to do an initial evaluation of the LonWorks network.
It can be used to evaluate whether duplicate subnet/node addresses exist, to account
for the devices on the network, and to determine their status. The Find command does
not affect the station database—it does not add objects to the workspace, it does not
upload configuration data, nor does it attempt to build any control logic.
Match
This command provides the means to match a device found on the network to a
shadow object that appears in the station database. The Program IDs of the two
records must be identical for the objects to be matched. When the LON Device
Manager performs a Match function, it simply places the Neuron ID of the actual
device in the record of the shadow object. The Commission function must be used
to actually apply network management to the device.
Niagara Release 2.3
8–3
Chapter 8
Device Manager
Commission
The Commission function applies network management to a LonWorks node. This
function clears out all of the network variables (configuration data) that may be
stored in the device, it clears the network address table, which specifies all the
bindings it has to other devices, and it applies the domain table to the device. The
domain table defines the subnet/node address and the domain on which the device is
communicating.
Note
When you “Commission” a device, the LON Device Manager applies the
zero-length domain. If the working domain is something different, that gets applied
too. But, Niagara will always apply the zero-length domain to the devices it finds on
the wire. It is possible to have devices assigned to different domains on the same wire
and they will not conflict.
The Commission function is often used in conjunction with the Match command.
However, it is possible to commission a device manually. To do so, select the device
in the LON Device Manager view and click Commission. A dialog box will prompt
you for Neuron ID. You can type it in if you know it; you can scan it in using an
infrared scanner to scan the barcode on the device label; or, you can select it from the
drop down list that is displayed in the dialog box for nodes whose Program IDs
match. You can also pin the device by clicking on the SvcPin button in the dialog and
have the Neuron ID automatically filled in by pressing the service pin on the device
that you are adding.
Replace
This function is used to replace a node that is not functioning properly. In order to
replace a down device, you must give the new node the personality of the one that is
being replaced. The Replace function copies all of the configuration data that is in the
shadow object down in the new controller along with its binding information and
domain table, which provides the new node with the subnet/node address and domain
length of the replaced node. The only thing that gets changed (in the shadow object)
is the Neuron ID—it takes on the address of the new device.
The replace process looks like this:
Learn
8–4
1.
Replace the hardware device.
2.
Use the Find function to find the new Neuron ID.
3.
Match the matching devices (Program IDs)—match the new device to the
shadow object that previously existed in the station database.
4.
Select the node to be replaced and click on the Replace button.
5.
Select the appropriate Neuron ID to be written to the shadow object.
The Learn function performs three primary operations. First, similar to the Find
function, Learn searches the LonWorks network and finds devices that are
communicating on the wire. Next, it matches the Program ID of each device with that
of a corresponding shadow object found in the Niagara object library. Program IDs
define a device's feature set and are unique for each device. The Niagara object
library includes manufacturer-specific shadow objects for each device that has been
Niagara Release 2.3
Chapter 8
Link Manager
integrated into the Niagara Framework. If a device is found for which a shadow
object does not exist, the Learn function can create a dynamic device and configured
it with the configuration data and self-documentation that is uploaded from the actual
device. Lastly, the Learn function creates a new container under the LonTrunk
container, named LonTemp, and places the LonWorks shadow objects into that
container.
The Learn function is used to learn a network of devices that was established with
some other network management tool (for example, LonMaker or Icelan-G). It is
assumed that LonWorks rules have been adhered to and proper network management
principles have been followed. The Learn function is not intended to resolve
duplicate subnet/node addresses or other irregularities.
The Learn function is typically followed by an Upload, which uploads configuration
properties and binding information for the learned node.
Caution
Upload
If you perform a Learn, then follow it with a Commission (and not an Upload), all
binding information is lost.
The Upload function performs two operations. It uploads the Neuron database from
an actual LonWorks device to its corresponding shadow object and creates links that
represent bindings between nodes. Optionally, the Upload function can be used to
upload configuration data from a node.
The Upload function displays a dialog that includes a number of check boxes that
allow you to select to upload binding information, lock existing bindings, add links,
and upload configuration data. Where the Learn function populated the LonTemp
container with shadow objects for each LonWorks node that was found, the Upload
function uploads all the binding information and configuration data found in the each
of those devices and establishes the links between the devices.
Status Line
A status line is displayed at the bottom of the view, which displays responses to
commands issued by the LON Device Manager. A more complete, historical view of
commands and their responses can be displayed in the Status Line History pop-up.
Link Manager
The Niagara LON Link Manager provides a view to manage LonWorks network
variable links and message tag links. This utility is:
The binding tool for devices on the LonWorks network.
• Provides information about all of the links to and from LonWorks nodes.
• Provides a method to change the service type for each binding.
• Provides a binding tool for message tags.
•
Niagara Release 2.3
8–5
Chapter 8
Link Manager
Figure 8-3
LON Link Manager.
Link Manager View
The LON Link Manager view displays the status of each linkage between two
LonWorks nodes and/or between a LonWorks node and a shadow object.
From left-to-right, this view includes the following column headings:
status, hubNode and hubNv, targetNode and targetNv, and service
status: Lists the current status of each link, as described in Table 8-2 below.
For more information, refer to “Troubleshooting a LON Device,” page A-11.
Table 8-2
Link statuses.
Status
Meaning
new
A link has been pulled between two nodes, but that link is not
bound. A LonWorks binding has not (yet) been created—entries
have not been made in the address tables of the linked nodes. Use
the Bind command to bind the linkages.
Until a link has been bound, the network variable is merely polled.
obsolete
A link has been deleted, but the address tables in the linked nodes
have not (yet) been updated—the entries in the address tables (on
both sides) still exist.
Use the Bind command to remove these entries.
8–6
unbound
An obsolete link is listed as unbound following a Bind command,
just to verify that the link has been deleted. Click on the Refresh
command to remove the entry from the table.
bound
Reflects a LonWorks binding has been established between two
network variables/nodes.
Niagara Release 2.3
Chapter 8
Link Manager
hubNode and hubNv: The source (sending) node and network variable (Nv). This
is the output side of the link/binding.
targetNode and targetNv: The target (destination) node and network variable (Nv).
This is the input side of the link/binding.
service: Each binding is configurable for service type. The LON Link Manager
implements four basic message service types offered by the LonTalk protocol. These
include critical, reliable, standard, and authenticate, described below.
critical (acknowledged) indicates that the target node needs to acknowledge
the fact that it received a message. The hub node will continue to send a
message until the target node acknowledges receipt of that message. You are
limited to the number of bindings that can be defined as critical because it taxes
the system and it can cause communications difficulties by loading down the
network with communications verification traffic.
• reliable (unacknowledged/repeated) is recommended for messaging that has
been classified as important—if there is a specific need to know that a status
has changed. Reliable messaging sends a message three times. The hub node
sends each message three times and if the target node receives the message, it
simply throws subsequent messages away.
• standard (unacknowledged) is the least reliable message service is
unacknowledged. This is the default service type for a Niagara binding. With
this service, the message is sent one time and no response is expected. The
unacknowledged service is typically used when the highest level of network
performance is needed, network bandwidth is limited, and the application is
not sensitive to the loss of messages.
• authenticate is a security service reserved for secure messaging. When using
authentication, the hub node must identify itself to the target and visa-versa.
This service is rarely used and only in instances when messaging must be
secure.
•
Message Tags
Generally, nodes use network variables to communicate with one another since they
are interoperable and they result in more efficient messaging. However, in some
cases, applications require a different data interpretation model than network
variables can provide. In these cases, nodes construct individual messages and assign
them an address. These are referred to as explicit messages and nodes use logical
input and output ports (message tags) to send and receive these messages.
All LonMark nodes contain a message-in tag, which can be used to receive messages.
In addition, nodes can declare bi-directional message tags that they can use to both
send and receive messages. If message tags are used, the LON Link Manager
displays their status in its view in a fashion similar to that used to display network
variable bindings.
Niagara Release 2.3
8–7
Chapter 8
Utilities Manager
Link Manager Commands
Two buttons appear at the bottom of the LON Link Manager view: Refresh and Bind.
These commands are used to establish LonWorks bindings and refresh the view.
Figure 8-4
Link Manager commands appear as buttons near the bottom of the view.
Status Line can display
information.
Click to open a Status Line History window.
In addition, a Status Line area at the bottom of view provides additional information.
Refresh
This command simply polls the current status of the bindings on the network and
displays that information in the view. If unbound (deleted) links are listed, those are
removed from the view.
Bind
Is used to bind a link between two nodes. When a link is first pulled (prior to
establishing an actual LonWorks binding), that link is polled. Polled variables are
pulled from the source (or hub) node by the target node—the network variable is
requested by the Local LON Device on a timed basis. Bound variables are pushed
from the hub node to the target node.
Polled variables create somewhat of an inefficient messaging scheme and may cause
unnecessary traffic on the wire. This is due to the fact that polled variables are
updated (sent from the hub node to the target node) on a timed basis, whether they
actually change or not. It is more efficient (and has less adverse impact on network
bandwidth) to update network variables only when they change.
Status Line
A status line is displayed at the bottom of the view, which displays responses to
commands issued by the LON Link Manager. A more complete, historical view of
commands and their responses can be displayed in the Status Line History pop-up.
Utilities Manager
The Niagara LON Utilities Manager includes a collection of commands and utilities
that allow you to query and manipulate the status of a node, find nodes on the
network, identify nodes, display node file structures and data structures, discover
more about communications errors, verify binding information, and more.
Generally speaking, to use the Utilities Manager, select the device, select a command
and a sub-command, then execute that command.
8–8
Niagara Release 2.3
Chapter 8
Utilities Manager
Figure 8-5
LON Utilities Manager View.
Select Device
Main Command
Sub Command
Client View
(results)
Execute Command
Utilities Manager View
The LON Utilities Manager view displays a selection box for the devices it finds and
selection boxes for commands and sub-commands (Figure 8-5). The client view
displays status information (results) for the command once it is executed.
Devices
The devices selection list (appearing towards the top of the view), displays a list of
the nodes (that is, Niagara LonWorks shadow objects, local hosted node, and
LonWorks devices) found by the Utilities Manager.
Initially, the list displays only those nodes found in the station database. However,
when you issue a Find command, the Utilities Manager adds the nodes it finds on the
network (even if they are not in the database). Subsequent commands can be issued
to manipulate the status of the nodes on the network for which shadow objects do not
appear in the database.
Use the devices selection list to select the device to which you issue a command.
Command/SubCommand
The commands and utilities supported by the LON Utilities Manager are divided into
primary and secondary categories—the primary category listed as commands and the
subcategory listed as sub-commands.
LON Utilities and Commands
Utilities and commands provided in the LON Utility Manager are representative of
those originally supported by the NODEUTIL program released by Echelon in 1994.
That now unsupported program was a simple DOS-based utility used to diagnose and
Niagara Release 2.3
8–9
Chapter 8
Utilities Manager
configure LonWorks network devices. It was not a network management tool. As a
comprehensive network management and device support environment, the Niagara
JDE provides complete network integration and support of LonWorks networks.
Main commands available from the LON Utility Manager are as follows:
•
•
•
•
•
•
•
•
status
status
find
identify
file
dataStructures
disable Authentication
reports
readMemory
This command is used to display real-time status for a node or to set it online or
unconfigured. The Utilities Manager displays all status information in the node (as
defined by the LonTalk protocol), whether or not it is actually used by the JDE.
To use the status command, first select a device and a sub-command. Status
sub-commands include display, clear, set unconfigured, set online, reset, and find.
display
This command issues a Query Status message to the node. This message retrieves the
network error statistics accumulators, the cause of the last reset, the state of the node,
and the last run-time error logged (Figure 8-6). If the network is saturated, messages
may get lost and transactions fail.
Figure 8-6
8–10
Device status display.
Niagara Release 2.3
Chapter 8
Utilities Manager
Data fields—Data fields in a status, display command include:
Transmit Errors: Number of CRC errors detected during packet reception. These
are often due to collisions and/or noise.
Transaction Timeouts: Number of times that the node failed to receive expected
acknowledgements or responses after retrying the configured number of times. This
may be due to destination nodes being inaccessible on the network, transmission
failures due to noise on the channel, or if the destination node has too few buffers or
receive transaction records to adequately receive a message and send an
acknowledgement.
Receive Transaction Full: Number of times that an incoming packet was discarded
because there was no room in the transaction database. This may be due to
excessively long receive timers or the receive buffers are too few.
Lost Messages: Number of times that an incoming packet was discarded because
there was no application buffer available. This may be due to an application program
being too slow to process incoming packets, insufficient application buffers, or to
excessive network traffic.
Missed Messages: Number of times that an incoming packet was discarded
because there was no network buffer available. This may be due to excessive network
traffic, insufficient network buffers, or to the network buffer size not being large
enough to accept all packets on the channel.
Reset Cause: Indicates why/how the node was last reset: power-on, external reset,
watchdog reset, software reset, or cleared.
Node State: Indicates the current state/mode of the node: applicationless and
unconfigured, unconfigured (but with an application), configured and hard off-line,
configured and soft off-line, configured and bypass off-line, or configured and
on-line.
Version Number: Reflects (or allows the calculation of) the original Neuron chip
firmware version number.
Error Log: The reason for the last error detected by the firmware on the node.
Neuron Chip model: Neuron 3150 or 3120.
Messages received by node: The number of good messages received by the node.
Not all messages are addressed to the node, but it does receive every message on the
wire. The maximum number of message counts is 65,000—once the count reaches
this value, it does not update. If you clear the display, you will see fresh data.
Messages addressed to node: The number of messages received by, addressed to,
and processed by this node.
Messages sent to MAC layer: The number of messages transmitted by this node.
These can include network variable updates, explicit messages, acknowledgements,
retries, reminders, service pin messages, and more.
Niagara Release 2.3
8–11
Chapter 8
Utilities Manager
Retries: The number of retry attempts that were needed to send a message
successfully (before an acknowledgement was received for a reliable message). If the
bandwidth of the network is low, the node should not have to re-send messages. But,
once the bandwidth starts creeping up and there are collisions, the node might have
to re-send messages.
Backlog overflows: The number of times the backlog reached its maximum value
of 63.
Late acks of responses: The number of acknowledgements or responses that
arrived at this node after the transmit transaction had expired.
Collisions detected: The number of CRC errors caused by collisions.
EEPROM lock: If this field is set, the checksummed EEPROM on the node is
protected against memory writes.
clear
This status sub-command sends a message to the node to clear its error counts. After
this is processed, the status display of the node is updated. Repeated issuance of the
display command (following a clear) will show you traffic on the wire.
set unconfigured
In this state, the node’s application is loaded, but configuration data is either not
loaded or deemed to be corrupted due to a configuration checksum error.
If duplicate subnet/node addresses exist, you may intentionally set a node
unconfigured in order to learn the network—the LON Device Manager will not learn
any devices on a network if duplicate addresses exist.
When a device is set unconfigured, it responds to status query messages with its
Neuron ID rather than using subnet/node addressing. Network variables are not
updated while the node is unconfigured and its service LED blinks at a rate of once
per second.
set online
The LON Device Manager (automatically) downloads a node's network image to
EEPROM when the device is added. This contains the address assignments of the
node, the binding information connecting network variables and message tags
between the nodes on the network, portions of the LonTalk protocol, and
configuration data that supports the application program. Once a node's network
image is downloaded, the LON Device Manager sets the node configured and
on-line.
For nodes that appear in the station database, each of their property sheets contain a
flag that can be used to set a node on-line. This command is provided here as a
convenience for those occasions when you need to set a device on-line that does not
appear in the station database.
8–12
Niagara Release 2.3
Chapter 8
Utilities Manager
When the state of a node is configured and on-line, its application is running and its
configuration is considered valid. This is the only state in which messages addressed
to the application are received. The service LED is off in this state.
reset
This status sub-command performs a software reset of the node.
find
The find command is used to discover the nodes that are communicating on the
network. It functions as described for the Find in the LON Device Manager.
Note
You do not need to select a device before using this command—this command finds
all devices (in the station database or not) communicating on the zero-length domain.
Figure 8-7
identify
Devices found by the LON Utilities Manager (command: find)
The identify command is used to identify a node in the field. This can be done in
either of two ways, using sub-commands wink and service pin.
A wink message is sent to a specific node, which causes it to either visually or
audibly identify itself.
• A service pin command sets the LonWorks Utility to wait for a service pin
message. You can then press the service pin on a node to have it identify itself.
•
wink
To use this command, first select a device from the selection list.
Niagara Release 2.3
8–13
Chapter 8
Utilities Manager
Initially, the device list includes only those nodes that exist in the station database. A
find command adds to this list the other nodes it discovers on the network. Use the
wink command to visually (or audibly) identify a node in the field.
service pin
You do not need to select a device in the device list before using this command.
The service pin command causes the LON Utilities Manager to wait and listen to the
network for a node to identify itself. While the LON Utilities Manager is in this
mode, the status bar displays “Waiting for service pin.” When you press the service
pin on a device on the network, the domain table for that node is displayed.
The service pin command is not merely used to identify a node to the LON Utilities
Manager, but in doing so, it polls the node for the domain it is using. If you are having
difficulty finding devices on the wire, use this command to verify that nodes are
communicating on the zero-length domain. If you find that devices are using another
domain length, change the domain ID for the LonWorks service.
Figure 8-8
The Service Pin command displays the domain table of a device.
The default timeout for the service pin wait is 300 seconds (5 minutes). Use the
cancel function to cancel the service pin wait.
Notes
8–14
Service pin time is adjustable as LonWorkService property servicePinWait
(sec). See LonWorksService property sheet (tabs NetMgmt, Engineering).
• On the same property sheet is a servicePinListen property, by default “False.”
While set to “True” and the LON Device Manager View is displayed, when
you press the service pin on a node, its record is highlighted in the view.
•
Niagara Release 2.3
Chapter 8
Utilities Manager
file
There are two ways that configuration data is stored in a node. Most commonly,
configuration data is stored in a block of memory and the node uses standard
LonWorks messaging (that is, network variable updates) to update that data. In this
case, the network variable acts as a memory pointer to the stored data.
In other cases, applications may use a file transfer protocol to download
configuration data to a device. This method is often used when significant number of
changes need to be made or if the node needs to update more than 64 network
variables (the maximum allowed for a hosted node). In this case, a configuration file
is stored in the device and some number of (fixed) network variables handle the file
transfer. If the network management tool finds these network variables, it knows to
use file transfer protocol rather than standard messaging. The file command is used
to display the file structure of a device.
To use the file command, first select a device and a sub-command. Sub-commands
include fileDirectory, configTemplateFile, configValueFile, and “other.”
fileDirectory
If a device supports a file structure, this command displays the directory structure,
version, size, and types of configuration files stored in the device.
Figure 8-9
File structures of the Honeywell W7753A controller.
Two file types might be stored in a node. The first file is known as a template file
and it identifies the layout of the information contained in the value file. The value
file contains the actual configuration data. Tridium often uses template files to
automatically generate class files for manufacturer-specific shadow objects as a part
of providing LonWorks integration solutions.
configTemplateFile
Displays the configuration template file stored in the node.
Niagara Release 2.3
8–15
Chapter 8
Utilities Manager
Figure 8-10
The template file of the Honeywell W7751F controller.
configValueFile
Displays the value file stored in the node.
Figure 8-11
Configuration values stored in the Honeywell W7751F controller.
other
Displays the contents, in hexadecimal format, of a file stored in the node. You must
specify the file number index, as “Filenum” (the default FileNum is 1).
Figure 8-12
8–16
File, other command displays hex dump of selected file.
Niagara Release 2.3
Chapter 8
Utilities Manager
dataStructures
Data structures displayed with this command can show application image and
network image data stored in the device.
The application image is generated by a Neuron-C compiler at the time the
application is generated by the manufacturer and it includes the following.
•
•
•
•
•
•
•
•
•
•
Network variable fixed data and self-identification data
Program ID
Optional self-identification and self-documentation data
Number of address table entries
Number of domain table entries
Number and size of network buffers
Number and size of application buffers
Number of receive transaction records
Input clock speed of the Neuron chip
Transceiver type and bit rate
In a Neuron 3150 chip, the application image is typically programmed into an
external ROM or downloaded over the network to EEPROM or flash memory.
The network image is typically downloaded into on-chip EEPROM when a node is
installed and it includes the following.
A domain table, with an entry for every domain to which the node belongs.
• An address table, with an entry for every network address referenced by the
node.
• A network variable configuration table, with entries for every network variable
defined by the node.
• A channel configuration structure that defines the transceiver interface of the
node.
To use the dataStructures command, first select a device and a sub-command. Data
structure sub-commands include addressTable, domainTable, readOnlyStructure,
configStructure, nvAliasTable, nvConfig, nvValue, and selfDocumentation.
•
addressTable
This table defines the network addresses to which this node can send implicit
messages and network variables. It also defines the groups to which this node
belongs.
The address table consists of up to 15 entries and each entry may be in one of five
formats: group address, subnet/node address, broadcast address, turnaround address,
or not in use. In cases where network variables are linked to a single controller,
subnet/node addressing is used. If network variables are fanned-in or fanned-out, the
node uses group addressing to multicast its message.
Refer to
Refer to Section A.3 of the LonWorks Technology Device Data book for more details.
Niagara Release 2.3
8–17
Chapter 8
Utilities Manager
Note
Links are grouped in the address table such that multiple network variables share
entries. You can learn more about the individual links by looking at the NV
configuration table. Each NV that shares an entry in the address table has a matching
address index in the NV configuration table.
Figure 8-13
The address table in the Honeywell W7750A controller.
Index: Address table index.
Type: Addressing format including group, subnet/node, broadcast, turnaround, or
not in use.
Group/Subnet: Group or subnet number.
Member/Node: Group member or subnet/node number.
Domain Index: Domain length.
Repeat Timer: The interval between repetitions of an outgoing message when
repeated service is used.
Retry Count: The number of retries for acknowledged, request/response, or
repeated service (0—15).
Receive Timer: When the node receives a group message, the receive timer is set to
the time interval specified here. If a message with the same transaction ID is received
before the receive timer expires, it is considered to be a retry of the previous message.
Transmit Timer: This field specifies the time interval between retries when
acknowledged or request/response service is used.
8–18
Niagara Release 2.3
Chapter 8
Utilities Manager
domainTable
This table defines the domains to which the node belongs. It is located in EEPROM
and is part of the network image written to the device during node installation.
Refer to
Figure 8-14
The domain table in the Honeywell W7750A controller.
Index: Each node can belong to up to two domains.
Subnet: This field displays the ID of the subnet to which the node belongs (1—255).
Node: This field displays the ID of the node within this subnet (1—127).
Authentication Key: This field specifies the six-byte authentication key to be used
in this domain for authenticated transactions. This key must match the key of all the
other nodes on this domain that participate in authenticated transactions with this
node.
Authentication is not typically used unless security is an issue. The use of
authentication doubles the traffic on a network—the first two messages communicate
authentication before the actual message is sent.
Domain Length: This field specifies the length of the domain ID in bytes. Domain
length can be zero (blank domain ID), 1 (256 different domain IDs), 3, or 6 bytes.
Domain ID: This is the unique identifier for the domain. Each device on this domain
must use the same ID—it is possible to have every node connected on the same
medium, but separate them into logical networks using different domain IDs.
Niagara Release 2.3
8–19
Chapter 8
Utilities Manager
readOnlyStructure
This structure defines the node identification as well as some of the application image
properties of the node.
Refer to
Figure 8-15
Read Only data structure in the Honeywell W7750A controller.
Neuron ID: This field is a 6-byte ID assigned to the device by the manufacturer of
the Neuron chip and it is unique for each node built.
Model Number and Minor Model Number: Specifies the model (3120 or 3150) of
the device.
NV Fixed Pointer: This field is a pointer to the NV fixed data table.
Read/Write Protect: This bit specifies that parts of the Neuron chip may not be read
from or written to.
Network Variables: This field specifies the number of network variables declared in
the application program running on the node (0—62).
SNVT Structures Pointer: This field is a pointer to the data structure that gives
self-identification information for the network variables.
Program ID: This field contains an 8-byte program identifying information that
includes the following information in the format (fm:mm:mm:cc:cc:ss:ss:nn).
8–20
Niagara Release 2.3
Chapter 8
Utilities Manager
•
•
•
•
•
Format code (f). Format 8 is reserved for devices passing the LonMark
conformance review and format 9 is used for devices with standard program
IDs that have not yet passed the conformance review.
Manufacturer Code (m). Assigned to each manufacturer when they become a
member of the LonMark Association.
Device Class (c). Drawn from a registry of pre-defined class definitions.
Device Subclass (s). Drawn from a registry of pre-defined subclass definitions.
Manufacturer Assigned Model Number (n).
NV Processing Off: This bit specifies that network variable selection is being
performed off-chip in a hosted node.
Two Domains: Specifies if two domains are being used.
Explicit Messaging: Specifies if explicit message addressing is being used.
Address Count: Specifies the number of entries in the address table (0—15).
TX by address: This bit specifies that the node is maintaining a separate outgoing
transaction space for each unique destination address in the address table.
Idempotent duplicate: This bit specifies that the Neuron chip sets the idempotent
retry bit in the application buffer when a request retry is sent up to the
application—like you thought you'd learn what idempotent meant by reading this.
Alias Count: Specifies the number of entries in the network alias table (0—62).
Aliases allow you to link an NV in one controller to multiple NVs in another (single)
controller. Normally, it is allowed to fan out to multiple controllers, but to fan out to
a single controller, requires aliasing.
Message Tag Count: Specifies the number of bindable message tags used by the
node.
Receive Transaction Count: This field specifies the number of receive
transactions.
Application and Network Buffer Size: These fields specify the size of each of the
application and network buffers (0—191 bytes). The actual size of the buffer is listed
with its corresponding field code value in parenthesis (for example: 47 (11)).
Number of Application and Network Buffers: These fields specify the number of
application and network buffers (0—63). The actual buffer count is listed with its
corresponding field code value in parenthesis (for example: 2 (3)).
Note
The number and size of buffers is determined by the application program compiled
and loaded into the device. There must be a balance struck between the amount of
memory used to support the application, versus that which is needed to support
messaging (for example, to reduce lost messages).
Niagara Release 2.3
8–21
Chapter 8
Utilities Manager
configStructure
This table defines the hardware and transceiver properties of the node. The table
resides in EEPROM and portions of it are written by the manufacturer at the time the
device was manufactured and other fields are written when the node is installed.
Refer to
Figure 8-16
Configuration data structure in the Honeywell W7750A controller.
Channel ID: Specifies the channel to which the node is assigned. Channel ID is
different from domain ID. Where domain ID can be used to break a network up into
separate logical networks, joining separate channels (through a router) provides the
means to extend the physical limitations of a single network.
Location: A 6-byte ASCII string describing the physical location of the node.
Comm Clock, Input Clock, Comm Type, and Comm Pin Direction: These fields
specify the ratio between the Neuron chip input clock oscillator frequency and the
transceiver bit rate, the type of transceiver used, and the direction of Neuron chip's
communications port pins.
Preamble Length, Packet Cycle, Beta2 Control, Transmit Interpacket, and
Receive Interpacket: These fields specify the raw transceiver parameters used by
the MAC processor to control the timing of the media access algorithm.
Node Priority: Specifies the priority slot used by the node when sending priority
messages on the channel.
Channel Priorities: Specifies the number of priority slots on the channel (0—255).
8–22
Niagara Release 2.3
Chapter 8
Utilities Manager
Transceiver Parameters: This field forms an array of seven user-defined
transceiver-specific parameters that are loaded into the transceiver when the node is
initialized. These can be used to control the operation of the transceiver.
Non-Group Timer: When the node receives a broadcasted message requiring a
response, the receive timer is set to the time interval specified here. If a message with
the same transaction ID, priority, and source and destination is received (before the
transaction timer expires), it is considered a retry of the previous message and it is
discarded.
Network Management Authentication: Sets network management messages to be
authenticated.
Preamble Timeout: Specifies the maximum time the node will wait for a free buffer.
nvAliasTable
As previously described, aliasing allows you to link a single NV to more than one
NV on multiple controllers. The NV alias table can have up to 62 entries.
Refer to
Figure 8-17
NV alias table in the Honeywell T7780A.
nvConfig
The network variable configuration table (Figure 8-18) defines the configurable
attributes of the network variables in the node. The table is located in EEPROM so
that it can be modified during node installation and is part of the network image
written at installation. The network configuration table can have up to 62 entries.
Niagara Release 2.3
8–23
Chapter 8
Utilities Manager
Refer to
Figure 8-18
Network variable configuration table in a Honeywell W7750A controller.
Direction: Specifies if the network variable is an input or an output.
Selector: Specifies the selector value for each network variable. Selectors are 14-bit
numbers (0—3FFF) assigned by the network management tool during the binding
process to identify connected network variables. Selector values in the range
3000—3FFF are reserved for unbound network variables, with the selector value
equal to 3FFF minus its network variable index.
Address Index: Specifies the index into the address table for this network variable.
The value 15 is used if the network variable is not associated with a table entry.
Multiple network variables may use the same address table index.
Service: Specifies the type of service used to deliver this network variable: ACKD,
UNACKD_RPT, or UNACKD.
Priority: This bit is set if the network variable uses priority messaging.
Authentication: This bit is set if the network variable uses authenticated
transactions.
Turnaround: This bit is set if the network variable is bound to another network
variable in the same node (turnaround messaging is employed).
8–24
Niagara Release 2.3
Chapter 8
Utilities Manager
nvValue
The network configuration value table allows you to verify what is actually stored in
the node versus that which is displayed on the property sheet of its corresponding
shadow object. This allows you to identify any discrepancies.
As shown in Figure 8-19, data is displayed raw (hex data). The communications to
and from the shadow object handles conversion from hex into the user-friendly data
that is displayed on the property sheet—there is code that converts the raw data bytes
and we can use this view to verify that code is acting properly.
Figure 8-19
NV value table in a Honeywell W7750A controller.
Name: This is the descriptive name that we have given the property and its relates
(one-to-one) to status, configuration, and network variable data appearing on the
property sheet for the node.
Data: This is raw hexadecimal data.
Relating NV Configuration Data to a Property Sheet—The raw hexadecimal
data that appears in the NV configuration table can be interpreted and/or verified by
looking at the property sheet for the shadow object that represents that device in the
station database. For more information, refer to Chapter 10, “Niagara LonWorks
Shadow Objects.”
General Tab: The General tab includes generic properties that are common to most
Niagara control objects. The Engineering sub-tab includes properties for node state,
subnet/node address, location, Neuron ID, Program ID, and many of the read only
structures contained in the device.
Niagara Release 2.3
8–25
Chapter 8
Utilities Manager
LonWorks devices can contain individual objects, referred to as LonMark objects,
each with its own set of network variables and configuration properties. In addition,
a standard node object (also known as node object zero) is defined that provides
commonly needed functionality, such as device status, self-test, alarm detection, and
more.
Node Tab: The Node tab includes properties for each network variable input,
output, and configuration parameter for node object zero. The node object is required
if file transfer protocol is used.
Controller Type: The Controller Type tab includes properties for each network
variable input, output, and configuration parameter associated with the profile loaded
in the device. The actual text that appears on this tab reflects device type (for
example: SCCCM, VAV, Type8060, etc.). Three sub-tabs organize data as follows:
Status sub-tab shows value properties that are typically not
user-modifiable—they display real-time status information about the node.
• Config sub-tab shows NCI values that are used to configure the node.
• LonProps sub-tab shows properties for each network variable input, network
variable output, and configuration property (that is, SCPT and UCPT) stored in
the device, as shown in Figure 8-20. Generally, these are listed in numerical
order by type—NVIs in numerical order, followed by NVOs in numerical
order, followed by SCPTs and UCPTs. The numerical order of these properties
is a function of their network variable index (see NvIndex or Ndx in the
headings of the NV configuration table and the NV value table).
•
Figure 8-20
LonProps sub-tab displays configuration values stored in the controller.
Network variable type (see the
SNVT Master List for more details).
Network variable name.
NV Index (relates to
Ndx and NvIndex).
NV Configuration
properties section.
8–26
Niagara Release 2.3
Chapter 8
Utilities Manager
selfDocumentation
Self-documentation is an embedded, network-readable description of a device's
visible attributes. Devices that gain the LonMark logo must provide this capability so
that general purpose network management tools, developed according to
interoperable design guidelines, can be used to install and configure a device without
the need for additional files or documentation.
Self-documentation can be provided for the device's application and each of its
network variables. Manufacturers that include user-defined services and events may
also support self-documentation for those services and their objects and properties.
As needed, the node makes its self-documentation information available to the host
application through properties.
Figure 8-21
Self-documentation stored in the Honeywell W7750A controller.
There are several structures associated with self-identification and
self-documentation. These include:
•
•
•
•
•
Refer to
A fixed size SNVT structure.
A table containing a self-identification descriptor for each network variable.
A self-documentation string for the node.
Self-documentation information for network variables.
Self-identification data for binding and status information.
For an in-depth discussion of self-documentation, refer to Section 5 of the LonMark
Niagara Release 2.3
8–27
Chapter 8
Utilities Manager
disable
Authentication
Authentication is a security service reserved for secure messaging. When using
authentication, the hub node must identify itself to the target and visa-versa. Because
of the overhead that this type of messaging introduces, it is rarely used. When it is
used, it can be configured individually for each network variable as well as for
network management transactions.
The disableAuthentication command can be used to disable authentication for the
selected node, or you can use the same command at the service level (LonWorks
service) to disable authentication for all nodes.
reports
The reports command is used to display network management data for networked
nodes, to display transmit error information, and to discover inconsistencies in the
station database (as compared to what is actually stored inside nodes that are online).
Reports that can be displayed (by sub-command) include:
•
•
•
•
•
netMgmtSummary—Network management summary
programIds—Program ID listing
transmitErrors—Device transmission error report
verify—Device/station database comparison report
networkSummary—Devices, routers, channels, and addresses in use
To use the Reports command, first select a device and then a sub-command.
netMgmtSummary
The network management summary report (Figure 8-22) is a summary of network
linkages, address table entries, and group assignments.
Figure 8-22
8–28
Network management summary view.
Niagara Release 2.3
Chapter 8
Utilities Manager
Network Variable Link Table: For each link, displays its service type, the source
and target of the link, its address table index (0—14), direction, and status.
Message Link Table: Displays link information for each message tag (if used).
Group Table : Displays the group and member assignments for each node.
programIds
The program ID table (Figure 8-23) lists the Echelon device class files that are
supported. The report is specific to an installation—it lists only those JAR files
(modules) that have been installed. It lists each shadow object by name (Class
Name), the device manufacturer (MfrId), and its Program ID.
Figure 8-23
Program ID listing for the class files installed on the JACE controller.
transmitErrors
The transmit errors report walks through all the devices on the wire, samples their
error counts, and displays a summary of that data here. When you run this report, the
service pulls the values from the devices, then turns around and clears the status of
all the devices. That way, you can run the report and wait 15 minutes to see the
number of errors received in that period.
Figure 8-24 shows an example transmit errors report.
Niagara Release 2.3
8–29
Chapter 8
Utilities Manager
Figure 8-24
Transmit errors report.
verify
The verify report (Figure 8-25) walks through all the devices on the wire and
compares the network variable properties found in the shadow object against what it
finds in the device and lists any discrepancies.
Figure 8-25
8–30
Device configuration verify report.
Niagara Release 2.3
Chapter 8
Utilities Manager
networkSummary
The network summary report provides a listing of routers and devices, including
addresses and channels used.
Figure 8-26
readMemory
Network summary view.
This command is used to read directly from the memory of the node. You can specify
a starting memory location in hex (Address) and length (up to 255 bytes). Use
manufacturer-specific device data to map where data is stored in memory.
To use the readMemory command, first select a device from the selection list.
Figure 8-27
Fixed memory structure of Invensys MN200 controller starting at location f000.
Neuron ID can be found in the
first six bytes of the Neuron’s
fixed data structure.
The Neuron fixed
structure is found in
EEPROM and it
includes Neuron ID,
model number,
authentication key,
and more.
Niagara Release 2.3
8–31
Chapter 8
LonWorks Service Properties
Status Line
A status line is displayed at the bottom of the view that displays responses to
commands issued by the LON Utilities Manager. A more complete, historical view
of commands and their responses can be displayed in the Status Line History pop-up.
The LonWorks service property sheet provides a view to customize and tune the
service in support of a particular LonWorks integration. Some of the features that can
be configured on the property sheet include the following.
Generic timing properties used to control processing between nodes.
• Temperature conversion.
• Configuration properties and statistical data relating to network variable
updates, querying device status, and network management.
•
General Tab
All services have the same basic timing characteristics and these provide generic
timing properties used to control processing between nodes.
Status
Properties
averageInterCycleDelay (ms): The amount of time in between successive
executions of the LonWorks service. Since the service does not have any inputs or
outputs, this statistic is relatively meaningless.
lateStarts: The number of times that the intercycle delay time exceeded cycle time
(the service started execution late).
Config
Properties
Engineering
Properties
temperatureUnits: Temperature units are the only units that Niagara allows you to
modify. The LonTalk protocol measures all values in SI units, therefore, temperatures
are measured in degrees Celsius. With this property set to Celsius, no temperature
conversion is performed—the value coming off of the wire is assumed to be in
degrees C. If set to Fahrenheit, any SNVT defined as a temperature is converted.
Manufacturer-specific network variables are not converted—it is assumed that the
manufacturer measures and displays those in the units that are required by the
application.
In general, exceptions always show up in the Standard Output window when a
service makes a request and an error results. In addition, the Engineering debug
function monitors for some specific messages as described below.
linkDebugOn: Displays all send and receive messages from the LonWorksService
in Standard Output.
8–32
Niagara Release 2.3
Chapter 8
debugOn: Displays requests and responses to and from a node when issued a
command. Engineering debug information is displayed in the Standard Output
window as the result of a fetch, upload, download, dump, read property, and others.
Caution
Debug functions should only be enabled while you are troubleshooting a specific
problem. Each debug function may introduce significant overhead that can result in
service/station processing delays. When finished troubleshooting, disable debug.
Figure 8-28
Standard output window showing network variable updates (debugOn).
Poll Tab
Polling a device for network variable updates, querying a device for its status, and
network management are all independent processes—each maintains its own thread.
As a result, each process has its own configuration properties and keeps track of its
own statistical data. The Poll tab is used to configure and monitor the performance
of network variable updates.
Status
Properties
These statistics relate to polled values only. Any value not bound to the station (that
is, unbound links and bindings between nodes that are not linked to the local LON
device), is a polled value.
averageExecuteTime: Total execution time/execution cycles—the average time it
takes to process all of the values in the poll list. Polling can be disabled on the Config
tab. This value is in milliseconds—see the Note below.
Niagara Release 2.3
8–33
Chapter 8
Note
After about 25 days of operation, the averageExecuteTime and totalExecuteTime
(below) may appear as negative, due to a “roll-over” condition. This does not affect
the operation of the LonWorksService or its polling mechanism.
totalExecuteTime: Total time the service has been running, in milliseconds.
executionCycles: Total number of times the poll list has been processed since the
service has been running.
overruns: The number of times the execution time has exceeded the cycle time—it
took longer than the defined cycle time to process all of the values in the poll list. In
a situation where all links are bound, there are very few items in the poll list, therefore
overruns kept at a minimum.
objectCount: Total number of values in the poll list.
startTime: Date and time the service (that is, station) was started.
interNodeDelay (ms): This statistic reflects the most recent polling sample. It is the
time between fetching values in the poll list and is a function of the number of values
to be polled, cycle time, and the time it (actually) takes to process messages. During
the next polling sequence, the service waits this amount of time between processing
values.
Config
Properties
cycleTime (ms): The amount of time allowed for the service to complete a pass of
the poll list.
displayDots (P): All services provide this feature to display a character in the
Standard Output window to indicate that its thread is still alive.
disabled: Enables and disables this thread.
DeviceStatus Tab
own statistical data. The Device Status tab is used to configure and monitor the
performance of query status messages.
Status
Properties
These statistics relate to device status—actual field hardware performance.
deviceStatusAverageExecuteTime (ms): Total execution time/execution cycles,
meaning the average time it takes to query all of the devices on the network. Device
status ping can be disabled on the Config tab.
deviceStatusTotalExecuteTime (ms): Total time the service has been running.
8–34
Niagara Release 2.3
Chapter 8
deviceStatusExecuteCycles: Total number of times the device list has been
queried.
deviceStatusObjectCount: Total number of nodes in the station database.
deviceStatusStartTime: Date and time the service (that is, station) was started.
Config
Properties
deviceStatusPingDelay (ms): Time delay in between checking each node in the
station database. With a 1000ms ping delay, the service waits one second between
querying nodes on the network.
deviceStatusDisplayDots (1): All services provide this feature to display a
character in the Standard Output window to indicate that its thread is still alive.
deviceStatusDisabled: Enables and disables this thread.
Alarm Setup
Properties
If a node does not respond to a ping (status query) or a network variable update after
the third attempt, the node marks itself as being down. On the next poll cycle, if the
node responds, it marks itself as up. Late responses are marked as overruns.
notificationClass: The notification class for LonWorks device status alarms. This
allows you to route LonWorks device errors to a separate alarm recipient, if needed.
Netmgmt (Network Management) Properties
own statistical data. The Network Management tab is used to configure and monitor
the performance of network management messages.
Engineering
Properties
The Netmgmt tab is used to configure and monitor the performance of network
management messages.
disable: Should always be left at False (default). Only set to True if the JACE is not
the LonWorks network manager, but acting as just another LonWorks device.
servicePinListen: Default value is False. While set to True, you can pin a device in
the field and have it identified in the Device Manager view—the node becomes
highlighted if it appears in the view. The device does not need to exist in the station
database for it to be identified in this way.
addNodeOnMatch: Default value is False. If set to True, provides an acceleration
feature that automatically adds a node when a match is performed.
Niagara Release 2.3
8–35
Chapter 8
verifyDirection: Default value is True. It is possible for a manufacturer to define
network variables in such a way as to have their orientation backwards (that is, NVIs
defined as outputs and visa-versa). This feature allows you to disable verification of
network variable direction (set to False) to correct that problem, which would then
allow the station to learn and/or commission that device.
If you attempt to learn a device and an error is returned, set this property to False,
learn the device, then set this property back to True and then commission the device.
This feature is especially useful when using the dynamic device object to learn a node
for which a device-specific shadow object does not exist.
setDeviceUnconfigOnRemove: Default value is False. If set to True, when you cut
a LonWorks shadow object from the workspace, it sets the actual field device to
unconfigured.
netmgmtDebug: In general, exceptions always show up in the Standard Output
window when a service makes a request and an error results. In addition, this debug
function monitors for some verify specific messages including those encountered
whenever network management messages are sent (bind, add, dump, and others).
Figure 8-29
Caution
8–36
Standard output showing network variable updates (netmgmtDebug = True).
Enable network management debug only when you are troubleshooting a specific
problem. It represents significant potential overhead that can result in service/station
processing delays. When finished troubleshooting, disable debug.
Niagara Release 2.3
Chapter 8
linkDescriptors: Communications parameters for the four service types associated
with network variable bindings: critical, reliable, standard, and authenticate. When
you select a service type for a link, Niagara applies these timers by default—they are
pre-configured in accordance with timing recommendations for LonWorks devices
as defined by Echelon.
Note
Under normal circumstances, do not modify these values.
For a description of these services and timers, refer to “Communications Services,”
page 5-7, and “Timers,” page 5-9.
domainID: Allows you to change the domain length and ID for the Local LON
Device. If domain length is set to zero, there is no ID. Domain length can be set to 0,
1, 3, or 6, which indicates the number of characters used for the ID. By default, the
working domain for Niagara is zero (0).
channelPriorities: The total number of channel priorities reserved.
channelId: If channel priorities are used, this is the identifier of the priority slot
reserved for this node.
authKey: Authentication Key. If authentication is used (enabled if the authenticate
property is True), all authentication uses this key. All nodes must use the same
authentication key to receive and respond to messages from the LonWorks service.
authenticate: Default value is False. Set to True only if using authentication.
routedNetwork: Default value is False. True if routers exist on the LON network.
temporaryBridge: False (and unavailable) whenever routedNetwork is False. If a
routed network, set to True if you want the JACE to act as a LonWorks bridge.
servicePinWait (sec): Default value is 300 seconds. Specifies the time period that
the LonWorks service listens (waits) for a service pin message, during a related
function (such as Commission or Replace) from the Device Manager. After this
timeout period, the LonWorks service ignores any received service pin message.
You may wish to adjust this upwards if it takes a while to physically reach a node to
push its service pin, after issuing a service pin action (SrvPin).
LonComm Tab
lonCommDebugOn: In general, exceptions always show up in the Standard Output
window when a service makes a request and an error results. However, when you
enable this debug feature, verbose messaging is displayed for each transaction
between the local LON device and nodes on the network.
Figure 8-30 shows example Standard Output while the property lonCommDebugOn
is set to True.
Niagara Release 2.3
8–37
Chapter 8
LonWorks Service Commands
Figure 8-30
Caution
Standard output showing NV updates (lonCommDebugOn = True).
Enable this debug function only when you are troubleshooting a specific problem. It
results in significant overhead that can produce service/station processing delays.
When finished troubleshooting, disable debug.
The Commands menu for the LonWorks service includes the following:
•
•
•
•
•
dump
bind
find
enAuth (Enable Authentication)
disAuth (Disable Authentication)
dump
The dump command is used to dump debug data about the LonWorks service to the
Standard Output window, including the service’s swid, handle, name, parent,
properties, and links. It is typically used only during development or troubleshooting.
bind
An alternate means of binding links between nodes. Performs the same operation as
the Refresh command on the LON Link Manager view.
8–38
Niagara Release 2.3
Chapter 8
find
Equivalent to the Find command within the Device Manager.
enAuth
Enable authentication. Enables authentication for all nodes on the network (sets the
LonWorksService property “authenticate” (Netmgmt, Engineering tabs) to True.
disAuth
Disable authentication. Disables authentication for all nodes on the network (sets the
LonWorksService property “authenticate” (Netmgmt, Engineering tabs) to False.
Niagara Release 2.3
8–39
Chapter 8
8–40
Niagara Release 2.3
CHAPTER
9
Niagara LonWorks Tree
Structure
This chapter explains the tree structure used in a Niagara station to support a
LonWorks integration. The following main sections are included:
•
•
•
•
•
Introduction
LonTrunk Container
LocalLonDevice (LLD)
LonTemp Container
Local Library
Introduction
The LonWorks service is typically selected when you initially create the station, but
it can be added later (after the station exists). By selecting the LonWorks service as
you create the station, the LonTrunk container and local LON device are selected by
default. The LonTrunk container is the parent container in which all LonWorks
device objects reside and the local LON device represents the hosted node (LON
adapter) in the JACE controller.
If the LonWorks service needs to be added to an existing station, a copy of the service
can be found in the local library in the \lonworks\services container. Copy the service
to the services container and restart the station. Copies of the LonTrunk container and
local LON device can also be found in the local library in \lonworks\containers and
\lonworks\devices.
LonTrunk Container
The LonTrunk container is automatically added when you select the LonWorks
service as you create the station. The shadow objects for all LonWorks nodes and the
local LON device must reside in this container. You can build whatever container
structure you need under this container, but ultimately each node must reside under
the LonTrunk container.
Niagara Release 2.3
9–1
Chapter 9
The ultimate purpose of the LonTrunk container is to build a hierarchy that will
(someday) support multiple LonWorks adapters in a single JACE controller. This
feature is not supported today, but when it is, each container will (presumably)
support a different LonWorks adapter, identified numerically by a property for the
container object, each supporting 126 nodes.
Most LonWorks devices are Neuron-based controllers, where the Neuron acts as an
applications processor and a communications device all in one. As such, the control
application runs directly out of Neuron. The LonWorks architecture supports a higher
order design where the node off-loads applications processing to a separate host
processor, using the Neuron only as a communications co-processor. This is referred
to as a hosted node.
In the JACE’s station database, the LocalLonDevice object represents its hosted
node—the Neuron on the LonWorks adapter acts as a communications co-processor,
passing messages between the JACE controller’s JVM and other LON devices.
Figure 9-1
LocalLonDevice provides a software object to which you can link network
variables that are exposed by the Niagara station.
As illustrated in Figure 9-1 above, the LocalLonDevice contains all of the binding
information from LonWorks nodes to and from the station—the node constructs itself
automatically as you make links to standard control objects in the station. Unlike
many other network management designs, bindings to and from the local LON
device are bound (not polled), resulting in much quicker network variable updates.
9–2
Niagara Release 2.3
Chapter 9
Notes
•
Input linkages (those that appear coming into the LLD) represent bindings
from Niagara shadow objects (for instance, LonWorks nodes) to standard
control objects in the station.
•
Output linkages (those that appear coming out of the LLD) represent bindings
from standard control objects in the station to Niagara shadow objects.
•
Bindings between LonWorks devices are not reflected on the local LON
device.
•
Polled values do not show up as exposures on the LLD.
•
Bindings (as opposed to polled variables) result in much quicker NV updates,
but they may also cause excessive network traffic (if the node has a tendency
to chatter).
LocalLonDevice Properties
The property sheet for the LocalLonDevice provides a view to monitor network
variable updates to the local LON device as well as to configure its message service
timers. Some of the features that are available on the property sheet include the
following.
Use the Status Tab to view the real-time status of each bound link to and from
the local LON device.
• Use the Config Tab to define the message service timers for the local LON
device. These timers:
– Determine the maximum amount of time the local LON device waits to
send out a value that has not changed (maxSendTime), and:
– Define the minimum amount of time that must elapse between network
variable updates for values that are changing rapidly (minSendTime).
• Use the Engineering Tab to view network image data for the local LON device.
• Use the Lon Props Tab to view network variable configuration and value
information for each value bound to and from the local LON device.
•
Status Tab
Displays the real-time status of each bound link to and from the local LON device
(Figure 9-2). Structured SNVTs provide drop down views.
Niagara Release 2.3
9–3
Chapter 9
Figure 9-2
Config Tab
Real-time status of each linked NV is shown on the LocalLonDevice Status tab.
Config properties specify timing for writing network variable updates from the
LocalLonDevice—these apply to bound LLD output values only. These properties
have no effect on polled values.
maxSendTime: Specifies the maximum amount of time (in seconds) that the LLD
waits to write an output value—if the value has not changed in this amount of time,
the LLD will send it anyway. Maximum send time ensures that network variable
updates are received by destination nodes (whether they change or not) within the
limits set by that node's receive heartbeat limit.
As an example, if you link a schedule object to an occupancy SNVT on a controller,
that object in the LLD only changes (typically) twice per day; at 8:00am and again at
5:00pm. If the destination object is expecting a network variable update every five
minutes, that device expects to see its occupancy SNVT updated periodically, or it
marks the hub node down and reverts to internal programming. In this case, that
might be unoccupied mode.
To prevent these types of unintended events, it is necessary to periodically update
network variable output values. Echelon suggests that the maximum send time
(sometimes called the send heartbeat) be 1/5 the receive heartbeat. Through
significant testing, though, we have found that if you update network variables 2-3
times per heartbeat time base, you will not experience any troubles. In other words,
if receive heartbeat is set to 300 (sec), set maximum send time to around 100 (sec).
9–4
Niagara Release 2.3
Chapter 9
minSendTime: Restricts the number of network variable updates placed on the wire.
Regardless of the rate at which the network variable is updating, it will only be sent
at this rate. This property prevents the network from being congested by values that
are oscillating at an abnormal rate.
selfDoc: Default value is “&3.0@0; Niagara Server Node.”
Engineering Tab
Engineering properties for the LocalLonDevice include generic performance
statistics (minimum, maximum, and average execution time) as well as network
image data that is typically found in every node.
Use the Engineering tab to view and/or modify the following.
verifySnvtType: This is a throw back to before the existence of the dynamic device,
which allows you to modify SNVT type and name. Default value is True.
nodeState: An alternate means of setting device status (rather than going to the
LON Utilities Manager). Node state can be set to unknown, unconfigured,
config_online, config_offline, applicationless, or hard_offline.
subnetNodeId: Allows you to change the subnet and node address assigned to the
LocalLonDevice by the LON Device Manager, which is 1/127.
Notes
You should never have to change the subnet/node address of the LLD.
• The LonDeviceManager automatically assigns subnet/node addresses to
commissioned devices. Addresses are sequential from 1/1 through 1/126.
•
location: Can be used to store a text string in the device indicating its physical
location. Becomes part of the device's self-documentation.
authenticate: (read-only) Shows if the LON is configured for authentication.
neuronId: Reflects the device’s Neuron ID.
programId: Reflects the device’s Program ID in expanded format (expand control)
including format, manufacturer ID, device class, device subclass, and model number.
deviceData: Expand control shows address table information including address
count and network variable count.
addressTable: Expand control shows node/group/address information used in
binds.
Niagara Release 2.3
9–5
Chapter 9
LonTemp Container
Lon Props Tab
The Lon Props tab displays network variable configuration and value information
for each network variable and configuration property bound to and from the
LocalLonDevice. Each binding provides a drop down view.
Use the LON Properties tab to view and/or modify the following.
NV Type: Use this information to look the network variable type up in the SNVT
Master List.
Receive Heartbeat: See the previous discussion of maximum send time to
understand how this property is used to ensure timely network variable updates are
transmitted and received. If this property is set to zero, the local LON device does not
expect periodic updates of its linked inputs—it simply waits until the value changes.
Replacing a Deleted LocalLonDevice
If the LocalLonDevice gets deleted from the station, simply go to the local library
and copy that device into the LonTrunk container and re-add the device in the LON
Device Manager. After adding the device, bind its links.
LonTemp Container
The LonTemp container is automatically created by the Learn command. The Learn
command searches the LonWorks network and finds the devices that are
communicating on the wire. Next, it matches the Program ID of each device with that
of a corresponding shadow object (or dynamic device) in the Niagara object library
and places those objects in the LonTrunk container. Move these objects (and their
links) to appropriate containers to establish the logical or physical tree structure that
you desire for the station database.
9–6
Niagara Release 2.3
Chapter 9
Local Library
Local Library
Figure 9-3
Local Library and manufacturer-specific shadow objects (londevices).
Key components of the local library (for example, d:/niagara/r2.3.01.327/), are:
Archived stations (/stations)
• Core control objects (/tridium)
• Foreign devices (/tridiumx)
•
The /stations container stores a copy of each Niagara station database that has been
created. The /tridium container stores a copy of each of the core runtime components
of the Niagara software suite. And, the /tridiumx container contains the foreign
device libraries for all third party devices that can be integrated into the Niagara
Framework, including LonWorks.
Lon Devices
Folder
The londevices folder contains individual jars for each manufacturer of LonWorks
devices. Each jar includes a docs folder that stores various HTML documents that
make up Niagara's on-line documentation set for that integration. In addition, these
containers include manufacturer-specific shadow objects that have been customized
to operate with known LonWorks profiles and conversion objects that are
node-specific.
lonworks JAR
The lonworks JAR contains copies of the core, non-manufacturer-specific Niagara
objects that can be used to support LonWorks integrations. The following containers
can be found under the lonworks JAR.
containers: Includes a copy of the LonTrunk container. Typically, the LonTrunk
container is added as you create the Niagara station, but it can be added afterward.
Also included are copies of a LonBundle, LonChannel, and LonContainer.
Niagara Release 2.3
9–7
Chapter 9
Local Library
conversion: Includes generic, easy-to-use objects that filter data into and out of
LonWorks devices that use structured SNVTs. Many manufacturers implement their
LonWorks solutions using structured SNVTs, which combine multiple pieces of data
into a structure that must be broken down into primitive data before it can be used
effectively. Niagara's LonWorks conversion objects perform this work—they
multiplex and de-multiplex those structures.
An example use of a demux object is the use of the SnvtSwitchDemux objects, which
breaks down a SNVT switch structure into its component parts. Therefore, you could
link a network variable output (of type SNVT switch) from any LonWorks device to
the input of a SnvtSwitchDemux and read its primitive outputs (value and state) as
individual values.
devices: Includes a dynamic LonWorks device object (DynamicDevice) and a copy
of the LocalLonDevice object. A DynamicDevice is a generic LonWorks node that
can be used to extract controller-resident data dynamically. Use this object to
represent any LonWorks device for which a manufacturer-specific shadow object has
not already been created (stored in a JAR under the Lon Devices Folder).
When you create a new station and select the LonWorks service, both a local LON
device and a LonTrunk container are created. The local LON device represents the
Echelon (LON) adapter in the JACE controller station. All other LonWorks shadow
objects must reside in the LonTrunk container. The capacity of the JACE controller
is 126 physical nodes. The local LON device allows us to bind between the LON
adapter and network variables in the LonWorks devices on the wire. The purpose for
this is to establish a relationship between real-time data at the fieldbus level and
control (or graphical views) running in the JACE.
docs: Contains all of the HTML files that make up the documentation set and
on-line help for the Niagara LonWorks service. Included in this container are files
that document generic shadow objects, conversions, and pertinent services.
services: Contains a copy of the LonWorks service. Typically, the LonWorks
service is added as you create the Niagara station, but it can be added afterward. Just
remember to restart the station after adding any service.
9–8
Niagara Release 2.3
CHAPTER
10
Niagara LonWorks Shadow
Objects
Manufacturer-specific shadow objects have been created to obtain
manufacturer-specific data from LonWorks controllers. They are customized to
operate with known LonWorks profiles and conversion objects that are
node-specific. Shadow objects have been created for each manufacturer-specific
device that has been integrated into the Niagara Framework and are located in the
library under \tridium\londevices. If a shadow object does not exist for the device that
you are integrating, extract the external interface file (.xif) and submit it to Tridium
so that a shadow object can be created.
Shadow Object Properties
Each shadow object has a number of different configuration properties depending on
its profile, but there are some properties that are relatively common, at least among
controllers for one particular vendor.
Properties are organized under the following main property sheet tabs:
General Tab
• Node Tab
• Controller Type Tab
•
General Tab
The General tab includes generic properties that are common to most Niagara control
objects including object type, execution frequency, and password permissions. In
addition to these, the Engineering sub-tab includes properties for node state,
Niagara Release 2.3
10–1
Chapter 10
Figure 10-1
General engineering properties.
Node Tab
The Node tab includes properties for each network variable input, output, and
configuration parameter associated with node object zero (the standard node object
that provides commonly needed functionality, such as device status, self-test, alarm
detection, and so on).
Controller Type Tab
The actual text that appears on this tab reflects device type (for example, SCCCM,
VAV, RTU, Type8060, etc.). This tab includes properties for each network variable
input, output, and configuration parameter associated with the profile loaded in the
actual field device for which this shadow object is representing in the station
database.
Sub-tabs under the controller-type tab include:
Status Tab
• Config Tab
• Lon Props Tab
•
10–2
Niagara Release 2.3
Chapter 10
Status Tab
Displays value properties that are not typically user-modifiable. These properties
display real-time status for each network variable (Figure 10-2).
Figure 10-2
Config Tab
Real-time status of each NV in the controller can be found on its Status tab.
Displays NCI values that are used to configure the node (Figure 10-3).
Niagara Release 2.3
10–3
Chapter 10
Figure 10-3
NCIs can be found on the controller's Config tab.
Some of the more popular configuration properties include:
Send Heartbeat: (nciMinOutTime) This is the maximum amount of time (in
seconds) that the device waits to write an output value—if the value has not changed
in this amount of time, the device will send it anyway. Send time ensures that NV
updates are received by destination nodes (whether they change or not) within the
limits set by that node's receive heartbeat limit. Commonly, this is set to 75.
Receive Heartbeat: (nciRcvHrtBt) This is the minimum amount of time (in
seconds) that the device waits to receive an input value—if the value has not updated
in this amount of time, the device assumes the hub node is down and marks it as such.
Receive time ensures that critical network variables are being updated on a timely
basis. Commonly, this value is set to 300.
Various other NCI configuration properties: Depending on the device, these
properties may define display characteristics, setpoint limits, temperature units,
input/output hardware, modes of operation, calibration data, and more.
Note
10–4
You can pretty much count on send heartbeat and receive heartbeat timers being set
to consistent values across controllers from the same vendor. But, if you have a mix
of different vendors, you need to look through them and tune their timers (with those
of the local LON device) to ensure that you don't cause nuisance alarms or create
communications problems for your network.
Niagara Release 2.3
Chapter 10
Shadow Object Commands
Lon Props Tab
Displays properties for each network variable input, network variable output, and
configuration property stored in the device.
Figure 10-4
LON Props tab displays SNVT types for all network variables.
Some of the more popular configuration properties include:
NV Type: Use this to look up the network variable in the SNVT Master List.
Receive Heartbeat: Compare this to the same property found on the Config Tab.
Polled or Locked: Allows you to specify a binding as either polled or locked.
Other: This view also displays priority slot, NV direction, selector number, service
type, authentication, and other configuration structures.
The Commands menu for a LonWorks shadow object includes the following:
•
•
•
•
•
•
fetch
upload and download
dump
enableCmd and disableCmd
wink
readProperty
Niagara Release 2.3
10–5
Chapter 10
fetch
Refreshes all of the network variables (NVIs and NVOs) in the shadow object from
information it finds in the node. The fetch command does not get NCIs.
upload
Takes what is in the controller and loads it into the shadow object—all the network
variables and configuration data.
download
Writes configuration data from the shadow object (in the station database) to the
device in the field
dump
The Dump command is used to dump the configuration properties for the object to
the Standard Output window. See Figure 51 for an illustration of how to use the
Dump command.
reset
Performs a software reset of the node.
enableCmd
Enables the device in the station database—opposite of the Disable command.
disableCmd
Disables the device in the station database and turns the object (on the workspace) to
cyan. The shadow object no longer updates—values are not pushed from the shadow
object to the device, nor are they pulled from the device to the shadow object. It
doesn't mean the device is not working in the field. It simply means the control engine
is no longer paying attention to it.
wink
Winks the device in the field.
readProperty
Similar to the Fetch command, but reads a single variable.
10–6
Niagara Release 2.3
CHAPTER
11
Niagara LonWorks Dynamic
Device
The purpose of the LonWorks dynamic device is to integrate foreign nodes for which
we have not yet customized an object. When you add or learn a network that has a
device for which we do not have a (pre-configured) shadow object, Niagara uses the
dynamic device to learn that hardware. The dynamic device has the ability to read the
self-documentation of a controller, then take on the personality of that device.
The following main sections are in this chapter:
When Using the Dynamic Device Object
• Dynamic Device Properties
• LON Schema Manager
•
When Using the Dynamic Device Object
When you use the dynamic device object, there are a few things to be aware of.
The dynamic device is very communications intensive. It takes up a lot more
RAM and processor time than does a regular shadow object. Use it only to
learn a device for which a LonWorks shadow object does not already exist.
• You may experience problems completely learning a device when there is a
great deal of traffic on the network—if messages are getting lost. If this
happens, simply delete the dynamic device and re-add it.
• Once the device is learned, you can go to its property sheet and view all of its
network variables. If you do not care for the nomenclature used in the
self-documentation (variable names), you can change them with the LON
Schema Manager. You can even re-type network variables—change their data
type.
•
Niagara Release 2.3
11–1
Chapter 11
Dynamic Device Properties
Dynamic Device Properties
When you learn a LonWorks device using a dynamic device object, that object takes
on the personality of the node. The tabs that appear on its property sheet reflect the
type of device that was learned and the properties that appear on those pages reflect
the profile loaded into the actual device (assuming the manufacturer has used
self-documentation to properly document the configuration of the device).
Other than the subtle differences that may result from generically learning the device,
the property sheet of the object looks and feels identical to that described for a
LonWorks shadow object.
LON Schema Manager
Once a device is learned using a dynamic device object, you can go to its property
sheet and view all of its network variables. If the manufacturer has not provided
effective naming of the network variables or if the vendor has improperly defined
network variable types (in self-documentation), you can use the LON Schema
Manager to redefine those values.
To use the LON Schema Manager, select the dynamic device on the workspace, then
right-click Go > LonSchemaManager.
Figure 11-1
11–2
The LON Schema Manager view.
Niagara Release 2.3
Chapter 11
LON Schema Manager
Double-click a variable to change its name (for instance, nviSatLevelDiscrete
to Damper Position).
• You can also change network variable type, because sometimes what is in the
self-documentation does not match what is actually in the controller.
For instance, Circon allows you to change SNVT type, but their tool does not
change the self-documentation of the controller—the result is that we
incorrectly learn SNVT type (based on the self-documentation). Therefore,
once we learn a Circon device, we may need to go in and alter SNVT type for
network variables that have been changed.
•
•
If you have links to the dynamic device, you cannot edit SNVT type.
LonSchemaManager Commands
The buttons at the bottom of the LON Schema Manager view include the following:
LearnNv
• Save
• Open
• Update
•
LearnNv
Learns the controller-resident value each network variable stored in the controller
and overwrites that value in the shadow object.
Save
Creates a separate, customized dynamic device using the changes (in name and type)
that you have made to the current object. This object can be used in the future to learn
similar nodes.
Open
Opens a previously saved dynamic device object.
Update
Saves the changes (in name and type) that you have made to the current
object—when you return to this property sheet, the changes that you have made will
be used.
Niagara Release 2.3
11–3
Chapter 11
LON Schema Manager
11–4
Niagara Release 2.3
CHAPTER
12
Building Niagara LonWorks
Solutions
This chapter provides the following main sections:
General Information—The two general approaches for engineering a Niagara
LonWorks solution.
• Planning Network Organization—This section addresses determining the
physical needs of the control system and planning the hierarchical structure of
the network database.
• LonWorks Network Installation—This discussion provides an introduction to
using a network management tool to install LonWorks nodes including
addressing nodes, binding network variables, and configuring a node for a
particular network application.
• Network Installation Scenarios—Installation procedures for each of the two
general scenarios (new site and existing LON network).
•
General Information
In general, one of two approaches is taken when building a LonWorks solution with
the Niagara Framework. Either:
1.
Add LonWorks devices (from the local library of LonWorks shadow objects) to
the station database, using the LonWorks service to install and apply network
management to a network of newly installed devices.
2.
Or, use the LON Device Manager to learn the configuration of a network of
previously installed devices—devices that have had network management
applied to them using some other network management tool.
Niagara Release 2.3
12–1
Chapter 12
Planning Network Organization
Prior to installing LonWorks nodes, some planning is in order. The first order of
business is to determine the physical needs of the control system including
identifying field devices and organizing them into some physical or functional
groupings—perhaps by location or equipment type. These groupings will likely drive
the hierarchical structure of the Niagara station database as well as the number and
flow of graphical views that make up the user interface to that database.
The following engineering topics apply:
Determine Network Requirements
• Determine Station Database Structure
• Guidelines for Structuring a LonWorks Database
•
Determine Network Requirements
Before designing a network, you need to determine your network requirements.
These requirements can be identified by answering the following questions.
What sensors, actuators, and controllers are needed to accomplish the tasks that
need to be done?
• What physical devices can be used to drive these sensors, actuators, and
controllers?
• Which devices will reside on which channels (that is, JACEs)? If there are a
limited number of LonWorks devices, this may not be an issue—a single JACE
controller may provide sufficient power/control. However, if the requirements
dictate that multiple area controllers provide supervisory control and global
data management of a vast network of LonWorks devices, you will need to plan
a distributed control system.
Group the LonWorks devices according to some physical or logical structure
(no more than 126 nodes per JACE) and identify the global data passing and
supervisory functions to be performed at the area controller.
•
12–2
Note
Although a limit of 126 devices per JACE controller is recommended, the limiting
factor relates more to bandwidth utilization than it does number of devices. The
LonWorks FTT-10 transceiver supports communications at 78 Kbps. Regardless of
the number of nodes, it is recommended that bandwidth utilization not exceed 25%.
Refer to
For an in-depth discussion of network installation, refer to Section 7 of the LonMark
Niagara Release 2.3
Chapter 12
Determine Station Database Structure
Once you have defined the device requirements of the control network and the
supervisory functions that are needed, plan the hierarchical structure of the station
database. This structure can be defined by answering the following questions.
•
•
•
•
•
How will devices and control logic be organized into subsystems?
What devices need to share information through network variables?
How do control system objects need to be configured such that they correctly
read values (from sensors), perform necessary calculations, and write their
outputs (drive actuators and other controlled devices)?
Do proprietary application programming tools need to be used to program or
configure devices before network management is applied to them?
Will you be connected (on-line) to the physical network when designing and
developing control logic? Will you have access to live data to test control logic
or will simulated values be required?
Guidelines for Structuring a LonWorks Database
Although you are free to structure the station database in virtually any fashion that
you desire, there are some guidelines that will help you manage your station database
more effectively. These guidelines will also help you in creating future Niagara
solutions by allowing you to re-use portions of databases as you move forward.
All LON objects must reside under the LonTrunk container, but other than that,
you are free to arrange your database any way you wish.
• To facilitate ease of re-use, you may want to organize both logic and graphical
objects under a common container. For instance, construct a 'VAV1' container
under the LonTrunk container that contains two other containers, one for the
logic (VAV1Logic) and another for the graphic (VAV1Graphic).
• With this arrangement, you can select the VAV1 container and save it away as
an .sns file (to the local library) for future repeated use. When you save the
container, it saves all of the configuration that you have created, plus it
preserves all of the links between the objects, both within the logic and graphic
containers as well as between the two containers.
• This approach is very effective in building an engineering library from which
you create jobs, and you always have the option to move the graphic container
out for the end-user and place it in a separate container of graphic displays as
you build the job.
•
Niagara Release 2.3
12–3
Chapter 12
Customizing a LonWorks device to give it a unique network personality involves
specifying and loading certain pieces of configuration information. The tasks for
managing this configuration information include addressing the node, binding
network variables, and configuration. How and when configuration properties are
assigned depends upon the specific needs of the job and the tools that are used.
Addressing a Node
Nodes communicate with one another by sending messages. A node's address
identifies it to the network so it can send and receive messages. A node's network
address consists of three components: the domain to which it belongs, the subnet
within that domain, and the node's ID within the subnet. Each node can have up to
two network addresses, one for each domain to which it belongs. The logical address
of a node is unique to the network and the responsibility for assigning the address
belongs to the network management tool used to install the node.
The process of assigning an address to a node is nothing more than pairing a physical
node with a logical network address. The association is made at installation time
using the Neuron ID of the node. There are three methods for extracting a Neuron
chip's unique Neuron ID: Service Pin, Find and Wink, and Manual Entry.
Service Pin
Each LonWorks device has a switch known as a service pin. When the service pin is
grounded, the Neuron chip broadcasts a message containing its Neuron ID and
program ID. Although the method used to ground the service pin varies from device
to device, most manufacturers attach the pin to a push button.
Typically, the service pin is used to identify the device when addressing it. A service
pin message can be sent as frequently as required—it has no lasting affect other than
to send a simple broadcast message that can be heard by all other nodes on the
LonWorks network.
Find and Wink
When the service pin of a device is out of reach, it may be more practical to use the
find and wink method for addressing the node. With this method, the network
management tool searches the network for unconfigured nodes. If more than one
uninstalled node is found, the network management tool uses the LonTalk wink
network management message to identify the device. Depending on the application
programmed into the device, the wink message causes the device to differentiate
itself, usually by flashing a status LED in a particular way or be displaying a service
code. This way an installer can identify the device (in the field) that is responding to
the wink command.
Manual Entry
Another method for pairing a physical node with a logical network address is to
manually enter the node's Neuron ID. The actual process of entering the ID may
mean the installer must type it into an entry field on a configuration screen, or some
manufacturers provide device labels that include a barcode that contains the Neuron
12–4
Niagara Release 2.3
Chapter 12
ID. As each node is installed, the installer reads the ID of the device, enters it into the
appropriate configuration property, then peels the label from the device and places it
on a set of plans, which identifies the device (by location) on a floor plan.
Binding Network Variables
Physically attaching nodes to the transmission medium and assigning them addresses
does not specify how they communicate and share information with one another. In
a LonWorks network, all interoperable communication between nodes is done using
network variables. The type, function, and number of network variables in each node
are determined by its application.
Network variable updates are typically sent using implicit messages, where the
Neuron builds and sends network variable updates using data contained in tables in
its EEPROM. Binding is the process of setting up these tables. The implicit
addressing established during the binding process is called a connection and the
network management tool is responsible for establishing the binding and allocating
the network resources used by the connection.
There is an alternative to implicit messages. In some cases, nodes construct
individual network variable update messages and assign addresses to them. These
messages are known as explicit messages.
Network
Variable
Selectors
There are two pieces of information that the Neuron uses to process and qualify a
message as an incoming network variable update. The first is the address to which
the message is being sent—the node only processes messages that are addressed to
it. The second is the network variable selector in the message. If the node determines
that the message is addressed to it, it checks to see if the network variable selector in
the message matches a network variable selector on the node.
Selectors are 14-bit numbers assigned by a network management tool during the
binding process to identify connected network variables. Nodes may use different
names to identify network variables, but all NVs in a connection must have the same
network variable selector value—each network variable can have only one network
variable selector. Network variable selectors can occur up to two times in any
node—once for an NV output and once for an NV input. This lets the node uniquely
identify each network variable. This does not mean that network variable selectors
need to be unique in the network; any selector can be used multiple times in the same
network as long as the nodes using it do not have any connections in common.
Configuration
Configuration is the process of customizing a node for a particular network
application. This includes setting both network and application related properties.
Network related properties might include communications services, priority, and/or
authentication. Application related configuration properties might include setpoints
and other operational parameters that are programmed using either configuration
network variables or standard network configuration parameters (SCPTs).
Niagara Release 2.3
12–5
Chapter 12
Network Installation Scenarios
There are two general scenarios used when designing and installing a network using
the Niagara Framework:
Using the Niagara LonWorks Service to Establish LON Nodes for a New Site.
• Using the Niagara LonWorks Service to Learn an Existing LonWorks Network
The first procedure is used when you are establishing a network of LonWorks devices
on a new site, the other is used when you are walking onto an existing site where a
network of LonWorks devices has already been installed using some other network
management tool.
•
Using the Niagara LonWorks Service to Establish LON
Nodes for a New Site
Once you have defined the requirements of your system and planned the structure of
the JACE station database, follow these steps to establish a network of LON nodes
for a new site.
Note
This procedure creates a station database on the local machine. You must copy the
station database (directory) to the JACE controller, then start the station.
Procedure 12-1
Establishing LON nodes for a new site.
Step 1
Using the WorkPlace Pro software, create a JACE station and enable the Niagara
LonWorks service. Add a LonTrunk container and a Local LON Device.
Step 2
Create a new container under the LonTrunk container.
The new container will house the LonWorks devices on the network. A good
organization is to create a tree structure that allows for the grouping of controllers
and associated logic by mechanical equipment function, security zone, energy
management function (for example, logging), and so on. It is also a good idea to keep
separate containers for both logic and graphic displays grouped together under the
same parent container. This arrangement facilitates efficient linking between control
logic and associated graphic displays. It also provides a manageable package that can
be stored as a module for future use.
Step 3
To the Logic container, add the LonWorks shadow objects that you need.
Manufacturer-specific shadow objects are located in the library under
\tridium\londevices. If a shadow object does not exist for the device that you are
integrating, extract the external interface file (.xif) and submit it to Tridium so that a
shadow object can be created. An alternative to using a manufacturer-specific
shadow object is to utilize the dynamic device located in the library under
\tridiumx\lonworks\devices. The dynamic device is a generic Lon device object that
learns the self-documentation of a controller and allows you to edit the names and
types of its properties (using the LON Schema Manager).
12–6
Niagara Release 2.3
Chapter 12
Step 4
Create connections between each object that needs to share data.
Select the network variable(s) that need to be connected for each device. Also select
the appropriate Service Type for the link(s). If the data types of the values that need
to pass data are incompatible, check the library under
\tridiumx\lonworks\conversion or the manufacturer-specific device folder (where
you located the shadow object) for a data type conversion object that supports the
link.
Step 5
Apply Niagara's network management to the device.
The Neuron ID must be identified for each device that is to be added to the station.
There are two methods to identify the Neuron ID of a node.
Find and Match. Once all of the physical devices on the LonWorks network have
been found (using the LonWorks service Find function), they can be matched with
their corresponding shadow objects. This procedure updates the shadow object with
the Neuron ID of the actual LON device. Once you have matched the device to its
shadow object, it can be added to the station database and placed on-line.
Commission. Once all of the physical devices on the LonWorks network have been
found (using the LonWorks service Find function), they can be added manually.
Manually commissioning a node requires the user address the node (assign the
Neuron ID of the physical device to the shadow object representing that device). As
previously discussed, the Neuron ID of the device can be provided in one of three
ways. First, if you know the ID, you can simply enter it by typing it on the keyboard.
Otherwise, you need either scan the UPC label on the device or press its service pin.
Step 6
Once the objects(s) have been commissioned, you must bind the links that have been
pulled between them (using the LON Link Manager).
Step 7
At this point, you would typically continue by creating a graphical representation of
the control logic that has just been added by developing a separate graphic container
and linking real-time values to the objects that are contained therein.
Using the Niagara LonWorks Service to Learn an Existing
LonWorks Network
Once you have defined the requirements of your system and planned the structure of
the JACE station database, follow these steps to learn an existing network of
LonWorks devices.
Note
This procedure creates a station database on the local machine. You must copy the
station database (directory) to the JACE controller, then start the station.
Procedure 12-2
Step 1
Learning an Existing LonWorks Network.
Using the WorkPlace Pro software, create a JACE station and enable the Niagara
LonWorks service. Add a LonTrunk container and a Local LON Device.
Niagara Release 2.3
12–7
Chapter 12
Step 2
Create a new container under the LonTrunk container.
The new container will house the LonWorks devices on the network. A good
organization is to create a tree structure that allows for the grouping of controllers
and associated logic by mechanical equipment function, security zone, energy
management function (for example, logging), and so on. It is also a good idea to keep
separate containers for both logic and graphic displays grouped together under the
same parent container. This arrangement facilitates efficient linking between control
logic and associated graphic displays. It also provides a manageable package that can
be stored as a module for future use.
Step 3
Using the LonWorks service Find function, find the LON devices on the network.
Review the list of devices. If there are any duplicate subnet/node addresses, do not
use the LON Device Manager to learn the network. Use Appendix 3 to resolve
duplicate addresses before proceeding.
Step 4
If there are no duplicate subnet/node addresses, use the LonWorks service Learn
function to learn the devices on the network. This process creates a shadow object
for each node that the LON Device Manager finds on the network.
Step 5
Upload each device's binding information and configuration data.
Step 6
Steps 4 and 5 (automatically) created and build out a new container located under the
LonTrunk container. The new container is named LonTemp and it houses all of the
shadow objects (and their links) that were learned by the LON Device Manager.
Move these objects (and their links) to appropriate containers to establish the logical
or physical tree structure that you desire for the station database.
Note
Do not copy and paste LON shadow objects from one container to
another—existing bindings will be lost. Use the Move function.
Moving objects assumes that one or more target containers exist. Create a tree
structure as described in step 2 and move the shadow objects in the LonTemp
container to appropriate targets.
Step 7
12–8
At this point, you would typically continue by creating a graphical representation of
the control logic that has just been added by developing a separate graphic container
and linking real-time values to the objects that are contained therein.
Niagara Release 2.3
CHAPTER
13
User Interface
This chapter contains the following main sections:
General Information
• Building a User Interface
•
General Information
In terms of building a user interface around control logic that uses LonWorks devices,
the following are statements of fact.
The Niagara object model (this is, LonWorks shadow objects and dynamic
devices) provides a common object model used to represent LonWorks
controllers and their configuration data.
• LonWorks is implemented using enumerations and data structures, which are
composites of mixed data, rather than using primitive values. As such, one
network variable from a LonWorks node may include state and value (for
example, SNVT_switch is a structured network variable).
• In Niagara, we break structures into primitive values using what is referred to
as a demux. The inverse is also true—we use multiplex objects to construct
data structures from primitive values when we want to ship data to a controller.
Together, muxes and demuxes are referred to as conversion objects.
• Conversion objects can be found in the local library. Both generic and
manufacturer-specific objects exist, which can take huge structures of
manufacturer-specific network variables that are assembled into very long data
streams of hex values and break down that data into individual primitive
values.
•
Building a User Interface
At a minimum, user interface to a commercial control system includes the ability to
view real-time data and issue control commands. As such, a graphical user interface
would require that those functions be supported.
Niagara Release 2.3
13–1
Chapter 13
User Interface
The following example uses a Honeywell T7780A thermostat and an Invensys
(Siebe) MNL-20 controller to illustrate the use of Niagara control objects to build a
user interface around a LonWorks control application.
This example is broken into three separate steps:
Create the Necessary Logic for Passing Data
• Create the Necessary Logic to Expose Values and Status
• Create the Necessary Logic to Push Commands
•
Create the Necessary Logic for Passing Data
Figure 13-1
Link Properties dialog box showing the creation of a LonWorks link.
Passing data from one node to another is accomplished visually within the workspace
editor, using Procedure 13-1.
Procedure 13-1
13–2
Create the Necessary Logic for Passing Data.
Step 1
Simply right-click on the first node, choose Link and click on the second node.
Step 2
Choose from the Link Properties dialog box, the SNVTs you want to send and
receive the data. Both SNVTs must be the same type, but do not have to have the
same name.
Niagara Release 2.3
Chapter 13
User Interface
Create the Necessary Logic to Expose Values and Status
Use the following features to expose real-time data.
Figure 13-2
Control logic to build a user interface around a LonWorks application.
Text box displays Boolean
value after conversion object.
Run the BinaryOutput through
the conversion object before
linking it to the MNL-20.
Text box displays space temperature.
In this example, exposing space temperature is simple.
Procedure 13-2
Create the Necessary Logic to Expose Values and Status.
Step 1
Make a direct link from nvoSpaceTemp to the binding property of a GxText object.
Step 2
Use a SnvtLevDiscToBoolean conversion object to take the Lon data type level
discrete to a primitive data type of Boolean.
When building an application that will support graphics, all Lon specific data types
must be converted to one of the primitive data types (Float, Boolean, Integer) for use
with the “Gx” graphics objects.
Niagara Release 2.3
13–3
Chapter 13
User Interface
Create the Necessary Logic to Push Commands
Use the following features to push control commands into the LonWorks controller.
Procedure 13-3
Step 1
Create the Necessary Logic to Push Commands.
Use the network variable nviOccCmd (of the MNLRR103) to command the
controller for occupancy/unoccupancy.
However, you cannot directly link in a BinaryOutput object to toggle that variable
active/inactive, because they are of different data types (the BinaryOutput is of type
booleanStatusType and the nviOccCmd is of type LonOccupancyEnum).
Therefore, you need to use a conversion object (BooleanToOccupancy) to convert
one to the other. The BoolToOccupancy conversion object can be found in the local
library \tridiumx\lonworks\conversion.
13–4
Step 2
Create a BoolToOccupancy object that sits between the BinaryOutput and the
MNLRR103.
Step 3
Link the statusOutput of the BinaryOutput to the state input of the conversion object.
Step 4
Link the snvtValue output of the conversion object to the nviOccCmd input of the
MNLRR103.
Step 5
Change the command text from inactive/active to UNOCC/OCC and test the manual
control of the node.
Step 6
Add a Schedule to the workspace and link it to the BinaryOutput for timed control.
Test the automatic operation of the node.
Niagara Release 2.3
APPENDIX
A
Much of the difficulty that you might have in initially communicating with
LonWorks devices may result from very predictable circumstances. Other difficulties
may require more in-depth troubleshooting. This appendix provides a number of
procedures that can be used to troubleshoot network installations in the field and it is
intended for engineers and technicians that are already familiar with basic LonWorks
concepts.
This appendix includes the following sections:
•
•
•
•
•
Resolving Duplicate Subnet/Node Address—If you attempt to learn an
existing network and the LonWorks service detects one or more duplicate
logical addresses, you may need to change the subnet/node address of a device.
Discovering Nodes on Other Domains—If you have difficulty discovering
nodes on the network, it may be that those devices are not communicating on
the zero-length domain—the domain on which the LON Device Manager
looks. Since the LonTalk protocol supports multiple domains, the Niagara
LonWorks service supports the ability to change the domain on which the local
LON device queries for devices.
Devices on Different Domains, But the Same Channel—For devices to
communicate and share data, they must be on the same logical domain. A
procedure is provided to combine devices on different logical networks to be
on the same domain.
Working With Routers—Addresses the enhanced feature set available with
Niagara release 2.1 and higher that supports routers.
Troubleshooting a LON Device—Describes link status errors that may be
encountered in the LON Link Manager view and provides source material that
can be used to troubleshoot LonWorks devices installed on twisted pair
networks.
Niagara Release 2.3
A–1
Appendix A
Resolving Duplicate Subnet/Node Address
Resolving Duplicate Subnet/Node Address
If you attempt to learn an existing network and the LonWorks service detects one or
more duplicate subnet/node addresses, the command will fail. If this is the case, you
have two alternatives:
You can change the subnet/node address of the offending device(s) in your
database to unique addresses (Procedure A-1). (Remember you can only
change the subnet/node address of a shadow object that exists in the station
database). Then when the Learn function is performed, the newly learned node
addresses will not conflict with the existing node addresses.
• Or you can set the node(s) unconfigured that are in conflict with the existing
nodes in your database (Procedure A-2). You then set the Learn function to
ignore unconfigured devices, which will automatically create shadow objects
in the database the remaining nodes. The unconfigured nodes will need to have
their shadow objects manually copied from your local library to your database,
they can then be Matched and Commissioned using the Device Manager.
•
Changing Subnet/Node Address of a Node
This procedure is used to change the subnet/node address of a device so that it does not
match the address of a device that you are attempting to add to the station database.
The Niagara LonWorks service automatically (and sequentially) assigns subnet/node
address to devices as it finds or learns them. If you want to change the address of the
shadow object in the station database, use Procedure A-1.
Figure A-1
Subnet/node address can be changed on the General Engineering tab of the
shadow object once it is added to the station database.
Subnet and node
address can be
changed here.
A–2
Niagara Release 2.3
Appendix A
Discovering Nodes on Other Domains
Procedure A-1
Changing Subnet/Node Address of a Node.
Step 1
Open the property sheet of the object that you want to change. Select the General,
Engineering tab (Figure A-1).
Step 2
Set the state of the node to “unknown” and click Apply.
Step 3
Change the subnetId and the nodeId of the object to the desired address, and click
Apply.
Step 4
Using the LON Device Manager, commission the device. The status of the device
displays config_online.
Step 5
Using the LON Link Manager, re-bind any obsolete bindings.
Setting a Node’s Status to Unconfigured
This procedure can be used to set a node unconfigured for the purpose of learning a
network of devices that have duplicate subnet/node addresses—you can learn a
network and ignore unconfigured devices.
Procedure A-2
Setting a node’s status to unconfigured.
Step 1
Right-click the LonWorksService container to display its tree menu. Click Go >
LonUtilitiesManager.
Step 2
Using the Command drop down box select find, and click Execute, to get an updated
listing of the nodes on the wire.
Step 3
Select the node you want to set unconfigured using the Device drop down box and
highlighting it. Using the Command drop down box select status, and in the
Subcommand drop down box select set unconfigured.
Step 4
Click Execute at the bottom of the screen, the device status will change (an Invensys
node will flash its red led service light once per second).
The LON Device Manager is used to discover nodes that are communicating on the
network. Assuming that devices are not already represented in the station database,
the Find and Learn commands can be used to discover the devices communicating on
the zero-length domain. Once the devices are discovered, they can be added to the
station database.
Adding a device to the station database applies network management to that device.
More specifically, this process clears out all of the network variables that may be
stored in the device, clears its address table, which specifies all the bindings it has to
other devices, and it applies the domain table to the device. The domain table defines
the subnet/node address and the domain on which the device is communicating.
Niagara Release 2.3
A–3
Appendix A
Since the LonTalk protocol supports multiple domains, the Niagara LonWorks
service supports the ability to change the domain on which the local LON device
queries for devices.
If you have difficulty discovering nodes on the network (using the LON Device
Manager), it may be that those devices are not communicating on the zero-length
domain—the default domain on which the LON Device Manager looks. It is easy to
discover on which domain a device is communicating. Simply use Procedure A-3.
If you find that one or more devices are communicating on a domain other than zero,
use Procedure A-4 to change the domain of the LonWorks service so that the LON
Device Manager can find those devices.
Discovering the Working Domain of a LonWorks Device
Procedure A-3
Step 1
In the JDE Tree View, expand the services container and right-click the
LonWorksService. Select Go > LonUtilitesManager.
Step 2
In the Command box, click the down arrow and select Find. Click Execute.
The LON Utilities Manager displays all of the LonWorks devices that it finds on the
working domain. If no devices are displayed, or if you are certain more devices exist
(on the wire) than are being displayed in the view, check the domain table of a device
on the network.
Step 3
In the Command box, click the down arrow and select identify. In the
Sub-Command box, click servicePin. Click Execute.
Step 4
Press the service pin on one of the s devices with which you are having trouble.
The domain table is displayed for the device, which indicates the domain length
(Domain Len) and ID for the device. Figure A-2 shows an example domain table.
Figure A-2
A–4
Discover the working domain for a LonWorks device.
Example domain table for a LonWorks device.
Niagara Release 2.3
Appendix A
Devices on Different Domains, But the Same Channel
If the device is configured to communicate on something other than the zero-length
domain, use Procedure A-4 to change the domain ID of the LonWorks service—the
LonWorks service must be configured to communicate on the same domain as the
devices on the wire.
Changing the Domain ID of the LonWorks Service
Procedure A-4
Changing the Domain ID of the LonWorksService
Step 1
In the JDE Tree View, expand the services container and right-click the
LonWorksService. Select Go > Properties. The property sheet displays.
Step 2
Click the Netmgmnt tab.
Locate the domainId property, click the down arrow, and select the appropriate
domain length. Click Apply.
Step 3
Right-click again on the LonWorksService, selecting Go > LonDeviceManager.
Step 4
Click the local LON device record to select it. With the record highlighted, click
Commission.
The local LON device is commissioned using the new domain length.
At this point, you should be able to repeat the Find operation and find all of the
devices on the LonWorks network. Once you have done so, refer to “Using the
Niagara LonWorks Service to Learn an Existing LonWorks Network,” page 12-7, to
learn and upload configuration data from each device on the network.
If there are devices on the network that continue to give you trouble, you can use the
Lon Utilities Manager to set the device “unconfigured,” which will have the control
engine ignore it.
Devices on Different Domains, But the Same
Channel
For devices to communicate and share data, they must be on the same logical domain.
If, as a part of discovering nodes on a LonWorks network, you come to find that
devices physically share a common channel, but they have been assigned different
logical domains, it is necessary to resolve that situation. Use Procedure A-5 below.
Caution
Do not use the LonDeviceManager’s “Commission” function on devices until
after you have uploaded their configuration data. The Commission command
clears network variables, address table information, which specifies all the
bindings in a device, and applies the domain table to a device. Prematurely
commissioning a device may destroy important configuration data.
Niagara Release 2.3
A–5
Appendix A
Devices on Different Domains, But the Same Channel
Procedure A-5
Resolving different domains and duplicate subnet/node addresses.
Step 1
Using the LON Utilities Manager, find the domain ID of one or more devices on each
domain. Use the Identify command to display the domain table for these devices.
Step 2
Set the domain ID of the LonWorks service to the first logical domain (domain one).
The domain ID assigned by the JACE controller can be found on the property sheet
of the LonWorks service.
Step 3
Using the LON Device Manager, learn all the nodes on domain one and upload their
configuration data. By default, this step adds shadow objects to the station database
for all nodes discovered on domain one (and applies the domain table for the current
domain to those devices).
Make note of the subnet/node addresses assigned to these devices (so you can verify
that duplicate addresses are not used in subsequent steps).
Note
At this point, do not worry with binding network variables. These bindings
will be made obsolete when you apply the new domain table to these devices
in a subsequent step.
Step 4
Change the domain ID of the LonWorks service to that of the second logical domain
(domain two).
Step 5
Using the LON Device Manager, execute a Find command. This step does two
things. First, it lists all the shadow objects that already exist in the station database
(those that were found on domain one). Second, it discovers the nodes that are
communicating on the current domain (domain two). The Find does not add shadow
objects to the station database for devices discovered on domain two, nor does it
change the domain ID of the devices found on domain one.
Check the subnet/node addresses of the devices found on domain two against those
of the devices learned in Step 3.
Step 6
If there are duplicates, proceed to step #10. Otherwise, continue with step #7.
Step 7
If there are no duplicate subnet/node addresses, use the LON Device Manager to
select all of the devices (including the local LON device) that currently exist in the
station database. Click Add. This step applies the domain table (of domain two) to
the selected devices—those that were previously communicating on domain one.
Step 8
Again, using the LON Device Manager, learn all the nodes on the current domain
(domain two) and upload their configuration data. This step adds shadow objects for
the devices found on domain two to those already added from domain one, thereby
combining the two domains.
Step 9
Using the LON Link Manager, execute a Bind command. This step binds existing
network variable linkages and resolves any obsolete bindings (resulting from
changing the domain ID of the devices that were communicating on domain one).
At this point, all devices are combined and communicating on the same logical
domain (domain two). All previous bindings have been properly reestablished. You
are finished.
A–6
Niagara Release 2.3
Appendix A
Working With Routers
Step 10
If duplicate subnet/node addresses exist, you must change the addresses of those
devices on domain one before you can learn the devices on domain two. Make note
of the subnet/node addresses of the devices on domain one that are duplicated on
domain two.
Step 11
Change the domain ID of the LonWorks service to the first logical domain (domain
one).
Step 12
As described in Procedure A-1, modify the subnet/node address of any nodes that
conflict.
Step 13
Repeat Step 4 through Step 9 until all devices have been combined on the same
logical domain, are communicating properly, and their network variables are bound.
Beginning in Niagara Release 2.2, support for LonWorks routers was added. Prior to
this, LonWorks devices had to exist on the same channel as the JACE controller.
The following topics apply to LonWorks routers in Niagara:
About Routers
• Niagara Representation
• Working with an Unmanaged Routed Network
• Working with a Managed Routed Network
•
About Routers
Routers are often used to span different channel (media) types, for example, FTT-10
to TPT/XF-78. They are also used to manage network traffic and increase node
capacities beyond a single-subnet limit.
Note
In a typical Niagara scenario, routers for media bridging (vs. node count increase) are
more common, because the JACE (as the LonWorks network manager), has inherent
limits to the number of nodes it can shadow. Generally, this limit is acknowledged as
126 nodes or less, depending on the number of data items exposed, plus other factors.
Considering this, a Niagara job with hundreds of LonWorks devices typically require
multiple JACE controllers, where each JACE is the network manager for a specific
portion of them. Therefore, the need for LonWorks routers is typically minimal.
Niagara Release 2.3
A–7
Appendix A
Niagara Representation
In a Niagara station, a LonWorks router is represented by three objects, all residing
directly in the LonTrunk container (Figure A-3):
One LonRouter
• Two LonChannels
•
Figure A-3
LonWorks router in Niagara is associated with 3 objects.
LonRouter: Device found in the in the \tridiumx\lonworks\devices folder of the
local library. It has one input (nearChannelId) and one output (farChannelId).
LonChannel: Container found in the \tridiumx\lonworks\containers folder of the
local library. One LonChannel must link to each side of a LonRouter.
The “near-side” LonChannel contains LonWorks shadow objects for nodes
that exist on the near-side (JACE-side) of the router.
• The “far-side” LonChannel contains LonWorks shadow objects for nodes that
exist on the far-side of the router.
•
Depending on the installation scenario (unmanaged network or previously managed
network), you may need to copy and paste these objects from the local library, or they
may automatically be created upon a Learn from the LON Device Manager.
See “Working with an Unmanaged Routed Network” and “Working with a Managed
Routed Network” for example procedures.
A–8
Niagara Release 2.3
Appendix A
Working with an Unmanaged Routed Network
An unmanaged network is typically made up of newly-installed devices. The installer
will know which devices are physically on the near-side and far-side of the router(s).
In the example below, you are beginning with a new station, which contains only the
LonWorksService, and the LonTrunk container with only the LocalLonDevice.
The physical LON network includes 10 unconfigured nodes and 1 router, as follows:
7 of the nodes are on the near side of the router.
• 3 of the nodes are on the far side of the router.
• All nodes are still factory-addressed as Subnet 1, node 254.
•
Procedure A-6
Example procedure to work with an unmanaged routed network.
Step 1
Open the local library, and expand the tridiumx/lonworks JAR, and its subfolders
devices and containers.
Step 2
Copy and paste a LonRouter object into the LonTrunk.
Step 3
Copy and paste two LonChannel containers, also into the LonTrunk.
The LonChannels should show up numbered as Channel 1 and 2.
Step 4
Link LonChannel1 nearChannel to the LonRouter nearChannelID.
Step 5
Link LonChannel2 farChannel to the LonRouter farChannelID. (See Figure A-3)
Step 6
Go the LonDeviceManager and perform a Find.
The result of the Find should show 10 nodes, all on Subnet 1, node 254.
Also, on the LonRouters tab, the LON router should also be listed.
Step 7
On the LonRouters tab, perform a Match with the LonRouter in the station and the
one just found. This copies the router’s Neuron ID into the LonRouter object.
Step 8
Commission the LonRouter you just matched.
Step 9
With the LonRouter selected in the LonDeviceManager, from the menu bar select
Commands > tempBridgeOn. This sets the LonRouter as a temporary bridge.
Step 10
Click Learn from the LonDeviceManager.
a.
Select (check) Unmanaged devices.
b.
Click Apply.
The learn progresses for several seconds.
In the LonDeviceManager, all 10 nodes should appear under the Lon Application
Devices tab, and the LON router should appear under the Lon Routers tab. Because
you selected “Unmanaged devices,” Niagara automatically re-numbered conflicting
node addresses. However, subnet addresses are not re-numbered, and all devices
should appear with a status of “unknown.”
Verify the station has new containers and devices under the LonTrunk. There should
be one LonRouter, one container named Channel1 and another container named
Channel2. All node (shadow) objects are created under the Channel1 container.
Niagara Release 2.3
A–9
Appendix A
Step 11
You must now Move shadow (node) objects that exist on the far-side of the router
from the LonChannel1 container to the LonChannel2 container.
Working in the Tree View, do this with a
a.
Click-and-drag action for each object to be moved, releasing the mouse button
when the cursor is over the LonChannel2 container.
b.
Select Move from the popup dialog. Niagara automatically changes the subnet
of the object to 2 during this process.
Step 12
Repeat Step 11for each shadow object that physically resides on the router’s far side.
Step 13
Go to the LonDeviceManager and verify that the LonRouter is still set to temporary
bridge on. Select the router, and from the menu bar, click Commands.
The drop-down menu should show “tempBridgeOff” (meaning that the temporary
bridge is turned On).
Step 14
On the Lon Application Devices tab, Commission each one of the nodes.
Step 15
On the Lon Routers tab, Commission the router.
Step 16
Set the LonRouter temporary bridge Off.
With the router selected on the Lon Routers tab, from the menu bar, select
Commands > tempBridgeOff.
The LON trunk is now in a managed state.
Working with a Managed Routed Network
A managed network is one that has already been managed with some other LonWorks
network management tool. In this case, you are connecting the JACE and attempting
to learn all the devices as currently configured.
In the example below, you are beginning with a new station, which contains only the
LonWorksService, and the LonTrunk container with only the LocalLonDevice.
The physical LON network includes 10 configured nodes and 1 router, as follows:
7 of the nodes are on the near side of the router, which has been managed as
Channel 1, Subnet 1.
• 3 of the nodes are on the far side of the router, which has been managed as
Channel 2, Subnet 2.
•
Procedure A-7
Step 1
A–10
Example procedure to work with a managed routed network.
Go to the LonDeviceManager and click Learn.
a.
Do not check “Unmanaged devices.”
b.
Click Apply.
The learn progresses for several seconds.
Niagara Release 2.3
Appendix A
Troubleshooting a LON Device
In the LonDeviceManager, all 10 nodes should appear under the Lon Application
Devices tab, and the LON router should appear under the Lon Routers tab. Because
you did not select “Unmanaged devices,” Niagara preserves all current node and
subnet addresses.
Step 2
In the Tree View, expand the LonTrunk container.
Verify that the station has new containers and devices. There should be one
LonRouter, one container named Channel1 and another container named Channel2.
Channel1 should contain 7 devices
• Channel2 should contain 3 devices
•
Step 3
Go to the LonDeviceManager and Commission each of the LON nodes.
Step 4
In the LonDeviceManagere, Commission the LON router.
The LON trunk is now in a managed state.
This section includes two important topics: link status errors and troubleshooting
LonWorks devices on twisted pair networks. The first section addresses the errors
that may be encountered on the LON Link Manager view and suggested steps to take
to resolve each. The second section addresses troubleshooting Neuron-based devices
installed on twisted pair networks.
Link Status Errors
The LON Link Manager displays the status of each linkage between LonWorks
nodes. Link status errors are described in Table A-1 below.
Table A-1
Link Status Errors.
Status
Meaning
AUTH_ERR
Authentication error. Check the messaging service type for the
network variable linkage on the LON Link Manager view.
BOUND
Reflects a LonWorks binding has been established between two
network variables/nodes.
COM_ERROR
Communications error. There were communications errors during
the bind operation (for example, timeouts). Try binding the network
variables again. If errors persist, check communications.
DEV_ERROR
Device error. The state of the node will not support a network
variable binding. Most likely, the node needs to be added.
DUAL_HUB_ERROR
In short, the target of a fan out type link cannot also be the target of
a fan in type link. When a single network variable output is linked to
multiple network variable inputs (fan out), that output is considered
a hub. Also, when a single network variable input is linked to
multiple network variable outputs (fan in), that input is considered a
hub.
Niagara Release 2.3
A–11
Appendix A
Table A-1
Link Status Errors. (continued)
Status
Meaning
GROUP_DIRTY
Typically means there is an address table problem. Usually, a
second pass at a bind will clear things up.
GROUP_ERROR
Unable to assign the node to a group. A node can belong to 15
different groups (up to 15 address table entries) when
acknowledged messaging service is used. To correct this error,
either reduce the number of address table entries or adopt
unacknowledged/repeated messaging service.
LOCKED
Binding is locked. This can be done at the time the node is learned
or a network variable can be locked on the property sheet of the
node.
MAX_CRIT_ERROR
Too many targets (bindings or linkages) are made to use the critical
messaging service. Reduce the number of bindings or adopt a
non-critical massaging service.
MULTIPLE_INS
This is a message tag error. There is a message tag with more than
one input when only one should be used.
NEW
A link has been pulled between two nodes, but that link is not
bound. A LonWorks binding has not (yet) been created—entries
have not been made in the address table of the linked nodes. Use
the Bind command to bind the linkages. Until a link has been bound,
the network variable is merely polled.
NV_TYP_ERROR
SNVT types do not match. Typically, you would use the LON
Schema Manager to change the name and/or data type of a
network variable for a node learned as a dynamic device when the
self-documentation of that node does not properly represent the
actual data stored in that device.
OBSOLETE
A link has been deleted, but the address tables in the linked nodes
have not (yet) been updated—the entries in the address table (on
both sides) still exist. Use the Bind command to remove these
entries.
SERV_TYP_ERR
Message service type mismatch. The message service type found
in the LON Link Manager does not match the actual service type
found in the node.
UNBOUND
An obsolete link is listed as unbound following a Bind command,
just to verify that the link has been deleted. Click on the Refresh
command to remove the entry from the table.
Troubleshooting LonWorks Devices and Twisted Pair
Networks
A future revision of this document may contain this information.
A–12
Niagara Release 2.3
APPENDIX
B
SNVT Reference
This appendix explains LonWorks SNVTs, and includes these main sections:
• Niagara Shadow Objects
• Working With SNVTs
• Converting LonWorks Data Using Program Objects
•
The following subsections are included:
•
•
•
•
•
•
Network Variables
SNVTs
Data Types
Naming Convention
Engineering Units
Working With LonWorks Data
Network Variables
Echelon defines a network variable as a data item that a particular device application
program expects to get from other devices on a network (an input network variable)
or expects to make available to other devices on a network (an output network
variable). Network variables can be any single data item, or they can be data
structures. Examples of network variables may include temperature, switch positions
(binary), or actuator position (analog).
Applications running in LonWorks devices do not need to know anything about
where input network variables come from or where output network variables go.
When the application changes a value, it simply passes the new value to firmware.
Using a process that takes place during installation called binding, the device
firmware is configured to know the logical address of the other devices on the
network—the device is then able to assemble a message and send it to the devices
Niagara Release 2.3
B–1
Appendix B
SNVT Reference
that need the information. In a similar fashion, when the device firmware receives an
updated value for an input network variable needed by the application, it passes that
data to the application.
The binding process creates soft wiring between nodes that represent logical
connections between an output network variable (NVO) on one node and an input
network variable (NVI) on one or more other nodes. A typical node on the network
may have multiple connections, both inbound and outbound. When the application
running in the sending node writes a new value to an NVO, the value is automatically
propagated to the network and received by all nodes that have a bound NVI. In this
way, network variables are continuously updated.
A simple example of soft wiring can be seen in Figure B-1. One node monitors the
position of a switch and exposes that value using the output network variable called
switch_on_off. Another node controls the on/off state of a light bulb. The second
node has an input network variable called lamp_on_off. A binding between
switch_on_off and lamp_on_off, creates a connection between the two devices that
can be used by device firmware that has the same effect as physically connecting a
wire between the switch and the lamp.
Figure B-1
Network variable connection.
Network Variable Updates
Switch
Lamp
Controller
Controller
SNVTs
Network variables and configuration properties of a LonMark profile or object are
implemented using formal LonMark data types called Standard Network Variable
Types (SNVTs). SNVTs facilitate interoperability by providing a well-defined
interface for communication between nodes made by different manufacturers. At
present, there are at least 145 SNVTs defined (version 10.00), each by name and
number, definition (measurement or usage), and range of values.
B–2
Niagara Release 2.3
Appendix B
SNVT Reference
For example, there are SNVTs for sharing temperature, pressure, status, and mode
information. A node can be installed in a network and logically connect to other
nodes via network variables as long as their data types match.
Data Types
Each SNVT is defined as either a scalar value or a structure. A scalar type represents
a single value that is a fixed point number, a floating point numbers, or an
enumeration. A structure is a set of one or more scalar values, embedded structures,
arrays, and/or unions.
The following general data type classifications can be made:
Scalar Types: Fixed Point Numbers (Integers)
• Scalar Types: Floating Point Numbers
• Scalar Types: Enumerated Values
• Structured Types
•
Scalar Types:
Fixed Point
Numbers
(Integers)
The representation for all fixed point numeric SNVTs is as follows:
0—65,535
-32,768—32,767
0—255
-128—127
Unsigned long
Signed long
Unsigned short
Signed short
An example of a fixed point SNVT is:
SNVT
SNVT number Measurement
Data Type
Size
Range
SNVT_temp_p
105
Fixed point scalar
signed long
2 bytes
-273.17— +327.66
degrees C
Scalar Types:
Floating Point
Numbers
Temperature
The representation for floating point SNVTs is ANSI/IEEE 754, which is one sign
bit, eight exponent bits, and 23 mantissa bits (32 bits total). The range of values for
all floating point SNVTs is -1E38 to +1E38.
An example of a floating point SNVT is:
SNVT
SNVT_power_f
57
Niagara Release 2.3
Power
Data Type
Size
Range
Floating point scalar
4 bytes
-1E38— 1E38 watts
B–3
Appendix B
SNVT Reference
Scalar Types:
Enumerated
Values
SNVT
SNVT_occupancy
Some SNVTs have enumerated values, where a single byte represents a value from
an enumerated list.
An example of an enumerated SNVT is:
109
Occupancy
Data Type
Size
Range
Enumeration scalar
1 byte
-1E38— 1E38 watts
Enumeration Definitions (occup_t):
Value
Identifier
Notes
0
OC_OCCUPIED
Area is occupied
1
OC_UNOCCUPIED
Area is unoccupied
2
OC_BYPASS
Area is temporarily occupied for the bypass period
3
OC_STANDBY
Area is temporarily unoccupied
OC_NUL
Value not available
0xFF
Structured
Types
SNVT
SNVT_temp_setpt
Some SNVTs are structured values, meaning they have more than one data field.
An example of a structured SNVT is:
106
Temperature
setpoints
Data Type
Size
Fields
Structure
12 bytes
Occupied_cool
Standby_cool
Unoccupied_cool
Occupied_heat
Standby_heat
Unoccupied_heat
Each of the fields of SNVT_temp_setpts are of type SNVT_temp_p, which are fixed
point scalar. The valid range of each field is -273.17 to +327.66 with a resolution of
0.01 degrees C.
Naming Convention
The naming convention for a SNVT is:
SNVT_name
The above can be extended to indicate data species or other delimiters. For example:
SNVT_name_f
denotes floating point data.
Engineering Units
Most SNVTs use System Internationale (SI) units (in other words, metric units)
rather than their English equivalents. Any necessary conversion from SI units to
English units is performed by logic in the node or via a PC interface.
B–4
Niagara Release 2.3
Appendix B
SNVT Reference
Working With LonWorks Data
This section introduces data types and formats, and how data is stored in and
communicated between LonWorks nodes.
Type Versus
Format
Every network variable and configuration property has an associated data type and
format.
The type specifies the units and structure of the data contained within the
network variable or configuration property.
• The format specifies how the raw data contained within the network variable
or configuration property is translated for display or for use by an application.
The format also specifies how data entered by a user or application is translated
to the raw data to be transmitted on the LonWorks network.
•
The type of a network variable or configuration property is typically fixed for most
devices. However, devices may support network variables and configuration
properties with changeable types as described in the LonMark Application Layer
Interoperability Guidelines. The format of a network variable or configuration
property may include scaling and offset values to convert one type of data to another
such as Celsius to Fahrenheit or kilograms to pounds.
As an example, a temperature sensor may report a temperature value with a type of
SNVT_temp_f. The SNVT_temp_f type is defined as a 32-bit signed floating point
value representing a Celsius temperature with a range of -273.17 to 1E38 degrees. A
value of SNVT_temp_f type may be displayed and entered using one of several
formats including Celsius, Fahrenheit, or differential Fahrenheit (degrees F with no
32 degree offset from zero). The format of a network variable or configuration
property does not affect how the corresponding value is transmitted on the wire.
Each data type has a default format. You can change the format at any time, but if you
change data type, the format is automatically changed to the default format for that
new type
Data Types
Table B-1 below identifies the various data types that might be encountered in a
LonWorks node.
Table B-1
LonWorks Data Types.
Number Category
Character
Niagara Release 2.3
Type
Range
Char
0 to 255 or ASCII character equivalent
Signed char
-128 to +127 ASCII character equivalent
Unsigned char
0 to 255 or ASCII character equivalent
B–5
Appendix B
SNVT Reference
Table B-1
LonWorks Data Types. (continued)
Number Category
Discrete number
How Data is
Represented on
the Wire
Type
Range
Signed int
-128 to +127
Unsigned int
0 to 255
Signed long
-32,768 to +32,768
Unsigned long
0 to 65,535
Signed short
-128 to +127
Unsigned short
0 to 255
Continuous numbers
(numbers with
fractional portion)
Float
-3.4 x 1038 to 3.4 x 1038
Signed 32-bit value
S32 Type
-2.1 x 109 to 3.4 x 109
Although messages are transmitted from one node to another via a series of 1’s and
0’s, network variables are stored in hexadecimal format. The NV value table displays
these values.
Figure B-2
NV value table available in the LON Utilities Manager view.
The data displayed in this table is raw (hex data). The communications to and from
the shadow objects representing the actual nodes on the network handles conversion
from hex into user-friendly data that is displayed in the workspace view—there is
code that coverts the raw data bytes and we can use this view to verify that code is
acting properly.
You can use Procedure B-1 to verify the conversion object is doing its job.
B–6
Niagara Release 2.3
Appendix B
SNVT Reference
Procedure B-1
Verifying data conversion for a network variable.
Step 1
Identify the network variable to be verified and find its NV index. NV index can be
found on the LonProps sub-tab of the property sheet for the shadow object.
Step 2
Display the nvValue table for the node in the LON Utilities Manager view. Locate
the appropriate entry in the table and read its raw value.
Step 3
Convert the hex value to decimal and resolve it for any formatting relating to its
SNVT type.
Figure B-3 illustrates an example for SNVT_temp_p.
Converting SNVT_temp_p to Displayed Engineering Units
SNVT_temp_p has the following characteristics:
Data is signed long (-32,768 to 32,767 integer) with a resolution of 0.01
degrees C.
• The relationship between the raw value and its displayed value is linear with a
given resolution. See the table below.
•
Note
Displayed Value
Raw Value
0
0
0.01
1
0.02
2
0.03
3
...
...
100.0
10,000
All raw temperature values are stored in degrees C and conversion is the
responsibility of the network management tool or user interface.
Niagara Release 2.3
B–7
Appendix B
SNVT Reference
Figure B-3
Converting SNVT_temp_p to displayed engineering units.
Use the Lon Utilities Manager to read the nvValue data structure
for the controller and find the NV index (for example, Ndx 15).
This is the raw value stored in the node and broadcast on the wire.
SNVT_temp_p is signed long with a
range of -273.17...+327.66 degrees C,
with a resolution of 0.01 degrees C.
SNVT index (Ndx) is 15.
Convert hex value A22 to decimal, which is 2594.
With a resolution of 0.01 degrees C, that
represents a value of 25.94 degrees C
(or 78.69 degrees F).
Change the engineering units for displayed
temperature on the LonWorks service property
sheet.
Converting SNVT_lev_percent to Displayed Engineering Units
SNVT_lev_percent has the following characteristics:
Data is signed long (-32,768 to 32,767 integer) with a resolution of 0.005%.
• The relationship between the raw value and its displayed value is linear with a
given resolution. See the table below and Figure B-4.
•
B–8
Displayed Value
Raw Value
0
0
0.005
1
0.010
2
0.015
3
...
...
100.0
10,000
Niagara Release 2.3
Appendix B
SNVT Reference
Niagara Shadow Objects
Figure B-4
Converting SNVT_lev_percent to Displayed Engineering Units
Use the Lon Utilities Manager to read the nvValue data structure
for the controller and find the NV index (in this case, Ndx 4).
This is the raw value stored in the node and broadcast on the wire.
SNVT_lev_percent is signed long with
a range of 0...100 percent, with a
resolution of 0.005.
SNVT index (Ndx) is 4.
Convert hex value 4E20 to decimal, which is
20,000.
With a resolution of 0.005, that represents a
value of 100%, which means full scale.
When used as the output of a two-state device,
the ON state is represented by state = TRUE
and value = 20,000 (100% of full scale).
Manufacturer-specific shadow objects have been created to obtain
manufacturer-specific data from LonWorks controllers. They are customized to
operate with known LonWorks profiles and conversion objects that are
node-specific. Shadow objects have been created for each manufacturer-specific
device that has been integrated into the Niagara Framework and are located in the
library under \tridiumx\londevices. If a shadow object does not exist for the device
that you are integrating, extract the external interface file (.xif) and submit it to
Tridium so that a shadow object can be created.
Niagara Release 2.3
B–9
Appendix B
SNVT Reference
Each shadow object has a number of different configuration properties depending on
its profile, but there are some properties that are relatively common, at least among
controllers for one particular vendor.
General Tab
The General tab includes generic properties that are common to most Niagara control
objects including object type, execution frequency, and password permissions. In
addition to these, the Engineering sub-tab includes properties for node state,
Figure B-5
General engineering properties.
Node Tab
The Node tab includes properties for each network variable input, output, and
configuration parameter associated with node object zero (the standard node object
that provides commonly needed functionality, such as device status, self-test, alarm
detection, and so on).
Controller Type
Tab
The actual text that appears on this tab reflects device type (for example, SCCCM,
VAV, RTU, Type8060, etc.). This tab includes properties for each network variable
input, output, and configuration parameter associated with the profile loaded in the
actual field device for which this shadow object is representing in the station
database.
Properties are grouped across three sub-tabs: Status, Config, and Lon Props.
B–10
Niagara Release 2.3
Appendix B
SNVT Reference
Status
Displays value properties that are not typically user-modifiable. These properties
display real-time status for each NVI and NVO contained in the device.
Figure B-6
Real-time status of each NV stored in the controller is found on its Status tab.
Config
Displays each NCI that is used to configure the node (Figure B-7).
Niagara Release 2.3
B–11
Appendix B
SNVT Reference
Figure B-7
NCIs can be found on the controller's Configuration tab.
Lon Props
Displays information about each network variable and configuration property stored
in the device. This information includes SNVT type and number, index, binding
information, NV configuration table data, and more. Use this tab to discover the
SNVT type for each NV and configuration property supported by the profile of the
subject device.
Figure B-8
B–12
LonProps view of a node.
Niagara Release 2.3
Appendix B
SNVT Reference
Getting Some Help
The JDE provides context-sensitive Help for each LonWorks shadow object
supported in the Niagara Framework. This information can be used to determine the
data type of each property stored in the station (configuration) database. Data type is
particularly important when you are considering linking network variables, for links
can only be made between network variables as long as their data types match.
Context
Sensitive Help
Use the following procedures to learn more about the network variables and
configuration properties stored in LonWorks shadow objects.
Procedure B-2
Viewing context-sensitive Help.
Step 1
Right-click on the shadow object as it appears on the workspace. Click Go >
Properties. The property sheet for the object is displayed.
Step 2
On the menu bar, click Help, then On Context. The node help view is displayed for
the selected object.
Each property is displayed, grouped by tab on the object's property sheet. The
property name (for example, nviSetPoint) is listed in the left hand column and its data
type (for example, FloatStatusType) is displayed in the right hand column.
Figure B-9
Step 3
Context sensitive help for a shadow object.
Click on the data type hyperlink. The index of the Property Reference help file is
displayed (Figure B-10).
Niagara Release 2.3
B–13
Appendix B
SNVT Reference
Figure B-10 Property Reference index.
Step 4
Scroll down to find the data type that you are interested in, and click on that
hyperlink. Context sensitive help for that property is displayed.
Figure B-11 Context sensitive help for data type.
The help view displayed above shows the selected network variable (nviSetPoint) is
of type FloatStatusType, which has two fields: status and value. To create a link from
another object, that link must pass data from a property that is identical (in type).
For instance, to change the setpoint value used by the LonWorks node, link the status
output property (sOut) of an AO object, which is of type FloatStatusType, to
nviSetPoint as illustrated below.
B–14
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-12 Link between properties with matching data types.
nviSetPoint input network variable
exposed on the shadow object for
the Honeywell W7751F controller.
Online
Documentation
In addition to the context sensitive help that is available from the property sheet of a
shadow object, there is a collection of on-line documents embedded in the JDE that
address LonWorks integrations and the Niagara Framework. You can access these
documents in two ways.
Help Files
On the JDE menu bar, click on Help > Index. From the documentation index
(Module Documentation), click on lonworks.
Figure B-13 LonWorks documentation in JDE Help.
Click on lonworks to review the
LonWorks documentation.
Niagara Release 2.3
B–15
Appendix B
SNVT Reference
Local Library
Open the local library and expand the /tridiumx folder to expose the /lonworks/docs
folder. In that folder, you'll find individual HTML documents for (generic)
LonWorks shadow objects, conversion objects, enumerations and data types,
variables, and more.
Figure B-14 Help view for a Dynamic Demux object (tridiumx/lonworks/docs).
.
Manufacturer-Specific Help Files
Open the local library and expand the /tridiumx/londevices folder to expose the
manufacturer for which you wish to learn more. In the folder for each manufacturer
you'll find a /docs folder that contains individual HTML documents for
manufacturer-specific LonWorks shadow objects, conversion objects, enumerations
and data types, variables, and more.
You will also find an overview document that lists each device integrated into the
Niagara Framework (as illustrated in Figure B-15 for Circon devices).
B–16
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-15 General documentation for Circon LonWorks devices.
SNVT Master List
The SNVT Master List is updated periodically as new SNVTs are added.
The document (PDF file) is available on LonMark's website at www.lonmark.org.
Use the link below to download LonMark resource files that include the latest SNVT
Master List. As of this writing, that was version 11.00.
http://www.lonmark.org/products/snvtfile.htm
Figure B-16 shows views that you will encounter as you access the LonMark website
and open/save the resource file zip that contains the SNVT Master List file.
Niagara Release 2.3
B–17
Appendix B
SNVT Reference
Figure B-16 Screen views while accessing the SNVT Master List.
B–18
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Working With SNVTs
This section provides real application examples for dealing with SNVTs—exposing
values and statuses, creating user controls, and otherwise pushing data into or pulling
data out of LonWorks devices. Not all of the SNVTs defined in the SNVT Master List
are covered here, but the vast majority of those that you will encounter in typical
HVAC control applications are illustrated.
Each of the following examples includes SNVT definition data. Some examples
include sample control logic illustrating the GUI needed to expose the variable,
Program object code (where needed) to convert data from one form to another, and
other instructions as appropriate.
The following SNVTs are covered:
SNVT_temp_p
Measures temperature.
SNVT_lev_percent
Measures percent level or humidity.
SNVT_lev_disc
An enumerated list of integer values that represent
discrete status.
SNVT_switch
A structure that can be used to differentiate between the
state of a device and its load.
SNVT_hvac_status
A structure that can be used to monitor and control the
status of a device.
SNVT_hvac_mode
An enumerated list of integer values that represent the
mode of operation of a device.
SNVT_hvac_overid
A structure that can be used to monitor and control the
override status of a device.
SNVT_hvac_emerg
emergency state of a device.
SNVT_temp_setpt
A structure that can be used to display and/or change a
collection of temperature setpoints used by a controller.
SNVT_occupancy
occupancy state of a device.
SNVT_date_time
This SNVT should not be used for new applications.
Use SNVT_time_stamp.
SNVT_time_stamp
A structure that can be used to display and/or change
date and time.
Niagara Release 2.3
B–19
Appendix B
SNVT Reference
Working With SNVTs
SNVT_temp_p
SNVT temperature. Measures temperature.
Type
SNVT_temp_p
Category
Measurement
Range
Index
Signed Long
Temperature
-273.17 ... +327.66
degrees Celsius (°C)
(resolution = 0.01 °C)
105
32,767 value (0x7FFF) is
invalid data
Example control logic may be shown in the next document revision.
Practice Using
SNVT_temp_p
In some future document revision, a practice exercise may be included.
SNVT_lev_percent
Level percent. Measures percent level or humidity.
Type
SNVT_lev_percent
Category
Measurement
Range
Index
Signed Long
Humidity
-163.84% ... 163.83%
(resolution = 0.005)
81
Figure B-17 Example control logic with NV implemented with SNVT_lev_percent.
Mouse over the property tag and find
that the property name is nvoSatPercent
of type FloatStatusType.
SNVT type is SNVT_lev_percent.
View the context sensitive help screen to
see the values of the structured SNVT.
PO converts FloatStatusType to
Boolean to drive the Boolean
graphic animator.
input FloatStatusType sIn
output boolean boolOut
output String strOut
if sin.value> 0
boolOut=true
strOut=”On”
else
Note: An even more efficient method of converting from
FloatStatus type to BooleanStatus type is available by using a
standard Comparison object (rather than a Program object).
boolOut=false
strOut=”Off”
endif
A Comparison object uses less resource counts than a Program
object, plus has “activeInactiveText” for showing the Boolean state.
B–20
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Practice Using SNVT_lev_percent
Create the control logic necessary to manually change the value of outside air
humidity as read by the Honeywell W7750A controller on its NVI.
Note
Use an AO object to set the value.
SNVT_lev_disc
Level discrete. An enumerated list that accommodates integers that have an
enumeration type definition.
Type
SNVT_lev_disc
Category
Measurement
Range
Index
Enumerated
Discrete Level
See Enum List (Table B-2)
22
Table B-2
Enumerations for discrete_levels_t.
Value
Indentifier
Notes
2-state device
3-state device
4-state device
0
ST_OFF
off
off
off
1
ST_LOW
on
low
low
2
ST_MED
on
high
medium
3
ST_HIGH
on
high
high
4
ST_ON
on
high
high
-1 (0xFF)
ST_NUL
Invalid Value
Figure B-18 Example control logic with NV implemented with SNVT_lev_disc.
Mouse over the property tag
and find that the property
name is nvoSatLevDisc1 of
type LonLevDiscEnum.
SNVT type is
SNVT_lev_disc.
View the context sensitive
help screen to see the
values of the structured
SNVT.
Niagara Release 2.3
B–21
Appendix B
SNVT Reference
Working With SNVTs
Practice Using SNVT_lev_disc
Using an Invensys MN-200 controller, create the control logic necessary to make a
Boolean graphic animator switch from inactive to active when the status of the
cooling stage(s) switch from off to on (low).
Notes
Use the variable nvoSatDisc1 to determine the state of the cooling stage(s).
• Use a GxBoolean object to display an active image when the cooling is on
(low) and a different (inactive) image when the cooling is off.
•
SNVT_switch
SNVT switch. A structure that can be used to differentiate between the state of a
device and its load. In other words, can monitor and control a device for position,
speed, or other variable signal as well as its state (enabled or disabled).
Type
SNVT_switch
Category
Measurement
Range
Index
Structure
Switch
See Structure (Table B-3)
95
Table B-3
SNVT_switch structure (data fields).
Field
Measurement
Category
Range
value
Value, percent of full scale
Unsigned Short
0 ... 100 (resolution = 0.5)
state
State
Signed Short
0 ... 1 (resolution = 1)
Figure B-19 Example control logic with NV implemented with SNVT_switch.
Mouse over the property tag
and find that the property name
is nvoSatSwitch1 of type
SnvtSwitchValueType.
SNVT type is SNVT_switch.
View the context sensitive help
screen to see the values of the
structured SNVT.
The exposed property types
include:
FloatStatusType—express
es status as a floating point
value 0—100.
Boolean—expresses status
as a True or False.
LonSwitchStateEnum—
expresses status as an
integer, either off (0), on (1),
or null (255).
B–22
The SnvtSwitchDemux
object is used to
convert the structured
SNVT into its
component values.
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Practice Using
SNVT_switch
Notes
Using a Honeywell W7750A controller, create the control logic necessary to
manually enable/disable the bypass mode of the controller. Monitor that state with a
graphical animator.
•
Use a BO object to enable/disable bypass mode.
•
Use a snvtSwitchMux object to push the command into the controller and a
snvtSwitchDemux object to expose the current state of that variable.
•
Use a GxBoolean object to display an active image when bypass mode is
enabled and a different (inactive) image when the bypass mode is disabled.
SNVT_hvac_status
HVAC status. A structure that can be used to monitor the status and operation mode
of a device. Used in HVAC applications, this structure supports both an enumerated
list (mode) as well as percent level values for heating control, cooling control,
economizer, fan control, and an in-alarm bit. See Figure B-20 for an example.
Type
SNVT_hvac_status
Table B-4
Category
Measurement
Range
Index
Structure
HVAC status
95
SNVT_hvac_status (data fields).
Field
Measurement
Category / Units
Range
mode
HVAC mode
Enumeration
See Table B-5, enums
heat_output_primary
Primary heat output
SNVT_lev_percent
-163.83 ... 163.83%
heat_output_secondary
Secondary heat output
SNVT_lev_percent
-163.83 ... 163.83%
cool_output
Cooling output
SNVT_lev_percent
-163.83 ... 163.83%
econ_output
Economizer output
SNVT_lev_percent
-163.83 ... 163.83%
fan_output
Fan output
SNVT_lev_percent
-163.83 ... 163.83%
in_alarm
Fan output
Boolean
Table B-5
Value
0 ... 1
Notes
—
Each of these
outputs is percentage
of full scale.
1 means unit in alarm
Enumerations for mode in SNVT_hvac_status, SNVT_hvac_mode.
Indentifier
Notes
0
HVAC_AUTO
Controller automatically changes between application modes
1
HVAC_HEAT
Heating only
2
HVAC_MRNG_WRMUP
Heating only
3
HVAC_COOL
Cooling only
4
HVAC_NIGHT_PURGE
Application-specific night purge
5
HVAC_PRE_COOL
Application-specific pre-cool
6
HVAC_OFF
Controller not controlling outputs
7
HVAC_TEST
Equipment being tested
8
HVAC_EMERG_HEAT
Emergency heat mode (heat pump)
Niagara Release 2.3
B–23
Appendix B
SNVT Reference
Working With SNVTs
Table B-5
Enumerations for mode in SNVT_hvac_status, SNVT_hvac_mode. (continued)
Value
Indentifier
Notes
9
HVAC_FAN_ONLY
Air not conditioned, fan turned on
10
HVAC_FREE_COOL
Cooling with compressor not running
11
HVAC_ICE
Ice-making mode
0xFF
HVAC_NUL
Value not available
Figure B-20 Example control logic with NV implemented with SNVT_hvac_status.
Mouse over the property tag and find that the property name
is nvoUnitStatus of type SnvtHvacStatusType.
Use a SNVT demux object of type SnvtHvacStatusDemux to
break down the structured SNVT into its component values.
SNVT type is SNVT_hvac_status.
View the context sensitive help screen to see the values of
the structured SNVT.
A standard Comparison object can be used to convert the
fanOutput (FloatStatus type) to a BooleanStatus type.
SNVT_hvac_mode
HVAC mode. An enumerated list that accommodates integers that have an
Type
SNVT_hvac_mode
Category
Measurement
Range
Index
Enumerated
HVAC mode
112
Table B-6
Value
B–24
Enumerations (SNVT_hvac_mode, also is mode in SNVT_hvac_status).
Indentifier
Notes
0
HVAC_AUTO
Controller automatically changes between application modes
1
HVAC_HEAT
Heating only
2
HVAC_MRNG_WRMUP
Heating only
3
HVAC_COOL
Cooling only
4
HVAC_NIGHT_PURGE
Application-specific night purge
5
HVAC_PRE_COOL
Application-specific pre-cool
6
HVAC_OFF
Controller not controlling outputs
7
HVAC_TEST
Equipment being tested
8
HVAC_EMERG_HEAT
Emergency heat mode (heat pump)
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Table B-6
Value
Enumerations (SNVT_hvac_mode, also is mode in SNVT_hvac_status).
Indentifier
Notes
9
HVAC_FAN_ONLY
Air not conditioned, fan turned on
10
HVAC_FREE_COOL
Cooling with compressor not running
11
HVAC_ICE
Ice-making mode
0xFF
HVAC_NUL
Value not available
Figure B-21 Example control logic with NV implemented with SNVT_hvac_mode.
MultistateOutput (MSO) object. The MSO generates an integer value.
Right-click on it to see the command pop-ups (below).
The commands are configured on the Visual tab of its property sheet.
Mouse over the property tag and find that the property
name is nviAppMode of type LonHvacModeEnum.
SNVT type is SNVT_hvac_mode.
View the context sensitive help screen to see the
values of the enumeration.
Program object converts the MSO integer output to
LonHvacModeEnum enumerations, with this code:
input IntegerStatusType sIn
output LonHvacModeEnum snvtOut
if sIn.value==0
snvtOut=LonHvacModeEnum.auto
elseif sIn.value==1
snvtOut=LonHvacModeEnum.heat
elseif sIn.value==2
snvtOut=LonHvacModeEnum.morning_warmup
elseif sIn.value==3
snvtOut=LonHvacModeEnum.cool
elseif sIn.value==4
snvtOut=LonHvacModeEnum.night_purge
elseif sIn.value==5
snvtOut=LonHvacModeEnum.pre_cool
elseif sIn.value==6
snvtOut=LonHvacModeEnum.off
elseif sIn.value==7
snvtOut=LonHvacModeEnum.test
MSO
property
sheet,
Visual tab.
elseif sIn.value==8
snvtOut=LonHvacModeEnum.emergency_heat
elseif sIn.value==9
snvtOut=LonHvacModeEnum.fan_only
elseif sIn.value==10
snvtOut=LonHvacModeEnum.free_cool
snvtOut=LonHvacModeEnum.ice
endif
Practice Using SNVT_hvac_mode
Using a Honeywell W7750A controller, create the control logic necessary to
manually switch the application mode for which that controller operates.
Niagara Release 2.3
B–25
Appendix B
SNVT Reference
Working With SNVTs
Notes
Use an MSO object to switch the mode of the controller.
• Create a Program object to interpret mode control commands (from the MSO)
and switch the mode of the controller.
•
SNVT_hvac_overid
HVAC override. A structure that can be used to monitor and control the override
mode of a device. Used in HVAC applications, this structure supports both an
enumerated list (override mode) as well as percent level and flow values for position
and/or flow override control.
Type
SNVT_hvac_overid
Table B-7
Category
Measurement
Range
Index
Structure
HVAC override
95
SNVT_hvac_overid (data fields).
Field
Measurement
Category / Units
Range
Notes
state
Override mode
Enumeration
See Table B-8, enums
—
percent
Position or flow
override value
SNVT_lev_percent
-163.83 ... 163.83%
—
flow
Flow override value
Unsigned Long
0 ...65,534 l/sec
Liters per second
Table B-8
Value
Enumerations for state in SNVT_hvac_overid.
Indentifier
Notes
0
HVAC_OFF
Not overridden
1
HVAC_POSITION
2
HVAC_FLOW_VALUE
Override flow in liters/sec
3
HVAC_FLOW_PERCENT
Override flow percentage
4
HVAC_OPEN
Override to position = 100%
5
HVAC_CLOSE
6
HVAC_MINIMUM
Override to configured minimum
7
HVAC_MAXIMUM
Override to configured maximum
<not used>
Note: Next 7 values apply to first device/group
Note: Next 7 values apply to all devices/groups
8—16
17
HVAC_POSITION_1
18
HVAC_FLOW_VALUE_1
19
HVAC_FLOW_PERCENT_1
20
HVAC_OPEN_1
21
HVAC_CLOSE_1
22
HVAC_MINIMUM_1
23
HVAC_MAXIMUM_1
<not used>
Note: Next 7 values apply to second device/group
24—32
B–26
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Table B-8
Enumerations for state in SNVT_hvac_overid. (continued)
Value
Indentifier
Notes
33
HVAC_POSITION_2
34
HVAC_FLOW_VALUE_2
35
HVAC_FLOW_PERCENT_2
36
HVAC_OPEN_2
37
HVAC_CLOSE_2
38
HVAC_MINIMUM_2
39
HVAC_MAXIMUM_2
40—48
<not used>
—
0xFF
HVAC_NUL
Value not available
Practice Using SNVT_hvac_overid
SNVT_hvac_emerg
SNVT HVAC emergency. An enumerated list that accommodates integers that have
an enumeration type definition.
Type
SNVT_hvac_emerg
Category
Measurement
Range
Index
Enumerated
HVAC Emergency
Mode
103
Table B-9
Enumerations for HVAC emergency mode.
Value
Indentifier
Notes
0
EMERG_NORMAL
No emergency mode
1
EMERG_PRESSURIZE
Emergency pressurize mode
2
EMERG_DEPRESSURIZE
Emergency depressurize mode
3
EMERG_PURGE
Emergency purge mode
4
EMERG_SHUTDOWN
Emergency shutdown mode
5
EMERG_FIRE
Emergency fire mode
-1 (0xFF)
EMERG_NUL
Invalid value
Figure B-22 shows example usage of SNVT_hvac_emerg.
Niagara Release 2.3
B–27
Appendix B
SNVT Reference
Working With SNVTs
Figure B-22 Example control logic with NV implemented with SNVT_hvac_emerg.
Mouse over the property tag and find that the property name
is nviEmergCmd of type LonHvacEmergencyEnum.
Program object converts the MSO integer output to
LonHvacModeEnum enumerations, with this code:
SNVT type is SNVT_hvac_emerg.
output LonHvacEmergencyEnum snvtOut
View the context sensitive help screen to see the values of
the enumeration.
if sIn.value==0
snvtOut=LonHvacEmergencyEnum.normal
MultistateOutput
(MSO) object.
elseif sIn.value==1
snvtOut=LonHvacEmergencyEnum.pressurize
elseif sIn.value==2
snvtOut=LonHvacEmergencyEnum.depressurize
elseif sIn.value==3
snvtOut=LonHvacEmergencyEnum.purge
elseif sIn.value==4
snvtOut=LonHvacEmergencyEnum.shutdown
// elseif sIn.value==5
// snvtOut=LonHvacEmergencyEnum.fire
endif
The MSO generates an integer
value.
MSO
property
sheet,
Visual tab.
Right-click on the MSO to see the
command pop-ups (at left).
The commands are configured on
the Visual tab of its property sheet.
SNVT_temp_setpt
SNVT temperature setpoints. A structure that can be used to display and/or change a
collection of temperature setpoints used by a controller for its various modes of
operation (that is, cooling/heating, occupied/unoccupied, and so on).
Type
SNVT_temp_setpt
Table B-10
Category
Measurement
Range
Index
Structure
Temperature setpoints
106
Category / Units
Range
SNVT_temp_setpt (data fields).
Field
Measurement
Notes
occupied_cool
Occupied cooling setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
standby_cool
Standby cooling setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
(for each):
unoccupied_cool
Unoccupied cooling setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
Resolution of 0.01°C
occupied_heat
Occupied heating setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
standby_heat
Standby heating setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
0x7FFF value (32,767)
means invalid data
unoccupied_heat
Unoccupied heating setpoint
SNVT_temp_p
-273.17 ... 327.66 °C
B–28
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Figure B-23 Example control logic with NV implemented with SNVT_temp_setpt.
Conversion object SnvtTempSetptCmd
allows right-click command access to
change NCI setpoint values.
NCIs appear as outputs so that
other outputs cannot be linked to
them. Programmatic writing to
NCIs must be avoided because
NCI values are stored in
persistent memory, and overuse
can lead to flash memory failure.
SNVT type is SNVT_temp_setpt.
View the context sensitive help
screen to see the values of the
structured SNVT.
GxTexts are used
to expose the
setpoint values.
Property sheet, Visual tab for SnvtTempSetptCmd object
determines the command labels seen.
Any non-blank entry allows command access to that
specific setpoint field in the NCI using SNVT_temp_setpt.
Setpoint adjustment limits are also possible (Figure B-24).
Figure B-24 Config properties for min and max values define user-adjustable limits.
If you configure max and min
SetptValues, the JDE provides
a slider bar for the user to
adjust setpoint values.
Niagara Release 2.3
B–29
Appendix B
SNVT Reference
Working With SNVTs
Practice Using SNVT_temp_setpt
Using an Invensys MN-200 controller, create the control logic necessary to manually
adjust temperature setpoint.
Notes
Use a SnvtTempSetptCmd object linked to the MNLRR103 shadow object.
• Configure the SnvtTempSetptCmd object such that the user can manually
adjust (on a slider scale) each of its six setpoint values. Limit each of those
values within a given range.
•
SNVT_occupancy
SNVT occupancy. An enumerated list that accommodates integers that have an
Type
SNVT_occupancy
Category
Measurement
Range
Index
Enumerated
Occupancy
109
Table B-11
Value
Occupancy enumerations.
Indentifier
Notes
0
OC_OCCUPIED
Area is occupied
1
OC_UNOCCUPIED
Area is unoccupied
2
OC_BYPASS
Area is temporarily occupied for the bypass period
3
OC_STANDBY
Area is temporarily unoccupied
OC_NUL
Value not available
0xFF
See Figure B-25 for two examples using SNVT_occupancy.
B–30
Niagara Release 2.3
Appendix B
SNVT Reference
Working With SNVTs
Figure B-25 Two examples of control logic with NV implemented with SNVT_occupancy.
Mouse over the property tag and find that the property
name is nviOccCmd of type LonOccupancyEnum.
SNVT type is SNVT_occupancy.
View the context sensitive help screen to see the
values of the enumeration.
NvoOccCmd provides
a means to expose
the occupancy status.
The BinaryOutput
(BO) provides the
means to override
a scheduled
occupancy time.
A BoolToOccupancy conversion
object is used to convert the BO
statusOut to the
LonOccupancyEnum data type.
This Program object takes the integer value
generated by the MSO and converts it to its
corresponding LonOccupancyEnum value, using the
following code:
output LonOccupancyEnum snvtOut
if sIn.value==0
snvtOut=LonOccupancyEnum.occupied
elseif sIn.value==1
snvtOut=LonOccupancyEnum.unoccupied
MSO
property
sheet,
Visual tab.
elseif sIn.value==2
snvtOut=LonOccupancyEnum.bypass
elseif sIn.value==3
snvtOut=LonOccupancyEnum.standby
snvtOut=LonOccupancyEnum.null
endif
Niagara Release 2.3
B–31
Appendix B
SNVT Reference
Working With SNVTs
Practice Using SNVT_occupancy
Using an Invensys MN-200 controller, create the control logic necessary to manually
override occupancy mode of that controller.
Notes
•
Use an MSO object to switch the occupancy mode of the controller.
•
Create a Program object to interpret mode control commands (from the MSO)
and switch the occupancy mode of the controller.
•
Display the occupancy mode of the controller in a GxText object.
SNVT_date_time
This SNVT should not be used for new applications. Use SNVT_time_stamp.
SNVT_time_stamp
SNVT time stamp. A structure that can be used to display and/or change date and
time.
Type
SNVT_time_stamp
Table B-12
Field
year
Category
Measurement
Range
Index
Structure
Time Stamp
84
SNVT_time_stamp (data fields).
Measurement
Category / Units
Range
Year
Year
0 ... 3,000 (years AD)
Notes
0 means year not specified
65,535 represents null date
month
Month
Month
0 ... 12
0 means month not specified
day
Day
Day
0 ... 31
0 means day not specified
24-hour format used
hour
Hour
Hour
0 ... 23
minute
Minute
Minute
0 ... 59
second
Second
Second
0 ... 59
Practice Using SNVT_time_stamp
B–32
Niagara Release 2.3
Appendix B
SNVT Reference
Converting LonWorks Data Using Program Objects
Converting LonWorks Data Using Program
Objects
This section contains the following subsections:
About Conversion Objects
• Creating Your Own Conversion Objects
• Other Examples
•
About Conversion Objects
As you are probably aware, many SNVTs are expressed as fixed point or floating
point values—meaning they accommodate a single integer or floating point value.
Other SNVTs are defined as structures. If an application calls for a link to be made
between two incompatible data types, a conversion object is required to convert data
from one type to another.
For instance, if an object could read only floating-point data and the available
network variable were an integer value, it would be necessary to convert the value—a
conversion object could be used to read an integer value on its input and write a
floating point value out on its output. Similarly, if an object exposed an input network
variable as a structure and the only network variables available (as inputs) were
single values, it would be necessary to build a structure from those individual values
before linking to the exposed NVI. This operation is referred to as “multiplexing” and
the conversion objects used to accomplish the task are multiplexers or “muxes.”
In the case of structured SNVTs, it is just as likely that you might have to dissect an
NVO (just as you constructed an NVI above). The term for this is “demultiplexing”.
Objects that read in a structured SNVT on a single NVI, break it down into its
component parts (fields), and make available multiple NVOs (as primitive data) for
use in the device's application, are called “demuxes.”
The LonWorks JAR file (d:/tridiumx/lonworks) contains copies of the core,
non-manufacturer-specific Niagara objects that can be used to support LonWorks
integrations. In this container, you can find generic conversion objects that can be
used to convert data for any LonWorks device. Similar, but manufacturer-specific,
conversion objects are available for each manufacturer integrated into the Niagara
Framework. A JAR file for each manufacturer is available in the local library at
d:/tridiumx/londevices.
Creating Your Own Conversion Objects
Many of the standard conversions can be handled with easy-to-use objects that are
pre-configured and stored in the local library. More conversion objects are added to
each subsequent Niagara software release. If you have a need for a conversion for
which a pre-configured object does not exist, a Program object can be easily
constructed to accomplish the task.
Niagara Release 2.3
B–33
Appendix B
SNVT Reference
The approach to create a custom Program object to is always the same: Declare one
or more inputs for the data that needs to be converted (in the form of the data as it
exists), declare an equivalent number of outputs (in the form that it needs to be), and
provide the logic necessary to set the field of the output variable equal to the value
required based on the input value.
The common steps that are required to create a custom Program object can be
summarized as follows.
Input Control
Logic
If the control logic that you are creating is input logic (that is, you are writing a value
to a controller or issuing a control command):
Determine the data type of the linkable output for the user control. This
property will serve as the source property for the link created between the
control object and the target node. The data type of this property determines the
variable type of the input declared in the Program object that you create.
• Determine the network variable (NV) type of the (input) property to which a
link is going to be made (on the LonWorks shadow object). The data type of
this property determines the variable type of the output declared in the Program
object that you create.
• Using context-sensitive help (in WorkPlace Pro), determine which Niagara
data type is used to represent the NVI to which you are linking.
• Using manufacturer-supplied documentation for the node that you are
integrating (or at least the SNVT Master List), determine the behavior of the
network variable for the purpose of creating control logic necessary to set the
value of the output based on the value of the input.
•
Output Control
Logic
If the control logic that you are creating is output logic (that is, you are exposing a
value/status or driving a graphic animator that conveys status):
Determine the network variable (NV) type of the (output) property from which
a link is going to be made. This property will serve as the source property for
the link created between the LonWorks shadow object and the target user
interface object. The data type of this property determines the variable type of
the input declared in the Program object that you create.
• Using context-sensitive help (in WorkPlace Pro), determine which Niagara
data type is used to represent the NVO from which you are linking.
• Determine the data type of the linkable input for the object to which a link is
going to be made (to expose the value/status). The data type of this property
determines the variable type of the output declared in the Program object that
you create.
• Using manufacturer-supplied documentation for the node that you are
integrating (or at least the SNVT Master List), determine the behavior of the
network variable for the purpose of creating control logic necessary to set the
value of the output based on the value of the input.
•
B–34
Niagara Release 2.3
Appendix B
SNVT Reference
A Simple Example: FloatStatusType to Boolean
Consider the situation where the status of a device is held in a SNVT of type
SNVT_lev_percent and you need to control a GxBoolean object for active/inactive
on a graphic display.
Using documentation supplied by the manufacturer, discover that heat status is held
in the SNVT nvoSatPercent1. Using context sensitive help, discover that
nvoSatPercent1 is stored in the Niagara station as type FloatStatusType. The data
type of the linkable input property 'binding' of the GxBoolean object is
FlexBindingType, which acts as a Boolean switch: it displays one graphic image
when the status input to which it is bound goes active and a separate image when that
status goes inactive.
Therefore, create a Program object that converts from FloatStatusType to Boolean.
The logic of the Program object tests that value of the floating-point input and if it is
greater than zero, it writes a true output. Conversely, if the input is either equal to or
less than zero, the Program object outputs a false. The true/false values are used to
activate and deactivate a graphical animator of a lamp.
The basic steps are shown in the following figures:
1.
Start from the property sheet of the LonWorks shadow object. (Figure B-26)
2.
Follow the links from NV to Variable Types and select the type. (Figure B-27)
3.
Create the Program object logic. (Figure B-28)
4.
Link the conversion Program object. (Figure B-29)
Figure B-26 Start from the property sheet of the LonWorks shadow object.
From the property sheet of
the LonWorks shadow
object, select
context-sensitive Help.
Search through the
properties and find the one
(nvoSatPercent1) that you
need to expose.
Note the data type of the
property (FloatStatusType).
In the context-sensitive
help view, click on the
FloatStatusType hyperlink.
Niagara Release 2.3
B–35
Appendix B
SNVT Reference
Figure B-27 Follow the links from NV to Variable Types and select the type.
The Help view displays a list
of variable types.
Scroll down to find the
variable type again (in this
case, FloatStatusType), and
click on it.
Elements of that variable are
displayed (for instance,
status and value). The
elements of the property
provide the means to read
and write property values.
Figure B-28 Create the Program object logic.
Create a Program object that
declares an input of type
FloatStatusType and an
output of type Boolean—the
string output is simply an
option that can be used to
display on/off status directly
from the Program object.
The logic of the Program
object tests the input (value)
for a value greater than zero.
• If true, the output is set
(true).
• If false, the output is
cleared (false).
These (output) values can,
in turn, be used to drive a
GxBoolean object active and
inactive as shown in the
control logic below.
B–36
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-29 Link the conversion Program object.
Stretch links between:
1) The nvoSatPercent1
property of the LonWorks
shadow object and the input
of the Program object, and
2) Between the output of the
Program object and the
binding property of the
GxBoolean object.
The resulting logic looks
similar to that shown here.
Other Examples
IntegerStatusType to LonOccupancyEnum
Consider the situation where you need to provide manual mode control. Oftentimes,
controllers provide a network variable input to control the mode of operation of an
air handler. The AHU may support several modes of operation including occupied,
unoccupied, bypass, standby, and more. A MultistateOutput (MSO) object is used to
provide manual control of occupancy mode.
Niagara Release 2.3
B–37
Appendix B
SNVT Reference
Notes for Creating the Program Object
The following notes apply in this example:
•
•
•
•
•
This is an example of input control logic.
The user control is an MSO, which provides manual control of multiple states.
The data type of the linkable output is of type IntegerStatusType.
The nviOccupancy network variable is of type SNVT_occupancy, which is of
type LonOccupancyEnum in the station.
The elements of LonOccupancyEnum include occupied (0), unoccupied (1),
bypass (2), standby (3), and null (255).
The state text table for the MSO that controls occupancy mode must be
configured as illustrated below.
Figure B-30 MultistateOutput stateText table for this example.
B–38
1.
Create the Program object using the necessary logic. (Figure B-31)
2.
Link the MSO, Program, and shadow objects. (Figure B-32)
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-31 Create the Program object using the necessary logic.
The code of the Program
object looks like this:
An input is declared to match
the data type of the user
control.
An output is declared to
match the data type of the
NVI.
The value of the output
(through the enumeration
LonOccupancyEnum) is set
to one of its predefined
modes depending on the
value of the command being
issued by the MSO.
The conditional logic tests
the value of the input. If it is
zero, the output is set to
occupied, if it is a one, the
output is set to unoccupied,
and so on.
Figure B-32 Link the MSO, Program, and shadow objects.
Stretch links:
• Between the status output
property of the MSO and
the input of the Program
object, and
• Between the output of the
Program object and the
nviOccCmd network
variable of the LonWorks
shadow object.
Niagara Release 2.3
B–39
Appendix B
SNVT Reference
Boolean to
Free1
Consider the situation where you need to provide manual on/off control of a digital
circuit on a Honeywell controller. Oftentimes, these controllers provide FreeX
network variable control of spare digital outputs for auxiliary functions. As defined
by Honeywell, nviFree1 controls the FREE1_OUT output, nviFree2 controls the
FREE2_OUT output, and so on. The states of these outputs have the following
meaning:
Table B-13
Honeywell controller FreeX output state meanings.
If the state element is OFF...
...the corresponding free logical output (and
therefore the physical output) is OFF.
If the state element is ON and
the value element is zero…
…the corresponding free logical output (and
therefore the physical output) is OFF.
If the state element is ON and
the value element is not zero…
…the corresponding free logical output (and
therefore the physical output) is ON.
Notes for Creating the Program Object
The following notes apply in this example:
This is an example of input control logic.
• User control is using a Binary Output and the linkable output is of type
BooleanStatusType.
• The nviFree1 network variable is of type SNVT_switch, which is of type
SnvtSwitchValueType in the station.
• The elements of the property SnvtSwitchValueType include statusFlags, value,
and state. The state element is an enumeration (LonSwitchStateEnum).
To discover the values of the enumeration, access the context-sensitive help for
the shadow object. Using the tridiumx/lonworks documentation, click on
Subsystem Reference, and find the enumeration in the Table of Contents
(Figure B-33).
•
B–40
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-33 Finding the enumeration values of a Variable Type.
Scroll down to find the variable of
interest, and click here to view the
list of variable types.
Scroll down again to locate the
variable, and click it again to
display the variable help page.
Note the enumeration type used
(LonSwitchStateEnum), and then click
on the tridiumx.lonworks Documents link.
Click on the Subsystem
Reference.
Scroll down the Table of Contents to find
the enumeration, and click on its link.
Niagara Release 2.3
B–41
Appendix B
SNVT Reference
The Program object used in this example allows the user to change the value
definition of an ON state and an OFF state. The properties used to make these
changes are HIout (used to define an ON state) and LOout (used to define an
OFF state).
• As specified in Table B-13, the state element is set ON, which allows the value
element to control the free digital output on/off.
•
1.
Create the Program object using the necessary logic. (Figure B-34)
2.
Link the BO, Program, and shadow objects. (Figure B-35)
Figure B-34 Create the Program object using the necessary logic.
The code of the Program
object looks like this.
An input is declared to
match the data type of
the user control.
An output is declared to
match the data type of
the NVI.
The properties are
optional and they allow
the user to modify the
value definitions used by
the Program object
without actually
modifying and
recompiling the PO itself.
The state of the output
(through the enumeration
LonSwitchStateEnum) is
set ON to allow the
physical output to be
controlled by changing
the value element.
The conditional logic tests
the value of the input. If it is
true, the output value is
changed to its user
defined high (ON), if not, it
is changed to its user
defined low (OFF).
B–42
Niagara Release 2.3
Appendix B
SNVT Reference
Figure B-35 Link the BO, Program, and shadow objects.
Stretch links:
• Between the status
output property of the
Binary Output and the
input of the Program
object, and
• Between the output of
the Program object and
the nviFree1 network
variable of the
LonWorks shadow
object.
Niagara Release 2.3
B–43
Appendix B
SNVT Reference
B–44
Niagara Release 2.3
You can help make this manual even better!
Please help us make our documentation as useful as possible. Use this form to advise
us of errors, descriptions that are not clear, or provide any other helpful information.
Mail this form to:
Tridium, Inc.
3951 Westerre Parkway, Suite 350
Richmond, Virginia 23233
Attention: Tridium Documentation Team
Or fax is to us at: (804) 747-5204
Or e-mail your comments to us at: [email protected]
Thank you for taking the time to help us improve our documentation!
Documentation Comment Form
Document Title:
Document Version:
Niagara Release 2.3
Page #
Problem Found or Suggested Change
Your Name:
Your Company:

Niagara LonWorks Integration Guide

Transcription

Similar documents

Thank You! - PenFinancial Credit Union

Buffalo Niagara Overview

Brochure March 14 - Executive Hotels and Resorts

a printable copy of our Park Brochure!

See Itinerary

NGRM 2016 Summer Newsletter - Niagara Gospel Rescue Mission

ACCOMMODATIONS - Embassy Suites Niagara Falls Hotel

- Niagara Sunday Fliers

Opportunities Brochure - Keefer Developments Ltd