Niagara LonWorks Integration Guide - … · Tridium, Inc. 3951 Westerre Parkway • Suite 350 Richmond, Virginia 23233 USA Phone 804.747.4771 • Fax 804.747.5204 Technical Publications

Tridium, Inc.3951 Westerre Parkway • Suite 350Richmond, Virginia 23233USA

http://www.tridium.comPhone 804.747.4771 • Fax 804.747.5204

Technical Publications

Niagara LonWorksIntegration Guide

Revised: December 16, 2002

http://www.tridium.com

Copyright Notice: The software described herein is furnished under a license agreement and may be used only in accordance with the terms of the agreement.

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 350Richmond, 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.

Niagara LonWorks Integration Guide© 2002, Tridium, Inc.All rights reserved.

C O N T E N T S

P R E F A C E About This Document 9

Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Important Information Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Commonly Used Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

C H A P T E R 1 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

C H A P T E R 2 LonWorks Overview 2-1

LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Echelon Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Applications and Distribution Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

LonMark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

C H A P T E R 3 LonWorks Design Concepts 3-1

LANs and LONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

LonTalk Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Smart Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Niagara Release 2.3Niagara LonWorks Integration Guide Revised: December 16, 2002 1

Contents

Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Centralized Control System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Fully Distributed (Flat) Control System . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Semi-Distributed Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

C H A P T E R 4 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

C H A P T E R 5 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.3Niagara LonWorks Integration Guide Revised: December 16, 20022

Contents

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

C H A P T E R 6 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

C H A P T E R 7 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


Contents

Third Party Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

Application Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Configurable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Programmable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Application Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

C H A P T E R 8 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

C H A P T E R 9 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


Contents

LonTemp Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

Local Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7

C H A P T E R 10 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

C H A P T E R 11 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

C H A P T E R 12 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


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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

C H A P T E R 13 User Interface 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

A P P E N D I X A 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

A P P E N D I X B 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


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


Contents


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 AudienceThe 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.


About This DocumentDocument Summary

Document SummaryThis 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.


About This DocumentFormatting Conventions

Formatting ConventionsThis 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 IndicatorsIn addition to text formatting, this document uses important information indicators, as listed below:

Note Notes typically contain significant details related to the topic in the nearby text. They alert you to important information that might otherwise be overlooked.

Caution Cautions remind you to be careful. There is a chance that you could perform an action that cannot be undone, might produce unexpected results, or might cause lost data. Cautions typically explain why the action is potentially problematic.

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

Refer to “Refer to” references point to other documents that contain additional information on the current topic. The reference includes the name of the document, and if applicable, the chapter name and number where the additional information appears.


About This DocumentRelated Documentation

Related DocumentationFor general information on networking and connectivity, refer to the Niagara Networking & Connectivity Guide.

Other related documents are listed in sections below.

SourcesThe 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 InformationFor 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


http://www.echelon.com/Support/KnowledgeDB/FAQ_Glossary/default.htm

http://www.lonmark.org/products/guides.htm#guidelines

About This DocumentCommonly Used Terms

Commonly Used TermsThroughout 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.



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.



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.



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:



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



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.



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.





CHAPTER 1
Introduction to Open Systems
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 SystemEach 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.

HardwareThe physical devices that are commonly found in an HVAC control system include:

• Sensors• Control Devices• Controllers• Networks• Operator Interface PC

Refer to For more information and an introduction to DDC control systems, refer to www.energy.iastate.edu/ddc_online.

1–1

www.energy.iastate.edu/ddc_online

Chapter 1 Introduction to Open SystemsParts of a Control System

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.

Niagara Release 2.3 Revised: December 16, 2002 Niagara LonWorks Integration Guide1–2


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.

SoftwareThe 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.

ArchitectureSystem 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.


1–3


Figure 1-1 Typical system architecture.

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.

Primary LAN

Operator Station Operator Station

Operator Station

Router orArea Controller

Controller

Controller

Operator Station


Controller

Controller


Chapter 1 Introduction to Open SystemsInterconnectivity 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

Interconnectivity in Control SystemsAs 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.

GatewaysIn 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 GatewayFigure 1-2 shows an architecture with a primary LAN, area controller, and proprietary fieldbus devices connected to third party devices via a gateway.


1–5


Figure 1-2 Closed-to-closed gateway configuration.

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.

Primary LAN



Controller

Controller

LAN (Closed Protocol)

Gateway

3rd Party Device

ProprietaryCommunications Trunk

(Closed)

Primary LAN



Controller

Controller


Gateway

3rd Party Device


(Closed)

Gateway

Open Protocol



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 BridgesA 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.

Primary LAN

Host Bridge (PC)

Operator Station


Controller

Controller



(Closed)

CCTV orFire System


1–7


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.

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

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.

Vendor(A) LAN

Operator Station (A)


Controller

Controller

DDC System (A)

Vendor(B) LAN

Overlay Systemwith HMI that looks like

a single system

Operator Station (B)


Controller

Controller

DDC System (B)



Openness in Control SystemsThere 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.


1–9


Figure 1-6 Network diagram of coexistence.

Interoperable Devices

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.

Operator Station


Controller

Controller

DDC System (A)

Primary LAN

Operator Station


Controller

Controller

DDC System (B)

Operator Station (A) Operator Station (B)

Systems share a common LAN, but they donot necessarily talk to one another.



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.

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.

Protocol (i.e., LonTalk)

InterchangeabilityUltimate in openness - allows the user to let price andperformance dictate choice.Standard hardware deinitionsStandard 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)


1–11


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.

• 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.



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

LonWorksLonWorks 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.

2–1

Chapter 2 LonWorks OverviewEchelon 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 CorporationEchelon 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.


Chapter 2 LonWorks OverviewApplications and Distribution Channels

Applications and Distribution ChannelsFundamental 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.

LonMarkIf 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


2–3

Chapter 2 LonWorks OverviewLonMark

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.



CHAPTER 3
LonWorks Design Concepts
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 LONsCommunications 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

3–1

Chapter 3 LonWorks Design ConceptsLonTalk 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 ProtocolA 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 DevicesA 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.


Chapter 3 LonWorks Design ConceptsNetwork Architecture

Network ArchitectureThe 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 SystemA 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).

LAN

Server

Workstation


3–3


Fully Distributed (Flat) Control SystemA 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.

LAN

WorkstationRouter Router

Workstation



Semi-Distributed Control SystemIn 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.

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.

LAN

Area Controller

Workstation

Workstation

Area Controller


3–5




CHAPTER 4
LonWorks Architecture
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 OverviewThe 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.

4–1

Chapter 4 LonWorks ArchitectureThe Neuron Chip

The Neuron ChipThe 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.

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 StructuresFigure 4-2 depicts the various data structures that may be stored in on-chip EEPROM, off-chip EEPROM, flash, or NVRAM.

Neuron ChipID# 010031EFEA00

Xtal

Transceiver

Optional ExtMemory (3150)

I/OConditioning

LonTalkNetwork

I/O Devices(sensors, actuators)

Protocol Firmware(Layers 1-2)

Protocol Firmware(Layers 3-6)

I/O Resources(i.e., counters, drivers, etc.)

ApplicationCPU

RAM / ROM / EPROM

Node-SpecificProgram

NetworkCPU

RAM / ROM / EPROM

Media AccessCPU

RAM / ROM /EPROM

CommPort

PowerRegulator



Figure 4-2 Neuron chip data structures.

Processing UnitsThe 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 ImageA 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.

Neuron FIXED STRUCTURE

NETWORK VARIABLE FIXED TABLE

NETWORK VARIABLE CONFIGURATION TABLE

SELF-DOCUMENTATION

CONFIGURATION STRUCTURE

ADDRESS TABLE

DOMAIN TABLE

This node's 48-bit ID and ProgramID

Points to NVs data in RAM orEEPROM

Points to NV selector number andaddress table

Contains transceiver parameters

Message destination subnet/nodesor groups used for implicitaddressing

This node's domain ID,authenticationkey, subnet ID, andnode ID


4–3


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.



Domain TableThe domain table contains an entry for every domain to which a node belongs. For more information, refer to “Logical Addressing,” page 5-4.

Address TableThe 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 TablesNetwork 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.


4–5

Chapter 4 LonWorks ArchitectureHosted Nodes

Hosted NodesIn 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.

Transceivers, Media, and Network TopologyIn 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.


Chapter 4 LonWorks ArchitectureTransceivers, Media, and Network Topology

Figure 4-3 Free topology networks.

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 TopologyAs 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.

TerminationModule

Node


4–7


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

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.



Doubly-Terminated Bus TopologyYou 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.

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.

• 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:

Wire size Maximum cable length24 AWG 2951 feet (900m)22 AWG 4590 feet (1400m)16 AWG 8853 feet (2700m)

TerminationModule

TerminationModule

Cable type AWG DiameterTIA 568A Category 5 24 0.5mmBelden 8471 (PVC jacket) 16 1.3mmBelden 85102 (Tefzel jacket) 16 0.65mmLevel IV 22 0.65mmJY (st) 2x2x0.8 20.4 0.8mm


4–9


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).


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).


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.

ChannelsThe 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.



RoutersRouters 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 RepeatersPhysical 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


4–11


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 WorkLearning 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.

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.

1 2 3

7 8 9

4 5 6

R

R

Channel

Channel

Channel

Subnet 1

Subnet 3

Subnet 2

Learning Router

R2

R1


Chapter 4 LonWorks ArchitectureLonWorks Network Interface

Learning Routers versus Configured RoutersWhen 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.

LonWorks Network InterfaceStandard 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.


4–13

Chapter 4 LonWorks ArchitectureLonWorks Network Interface



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.

5–1

Chapter 5 LonTalk ProtocolLonTalk

LonTalkLonTalk 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.

A Closer Look at the LonTalk ProtocolNeuron 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.

Table 5-1 Seven-layer OSI protocol model used with LonTalk protocol.

OSI Protocol Model Layer Number LonTalk Purpose SummaryApplication 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.


Chapter 5 LonTalk ProtocolLonTalk

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.


5–3

Chapter 5 LonTalk ProtocolLogical Addressing

Logical AddressingSince 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.

DomainA 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.



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.

SubnetThe 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).

Figure 5-2 Subnets cannot span intelligent routers (one domain).

1 2 3 4 5 6

Channel

Subnet 1 Subnet 2

1 2 3

4 5 6

R

Channel

Channel

Subnet 1

Subnet 3

4 5

Subnet 2


5–5


Figure 5-3 A node configured in two domains has subnet assignments for each.

Node AddressEvery node within a subnet is assigned a unique node number from 1—127, by the network management tool at the time of commissioning.

GroupsGroup 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.

Domain 1, Subnet 1 Domain 2, Subnet 1

111 112 113

Channel

212 213 214114211

Node (112):Domain 1, Subnet 1, Device 2

1 2 3

7 8 9

4 5 6

R

R

Channel

Channel

Channel

Subnet 1

Subnet 3

Subnet 2

Nodes 1—3 and 9 belong to a common group.


Chapter 5 LonTalk ProtocolCommunications 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 FormatsNodes are addressed using one of five addressing formats.

Routing MessagesAs 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.

Communications ServicesThe 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

If the address data specified is… The nodes that receive the message are…Domain:X, Subnet equals zero All nodes assigned to Domain:XDomain:X, Subnet:Y All nodes assigned to Domain:X and Subnet:YDomain:X, Subnet:Y, Node:Z That specific logical nodeDomain:X, Group:G All nodes assigned to Group:GUnique Neuron ID Specific physical node


5–7

Chapter 5 LonTalk ProtocolCommunications Services

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 ServiceThe 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 ServiceThe 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 ServiceAlso 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 ServiceThe 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.


Chapter 5 LonTalk ProtocolCollision Detection

Collision DetectionAll 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.

TimersThere 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 TimerWhen 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.


5–9

Chapter 5 LonTalk ProtocolOptional Priority

Transaction TimerWhen 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 TimersThis 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 TimerWhen 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 PriorityThe 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.


Chapter 5 LonTalk ProtocolAuthentication

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.

AuthenticationAuthentication 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.


5–11

Chapter 5 LonTalk ProtocolAuthentication

Figure 5-5 Network Variable Update Flow Diagram.

APPLICATIONMODIFIESNETWORKVARIABLE

GET SELECTORFROM NV

CONFIG TABLE

GETDESTINATIONADDR FROM

ADDRESS TABLE

NV UPDATEMESSAGE

FORMATTED

TRANSMITMESSAGE

RECEIVEMESSAGE

GROUPMEMBER?

SELECTORMATCH?

UPDATE DATA

NOTIFYAPPLICATION

DONE

YES

YES

ADDRESSTABLE(Group

Numbers)

NV CONFIGTABLE

(Selectors)

TargetNode 2

RECEIVEMESSAGE

GROUPMEMBER?

SELECTORMATCH?

UPDATE DATA

NOTIFYAPPLICATION

DONE

YES

TaregetNode 1

MESSAGE SENT TOGROUP

The NV selector is a 14-bitnumber assigned by a

network management tool.The selector is the same for

all NVs bound together.

There are 15 address tableentries per node. Each NVis associated with an entry

in the address table. Groupaddressing is typically usedfor NV bindings. The limits

of group addressing are:255 groups per domain and64 members per group. A

single node can be amember of multiple groups.

ADDRESSTABLE(Group

Numbers)

NV CONFIGTABLE

(Selectors)

NV CONFIGTABLE

(NV selector &Addr Table Index)

ADDR TABLE(Addr Table Entry)

SourceNode

1 size (2-64)

dom member id (0-63)

repeat timer retry count

receive timer transmit timer

group (0-255)

Group Address Format

0-6bytes

subnet/node

subnet/node,

group, orbcast

14-bitnumber

1-31bytes

DOMAINID

SOURCEADDR

DESTADDR

NVSEL DATA

Packet Format

pri select - hi

select - lo

svc type addr tbl index

NV Config Table(typical for 62)

dir

turn auth

YES



CHAPTER 7
Network Management Tools
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 ManagementNetwork 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

7–1

Chapter 7 Network Management ToolsSystem 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 OverviewThe 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.


Chapter 7 Network Management ToolsStructure of a Network Management Tool

Figure 7-1 System diagram.

Structure of a Network Management ToolTheoretically, 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.

Human MachineInterface

NetworkDatabase

NetworkInterface

NetworkManagement

Tool

ApplicationProgramming

Tool

LonWorks Network

User Interface

Add-OnPlug-In Interface

Tool Kernel

LonWorks Interface

Database


7–3

Chapter 7 Network Management ToolsStructure of a Network Management Tool

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 ServicesLonWorks 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 InstallationThe 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.


Chapter 7 Network Management ToolsNetwork 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 DatabaseAs 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.


7–5


LNSEchelon 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.



• 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 See http://www.echelon.com/lonmaker/ for complete description.

VisualControl Network Manager (VCNM)

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 DesignsProprietary 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


7–7

http://www.echelon.com/lonmaker/

http://www.visualcontrol.com/vcnet.htm

Chapter 7 Network Management ToolsApplication 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 Peak Component's network management tool.

Refer to See http://www.ieclon.com/tutorial.html for a complete description.

Circon SI Circon's network management tool.

Refer to See http://www.circon.com/products/default.asp for a complete description.

Application ProgrammingThe 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 DevicesApplication-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.


http://www.ieclon.com/tutorial.html

http://www.circon.com/products/default.asp


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 DevicesA 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 ToolsThis 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.


7–9

http://www.visualcontrol.com/vcgra.htm


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.



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 AssociationThe 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

6–1

Chapter 6 InteroperabilityNetwork 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 VariablesEchelon 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.



Figure 6-1 Network Variable Connection.

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 RestrictionsThere 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.

Controller Controller

Switch Lamp

Network Variable Updates


6–3


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 SNVTsMany 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.


Chapter 6 InteroperabilityConfiguration Properties

Enumerated ListsSNVTs 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_ONLY10: HVAC_FREE_COOL11: HVAC_ICE

Configuration PropertiesNodes 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.


6–5

Chapter 6 InteroperabilityExplicit 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 MessagesApplications 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.

ApplicationsEvery 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) DevicesSimple 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 DevicesAn 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


Chapter 6 InteroperabilityFunctional 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 InterfaceWhere 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• Configuration Properties• 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.


6–7

Chapter 6 InteroperabilityLonMark 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 ObjectsAs 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.


Chapter 6 InteroperabilityLonMark Objects

All standard network variables and configuration properties are separated into mandatory, optional, and manufacturer-defined.

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.

Figure 6-2 Example functional profile (LonMark Interoperability Guidelines).

Input network variables (NVIs) appear on the left and show values entering the object.Output network variables (NVOs) appear on the right and show values exiting the object. The SNVT type of the NVI/NVO appears below each nviName and nvoName. Associated configuration properties (NCIs) are shown in the lower section of the object.

nv1nviSpaceTempSNVT_temp_p

Object Type and Index(i.e., Heat Pump: Type 8051)

nv3nvoSpaceTempSNVT_temp_p

MandatoryNetworkVariables

OptionalNetworkVariables

nv10nvoEffectiveSetptSNVT_temp_p

nv7nviSetptOffsetSNVT_temp_p

nv6nviOccCmdSNVT_occupancy

nv5nviAppliModeSNVT_hvac_mode

Configuration Properties

nc49 - nciSndHrtBtnc48 - nciRcvHrtBtnc60 - nciSetPnts

SNVT_time_secSNVT_time_secSNVT_temp_setpt

ManufacturerDefined Section

Explicit Messages

Device Documentation

Input network variables, including nv#, name and SNVT type.

Output network variables, including nv#, name and SNVT type.

Mfg-defined network variables and types. May include proprietary, non-interoperable interface.


6–9

Chapter 6 InteroperabilityNetwork 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 TypingFor 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 ConventionsNetwork 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.


Chapter 6 InteroperabilityProgram IDs

Program IDsA 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.


6–11

Chapter 6 InteroperabilityProgram IDs



CHAPTER 8
Niagara LonWorks Service
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 ManagerThe 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 LON Device Manager.

8–1

Chapter 8 Niagara LonWorks ServiceDevice Manager

Device Manager ViewThe 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.

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.

Table 8-1 Device statuses.

Status Meaningconfig_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.



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 CommandsSeveral 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.

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.

Status Line can display information. Click to open a Status Line History window.


8–3


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:

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.

Learn 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


Chapter 8 Niagara LonWorks ServiceLink 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 If you perform a Learn, then follow it with a Commission (and not an Upload), all binding information is lost.

Upload 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 ManagerThe 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.


8–5


Figure 8-3 LON Link Manager.

Link Manager ViewThe 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 Meaningnew 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.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.



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 TagsGenerally, 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.


8–7

Chapter 8 Niagara LonWorks ServiceUtilities Manager

Link Manager CommandsTwo 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.

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 ManagerThe 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.

Status Line can display information. Click to open a Status Line History window.



Figure 8-5 LON Utilities Manager View.

Utilities Manager ViewThe 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/SubCommandThe 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 CommandsUtilities 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

Main Command

Sub Command

Select Device

Execute Command

Client View (results)


8–9


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• find• identify• file• dataStructures• disable Authentication• reports• readMemory

status 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.

displayThis 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 Device status display.



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.


8–11


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.

clearThis 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 unconfiguredIn 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 onlineThe 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.



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 Devices found by the LON Utilities Manager (command: find)

identify 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.

winkTo use this command, first select a device from the selection list.


8–13


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 pinYou 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 • 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.



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.”

fileDirectoryIf 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.


8–15


Figure 8-10 The template file of the Honeywell W7751F controller.

configValueFileDisplays the value file stored in the node.

Figure 8-11 Configuration values stored in the Honeywell W7751F controller.

otherDisplays 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 File, other command displays hex dump of selected file.



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.

addressTableThis 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.


8–17


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.



domainTableThis 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.


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.


8–19


readOnlyStructureThis structure defines the node identification as well as some of the application image properties of the node.


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).



• 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).


8–21


configStructureThis 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.


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).



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.

nvAliasTableAs 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.


Figure 8-17 NV alias table in the Honeywell T7780A.

nvConfigThe 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.


8–23



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).



nvValueThe 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.


8–25


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 name.

Network variable type (see the SNVT Master List for more details).

NV Index (relates to Ndx and NvIndex).

NV Configuration properties section.



selfDocumentationSelf-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:

• 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.

Refer to For an in-depth discussion of self-documentation, refer to Section 5 of the LonMark Application Layer Interoperability Guidelines (078-0120-01C).


8–27


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.

netMgmtSummaryThe network management summary report (Figure 8-22) is a summary of network linkages, address table entries, and group assignments.

Figure 8-22 Network management summary view.



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.

programIdsThe 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.

transmitErrorsThe 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.


8–29


Figure 8-24 Transmit errors report.

verifyThe 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 Device configuration verify report.



networkSummaryThe network summary report provides a listing of routers and devices, including addresses and channels used.

Figure 8-26 Network summary view.

readMemory 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.


8–31

Chapter 8 Niagara LonWorks ServiceLonWorks Service Properties

Status LineA 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.

LonWorks Service PropertiesThe 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 TabAll 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

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.

Engineering Properties

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.



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 TabPolling 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.


8–33


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 TabPolling 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 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.



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) PropertiesPolling 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 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.


8–35


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 Standard output showing network variable updates (netmgmtDebug = True).

Caution 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.



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 TablonCommDebugOn: 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.


8–37

Chapter 8 Niagara LonWorks ServiceLonWorks Service Commands

Figure 8-30 Standard output showing NV updates (lonCommDebugOn = True).

Caution 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.

LonWorks Service CommandsThe Commands menu for the LonWorks service includes the following:

• dump• bind• find• enAuth (Enable Authentication)• disAuth (Disable Authentication)

dumpThe 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.

bindAn alternate means of binding links between nodes. Performs the same operation as the Refresh command on the LON Link Manager view.



findEquivalent to the Find command within the Device Manager.

enAuthEnable authentication. Enables authentication for all nodes on the network (sets the LonWorksService property “authenticate” (Netmgmt, Engineering tabs) to True.

disAuthDisable authentication. Disables authentication for all nodes on the network (sets the LonWorksService property “authenticate” (Netmgmt, Engineering tabs) to False.


8–39




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

IntroductionThe 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 ContainerThe 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.

9–1

Chapter 9 Niagara LonWorks Tree StructureLocalLonDevice (LLD)

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.

LocalLonDevice (LLD)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.



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 PropertiesThe 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.


9–3


Figure 9-2 Real-time status of each linked NV is shown on the LocalLonDevice Status tab.

Config 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).



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.


9–5

Chapter 9 Niagara LonWorks Tree StructureLonTemp 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 LocalLonDeviceIf 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 ContainerThe 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.


Chapter 9 Niagara LonWorks Tree StructureLocal Library

Local LibraryFigure 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.


9–7

Chapter 9 Niagara LonWorks Tree StructureLocal 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.



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 PropertiesEach 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 TabThe 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, subnet/node address, location, Neuron ID, Program ID, and many of the read only structures contained in the device.

10–1

Chapter 10 Niagara LonWorks Shadow ObjectsShadow Object Properties

Figure 10-1 General engineering properties.

Node TabThe 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 TabThe 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



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 Real-time status of each NV in the controller can be found on its Status tab.

Config Tab Displays NCI values that are used to configure the node (Figure 10-3).


10–3


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 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.


Chapter 10 Niagara LonWorks Shadow ObjectsShadow 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.

Shadow Object CommandsThe Commands menu for a LonWorks shadow object includes the following:

• fetch• upload and download• dump• enableCmd and disableCmd• wink• readProperty


10–5

Chapter 10 Niagara LonWorks Shadow ObjectsShadow Object Commands

fetchRefreshes 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.

uploadTakes what is in the controller and loads it into the shadow object—all the network variables and configuration data.

downloadWrites configuration data from the shadow object (in the station database) to the device in the field

dumpThe 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.

resetPerforms a software reset of the node.

enableCmdEnables the device in the station database—opposite of the Disable command.

disableCmdDisables 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.

winkWinks the device in the field.

readPropertySimilar to the Fetch command, but reads a single variable.



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 ObjectWhen 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.

11–1

Chapter 11 Niagara LonWorks Dynamic DeviceDynamic Device Properties

Dynamic Device PropertiesWhen 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 ManagerOnce 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 The LON Schema Manager view.


Chapter 11 Niagara LonWorks Dynamic DeviceLON 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.


11–3

Chapter 11 Niagara LonWorks Dynamic DeviceLON Schema Manager



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.

12–1

Chapter 12 Building Niagara LonWorks SolutionsPlanning Network Organization

Planning Network OrganizationPrior 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 RequirementsBefore 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.

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 Application Layer Interoperability Guidelines (078-0120-01C).


Chapter 12 Building Niagara LonWorks SolutionsPlanning Network Organization

Determine Station Database StructureOnce 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 DatabaseAlthough 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.


12–3

Chapter 12 Building Niagara LonWorks SolutionsLonWorks Network Installation

LonWorks Network InstallationCustomizing 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 NodeNodes 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


Chapter 12 Building Niagara LonWorks SolutionsLonWorks Network Installation

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 VariablesPhysically 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.

ConfigurationConfiguration 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).


12–5

Chapter 12 Building Niagara LonWorks SolutionsNetwork Installation Scenarios

Network Installation ScenariosThere 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).



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 Learning an Existing LonWorks Network.

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.


12–7


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 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.



CHAPTER 13
User Interface
This chapter contains the following main sections:

• General Information• Building a User Interface

General InformationIn 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 InterfaceAt 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.

13–1

Chapter 13 User InterfaceBuilding a 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 DataFigure 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 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.



Create the Necessary Logic to Expose Values and StatusUse the following features to expose real-time data.

Figure 13-2 Control logic to build a user interface around a LonWorks application.

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.

Run the BinaryOutput through the conversion object before linking it to the MNL-20.

Text box displays Boolean value after conversion object.

Text box displays space temperature.


13–3


Create the Necessary Logic to Push CommandsUse the following features to push control commands into the LonWorks controller.

Procedure 13-3 Create the Necessary Logic to Push Commands.

Step 1 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.

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.


A


PPENDIX A
Advanced LonWorks Procedures
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.

A–1

Appendix A Advanced LonWorks ProceduresResolving Duplicate Subnet/Node Address

Resolving Duplicate Subnet/Node AddressIf 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 NodeThis 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.

Niagara Release 2.3Niagara LonWorks Integration Guide Revised: December 16, 2002A–2

Appendix A Advanced LonWorks ProceduresDiscovering 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 UnconfiguredThis 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).

Discovering Nodes on Other DomainsThe 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.3Niagara LonWorks Integration Guide Revised: December 16, 2002 A–3

Appendix A Advanced LonWorks ProceduresDiscovering Nodes on Other Domains

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 DeviceProcedure A-3 Discover the working domain for a LonWorks device.

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 Example domain table for a LonWorks device.


Appendix A Advanced LonWorks ProceduresDevices 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 ServiceProcedure 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.


Appendix A Advanced LonWorks ProceduresDevices 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.


Appendix A Advanced LonWorks ProceduresWorking 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.

Working With RoutersBeginning 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 RoutersRouters 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 RepresentationIn 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.



Working with an Unmanaged Routed NetworkAn 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.



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 NetworkA 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 Example procedure to work with a managed routed network.

Step 1 Go to the LonDeviceManager and click Learn.

a. Do not check “Unmanaged devices.”

b. Click Apply.The learn progresses for several seconds.


Appendix A Advanced LonWorks ProceduresTroubleshooting 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.

Troubleshooting a LON DeviceThis 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 ErrorsThe 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.


Appendix A Advanced LonWorks ProceduresTroubleshooting a LON Device

Troubleshooting LonWorks Devices and Twisted Pair Networks

A future revision of this document may contain this information.

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.

Table A-1 Link Status Errors. (continued)

Status Meaning


A


PPENDIX B
SNVT Reference
This appendix explains LonWorks SNVTs, and includes these main sections:

• Standard Network Variable Types (SNVTs)• Niagara Shadow Objects• Working With SNVTs• Converting LonWorks Data Using Program Objects

Standard Network Variable Types (SNVTs)The following subsections are included:

• Network Variables• SNVTs• Data Types• Naming Convention• Engineering Units• Working With LonWorks Data

Network VariablesEchelon 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

B–1

Appendix B SNVT ReferenceStandard Network Variable Types (SNVTs)

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.

SNVTsNetwork 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.

Controller Controller

Switch Lamp

Network Variable Updates

Niagara Release 2.3Niagara LonWorks Integration Guide Revised: December 16, 2002B–2


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 TypesEach 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 Unsigned long

-32,768—32,767 Signed long

0—255 Unsigned short

-128—127 Signed short

An example of a fixed point SNVT is:

Scalar Types: Floating Point Numbers

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 number Measurement Data Type Size RangeSNVT_temp_p 105 Temperature Fixed point scalar

signed long2 bytes -273.17— +327.66

degrees C

SNVT SNVT number Measurement Data Type Size RangeSNVT_power_f 57 Power Floating point scalar 4 bytes -1E38— 1E38 watts

Niagara Release 2.3Niagara LonWorks Integration Guide Revised: December 16, 2002 B–3


Scalar Types: Enumerated Values

Some SNVTs have enumerated values, where a single byte represents a value from an enumerated list.

An example of an enumerated SNVT is:

Enumeration Definitions (occup_t):

Structured Types

Some SNVTs are structured values, meaning they have more than one data field.

An example of a structured SNVT is:

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 ConventionThe 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 UnitsMost 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.

SNVT SNVT number Measurement Data Type Size RangeSNVT_occupancy 109 Occupancy Enumeration scalar 1 byte -1E38— 1E38 watts

Value Identifier Notes0 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

0xFF OC_NUL Value not available

SNVT SNVT number Measurement Data Type Size FieldsSNVT_temp_setpt 106 Temperature

setpointsStructure 12 bytes Occupied_cool

Standby_coolUnoccupied_coolOccupied_heatStandby_heatUnoccupied_heat



Working With LonWorks DataThis 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 Type Range

Character

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



How Data is Represented on the Wire

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.

Discrete number

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

Table B-1 LonWorks Data Types. (continued)

Number Category Type Range



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 UnitsSNVT_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 All raw temperature values are stored in degrees C and conversion is the responsibility of the network management tool or user interface.

Displayed Value Raw Value

0 0

0.01 1

0.02 2

0.03 3

... ...

100.0 10,000



Figure B-3 Converting SNVT_temp_p to displayed engineering units.

Converting SNVT_lev_percent to Displayed Engineering UnitsSNVT_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.

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.

Displayed Value Raw Value

0 0

0.005 1

0.010 2

0.015 3

... ...

100.0 10,000


Appendix B SNVT ReferenceNiagara Shadow Objects

Figure B-4 Converting SNVT_lev_percent to Displayed Engineering Units

Niagara Shadow ObjectsManufacturer-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.

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).



Shadow Object PropertiesEach 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, subnet/node address, location, Neuron ID, Program ID, and many of the read only structures contained in the device.

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.



StatusDisplays 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.

ConfigDisplays each NCI that is used to configure the node (Figure B-7).



Figure B-7 NCIs can be found on the controller's Configuration tab.

Lon PropsDisplays 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 LonProps view of a node.



Getting Some HelpThe 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 Context sensitive help for a shadow object.

Step 3 Click on the data type hyperlink. The index of the Property Reference help file is displayed (Figure B-10).



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.



Figure B-12 Link between properties with matching data types.

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 FilesOn 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.

nviSetPoint input network variable exposed on the shadow object for the Honeywell W7751F controller.

Click on lonworks to review the LonWorks documentation.



Local LibraryOpen 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 FilesOpen 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).



Figure B-15 General documentation for Circon LonWorks devices.

SNVT Master ListThe 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.


www.lonmark.org

http://www.lonmark.org/products/snvtfile.htm


Figure B-16 Screen views while accessing the SNVT Master List.


Appendix B SNVT ReferenceWorking With SNVTs

Working With SNVTsThis 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 An enumerated list of integer values that represent the 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 An enumerated list of integer values that represent the 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.



SNVT_temp_pSNVT temperature. Measures temperature.

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_percentLevel percent. Measures percent level or humidity.

Figure B-17 Example control logic with NV implemented with SNVT_lev_percent.

Type Category Measurement Range Index

SNVT_temp_p Signed Long Temperature -273.17 ... +327.66degrees Celsius (°C)

(resolution = 0.01 °C)

32,767 value (0x7FFF) is invalid data

105


SNVT_lev_percent Signed Long Humidity -163.84% ... 163.83%(resolution = 0.005)

81

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 sInoutput boolean boolOutoutput String strOut

if sin.value> 0boolOut=truestrOut=”On”

elseboolOut=falsestrOut=”Off”

endif

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).

A Comparison object uses less resource counts than a Program object, plus has “activeInactiveText” for showing the Boolean state.



Practice Using SNVT_lev_percentCreate 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_discLevel discrete. An enumerated list that accommodates integers that have an enumeration type definition.

Figure B-18 Example control logic with NV implemented with SNVT_lev_disc.


SNVT_lev_disc 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 device0 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

Mouse over the property tag and find that the property name is nvoSatLevDisc1 of type LonLevDiscEnum.

SNVT type is SNVT_lev_disc.




Practice Using SNVT_lev_discUsing 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_switchSNVT 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).

Figure B-19 Example control logic with NV implemented with SNVT_switch.


SNVT_switch 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)

Mouse over the property tag and find that the property name is nvoSatSwitch1 of type SnvtSwitchValueType.

SNVT type is SNVT_switch.


The exposed property types include:

FloatStatusType—expresses 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).

The SnvtSwitchDemux object is used to convert the structured SNVT into its component values.



Practice Using SNVT_switch

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.

Notes • 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_statusHVAC 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.


SNVT_hvac_status Structure HVAC status See Structure (Table B-4) 95

Table B-4 SNVT_hvac_status (data fields).

Field Measurement Category / Units Range Notes

mode HVAC mode Enumeration See Table B-5, enums —

heat_output_primary Primary heat output SNVT_lev_percent -163.83 ... 163.83%

Each of these outputs is percentage of full scale.

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 0 ... 1 1 means unit in alarm

Table B-5 Enumerations for mode in SNVT_hvac_status, SNVT_hvac_mode.


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)



Figure B-20 Example control logic with NV implemented with SNVT_hvac_status.

SNVT_hvac_modeHVAC mode. An enumerated list that accommodates integers that have an enumeration type definition.

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

Table B-5 Enumerations for mode in SNVT_hvac_status, SNVT_hvac_mode. (continued)


Mouse over the property tag and find that the property name is nvoUnitStatus of type SnvtHvacStatusType.

SNVT type is SNVT_hvac_status.


Use a SNVT demux object of type SnvtHvacStatusDemux to break down the structured SNVT into its component values.

A standard Comparison object can be used to convert the fanOutput (FloatStatus type) to a BooleanStatus type.


SNVT_hvac_mode Enumerated HVAC mode See Enum List (Table B-6) 112

Table B-6 Enumerations (SNVT_hvac_mode, also is mode in SNVT_hvac_status).


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)



Figure B-21 Example control logic with NV implemented with SNVT_hvac_mode.

Practice Using SNVT_hvac_modeUsing a Honeywell W7750A controller, create the control logic necessary to manually switch the application mode for which that controller operates.

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


Table B-6 Enumerations (SNVT_hvac_mode, also is mode in SNVT_hvac_status).


Program object converts the MSO integer output to LonHvacModeEnum enumerations, with this code:

input IntegerStatusType sInoutput LonHvacModeEnum snvtOut

if sIn.value==0snvtOut=LonHvacModeEnum.auto

elseif sIn.value==1snvtOut=LonHvacModeEnum.heat

elseif sIn.value==2snvtOut=LonHvacModeEnum.morning_warmup

elseif sIn.value==3snvtOut=LonHvacModeEnum.cool

elseif sIn.value==4snvtOut=LonHvacModeEnum.night_purge

elseif sIn.value==5snvtOut=LonHvacModeEnum.pre_cool

elseif sIn.value==6snvtOut=LonHvacModeEnum.off

elseif sIn.value==7snvtOut=LonHvacModeEnum.test

elseif sIn.value==8snvtOut=LonHvacModeEnum.emergency_heat

elseif sIn.value==9snvtOut=LonHvacModeEnum.fan_only

elseif sIn.value==10snvtOut=LonHvacModeEnum.free_cool

elseif sIn.value==11snvtOut=LonHvacModeEnum.ice

endif

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.

MSO property sheet, Visual tab.

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.



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_overidHVAC 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.


SNVT_hvac_overid Structure HVAC override See Structure (Table B-7) 95

Table B-7 SNVT_hvac_overid (data fields).


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 Enumerations for state in SNVT_hvac_overid.


0 HVAC_OFF Not overridden

Note: Next 7 values apply to all devices/groups

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 Override to position = 0%

6 HVAC_MINIMUM Override to configured minimum

7 HVAC_MAXIMUM Override to configured maximum

8—16 <not used> Note: Next 7 values apply to first device/group

17 HVAC_POSITION_1

18 HVAC_FLOW_VALUE_1 Override flow in liters/sec

19 HVAC_FLOW_PERCENT_1 Override flow percentage

20 HVAC_OPEN_1 Override to position = 100%

21 HVAC_CLOSE_1 Override to position = 0%

22 HVAC_MINIMUM_1 Override to configured minimum

23 HVAC_MAXIMUM_1 Override to configured maximum

24—32 <not used> Note: Next 7 values apply to second device/group




Practice Using SNVT_hvac_overidIn some future document revision, a practice exercise may be included.

SNVT_hvac_emergSNVT HVAC emergency. An enumerated list that accommodates integers that have an enumeration type definition.

Figure B-22 shows example usage of SNVT_hvac_emerg.

33 HVAC_POSITION_2

34 HVAC_FLOW_VALUE_2 Override flow in liters/sec

35 HVAC_FLOW_PERCENT_2 Override flow percentage

36 HVAC_OPEN_2 Override to position = 100%

37 HVAC_CLOSE_2 Override to position = 0%

38 HVAC_MINIMUM_2 Override to configured minimum

39 HVAC_MAXIMUM_2 Override to configured maximum

40—48 <not used> —


Table B-8 Enumerations for state in SNVT_hvac_overid. (continued)



SNVT_hvac_emerg Enumerated HVAC Emergency Mode

See Enum List (Table B-9) 103

Table B-9 Enumerations for HVAC emergency mode.


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 Example control logic with NV implemented with SNVT_hvac_emerg.

SNVT_temp_setptSNVT 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).

Mouse over the property tag and find that the property name is nviEmergCmd of type LonHvacEmergencyEnum.

SNVT type is SNVT_hvac_emerg.


Program object converts the MSO integer output to LonHvacModeEnum enumerations, with this code:

input IntegerStatusType sInoutput LonHvacEmergencyEnum snvtOut

if sIn.value==0snvtOut=LonHvacEmergencyEnum.normal

elseif sIn.value==1snvtOut=LonHvacEmergencyEnum.pressurize

elseif sIn.value==2snvtOut=LonHvacEmergencyEnum.depressurize

elseif sIn.value==3snvtOut=LonHvacEmergencyEnum.purge

elseif sIn.value==4snvtOut=LonHvacEmergencyEnum.shutdown

// elseif sIn.value==5// snvtOut=LonHvacEmergencyEnum.fireelseif sIn.value==255endif


MultistateOutput (MSO) object.

The MSO generates an integer value.

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 Structure Temperature setpoints See Structure (Table B-10) 106

Table B-10 SNVT_temp_setpt (data fields).


occupied_cool Occupied cooling setpoint SNVT_temp_p -273.17 ... 327.66 °C

(for each):Resolution of 0.01°C0x7FFF value (32,767) means invalid data

standby_cool Standby cooling setpoint SNVT_temp_p -273.17 ... 327.66 °C

unoccupied_cool Unoccupied cooling setpoint SNVT_temp_p -273.17 ... 327.66 °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

unoccupied_heat Unoccupied heating setpoint SNVT_temp_p -273.17 ... 327.66 °C



Figure B-23 Example control logic with NV implemented with SNVT_temp_setpt.

Figure B-24 Config properties for min and max values define user-adjustable limits.

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.


Conversion object SnvtTempSetptCmd allows right-click command access to change NCI setpoint values.

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).

If you configure max and min SetptValues, the JDE provides a slider bar for the user to adjust setpoint values.



Practice Using SNVT_temp_setptUsing 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_occupancySNVT occupancy. An enumerated list that accommodates integers that have an enumeration type definition.

See Figure B-25 for two examples using SNVT_occupancy.


SNVT_occupancy Enumerated Occupancy See Enum List (Table B-11) 109

Table B-11 Occupancy enumerations.


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

0xFF OC_NUL Value not available



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.


A BoolToOccupancy conversion object is used to convert the BO statusOut to the LonOccupancyEnum data type.

The BinaryOutput (BO) provides the means to override a scheduled occupancy time.

NvoOccCmd provides a means to expose the occupancy status.

This Program object takes the integer value generated by the MSO and converts it to its corresponding LonOccupancyEnum value, using the following code:

input IntegerStatusType sInoutput LonOccupancyEnum snvtOutif sIn.value==0

snvtOut=LonOccupancyEnum.occupiedelseif sIn.value==1

snvtOut=LonOccupancyEnum.unoccupiedelseif sIn.value==2

snvtOut=LonOccupancyEnum.bypasselseif sIn.value==3

snvtOut=LonOccupancyEnum.standbyelseif sIn.value==255

snvtOut=LonOccupancyEnum.nullendif




Practice Using SNVT_occupancyUsing 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_timeThis SNVT should not be used for new applications. Use SNVT_time_stamp.

SNVT_time_stampSNVT time stamp. A structure that can be used to display and/or change date and time.


Practice Using SNVT_time_stampIn some future document revision, a practice exercise may be included.


SNVT_time_stamp Structure Time Stamp See Structure (Table B-12) 84

Table B-12 SNVT_time_stamp (data fields).


year Year Year 0 ... 3,000 (years AD) 0 means year not specified65,535 represents null date

month Month Month 0 ... 12 0 means month not specified

day Day Day 0 ... 31 0 means day not specified

hour Hour Hour 0 ... 23 24-hour format used

minute Minute Minute 0 ... 59

second Second Second 0 ... 59


Appendix B SNVT ReferenceConverting 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 ObjectsAs 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 ObjectsMany 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.



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.



A Simple Example: FloatStatusType to BooleanConsider 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.



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.



Other Examples

IntegerStatusType to LonOccupancyEnumConsider 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.

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, and2) Between the output of the Program object and the binding property of the GxBoolean object. The resulting logic looks similar to that shown here.



Notes for Creating the Program ObjectThe 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.


1. Create the Program object using the necessary logic. (Figure B-31)2. Link the MSO, Program, and shadow objects. (Figure B-32)



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.

The resulting logic looks similar to that shown here.



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:

Notes for Creating the Program ObjectThe 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).

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.



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.

Click on the Subsystem Reference.

Note the enumeration type used (LonSwitchStateEnum), and then click on the tridiumx.lonworks Documents link.

Scroll down the Table of Contents to find the enumeration, and click on its link.



• 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).



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.

The resulting logic looks similar to that shown here.




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 350Richmond, Virginia 23233Attention: 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 FormDocument Title: Niagara LonWorks Integration Guide

Document Version: Niagara Release 2.3

Page # Problem Found or Suggested Change

Your Name:

Your Company:

mailto:[email protected] ?Subject=Niagara%20LonWorks%20Integration%20Guide%20R%202.3