Day 1 E-Link Overview - Version 1

Welcome to E-LINK BOOT CAMP
Day 1
Theory of Operation
BACnet Technology Overview
Modbus Technology Overview
LON Technology Overview
N2 Technology Overview
Support of the E-Link Files
Questions
1
Theory of Operation
2
E-LINK Specification Reference
•• E-Link
E-Link Technical
Technical Spec.docx
Spec.docx
E-Link Theory of Operation

3
History – York Products (1st Generation)
• York MicroGateway
FSP MicroGateway ISN Gateway Era
VT100
E2
Adjustable User
ACII Script
Parameters
MIcroGateway
Configuration
Tool EPROM (OS)
ISN
BAS
- OR -
N2
YorkTalk 1
YorkTalk 2
YorkTalk 3
Equipment
ASCII

4
History – York Products (2nd Generation)
FSP MicroGateway Quick Start Gateway Era
VT100
E2 Node Switch
Adjustable User (Configuration)
ACII Script
Parameters
MIcroGateway
Configuration
Tool EPROM (OS)
ISN
BAS N2
- OR -
YorkTalk 1 MS/TP
YorkTalk 2
YorkTalk 3 Modbus RTU
ASCII Equipment

5
History – York Products (3rd Generation)
FSP MicroGateway RMD Gateway Era
VT100
E2 Node Switch
Adjustable User (Configuration)
ACII Script
Parameters
MIcroGateway RMD
Remote BAS
Configuration CLIP
EPROM (OS) Monitoring
Tool
ISN
BAS N2
- OR -
MS/TP
YorkTalk 1
Modbus RTU
YorkTalk 2
YorkTalk 3 Equipment
ASCII

6
History – York Products (Final Generation)
– 4th Generation
FSP MicroGateway ConneXsys Gateway Era
VT100
Flash Node Switch
Object Engine (Configuration)
IcE
Configuration
Tool ISN
EPROM (BIOS, OS)
OCS 1.0 N2
- OR -
Advantage
MS/TP
Modbus RTU
BAS
YorkTalk 1 RMD
YorkTalk 2
YorkTalk 3 Equipment
ASCII

7
History – E-LINK (Johnson Controls 1st Generation)
• Johnson Controls E-LINK
FSP E-LINK Switch Bank “A”

Equipment Protocol
VT100 Flash Switch Bank “B”
Bios BAS Protocol
IcE OS Switch Bank “C”

Configuration Addr and Terminal
Tool Object Engine
ISN
N2
RMD MS/TP
BAS
Protocessor
YorkTalk 2 Modbus RTU
YorkTalk 3
LON FTT10
MS/TP
Equipment
Modbus RTU

8
What is an E-Link?
• Johnson Controls Equipment Link (E-Link)
– A Communications device that provides a connection
between specific YORK equipment and standard open
BAS protocols
– Replacement for the YORK MicroGateway*
– Available since December 2007
– Board set manufactured and factory tested at the JCI
Reynosa, Mexico Plant
* E-Link does not support ISN, ASCII , York Talk 1, or Modbus via RS-232 protocols

9
Design Features
• General
– Variety of protocol options in a single device
– Preconfigured with standard YORK equipment profiles
– Commissioning via DIP switches and User Reports
– Multiple BAS ports - operate concurrently
– Non-volatile flash memory
– Built in Terminal Interface via RS485
• Hardware
– Physical dimensions and power requirements are same as
YORK MicroGateway
– Removable connectors
– Diagnostic LEDs
– On-board network termination

10
Agency Listings
• US
– UL 916
– FCC Part 15 Conducted and Radiated
• European
– 2004/108 EC
– EMC Directive: EN61000-6-2, EN61000-6-4 2006/95 EC
– Low Voltage Directive: EN12100-2-6, EN60204-1-4 to 1-18
• BACnet Testing Laboratory
– BACnet Application Specific Controller (B-ASC) July 2008 at
Version 2_3_2_174 for the YK-ELINK100-00 and YK-
ELINKE00-0
• LonMark
– ????? (no longer visible on the LonMark certified web page)

11
Communication Protocols
• YORK Equipment Protocols – Profile Quick Starts

– BACnet MS/TP (RS-485) – YPAL Equipment Support
– York Talk 2 (RS-485) – Generic YT2 Support
– Modbus RTU (RS-485) – Generic Wuxi STC Equipment Support
– York Talk 3 (RS-232) – OptiView-I Equipment Support
• Open Network Protocols – Protocol Quick Starts

– BACnet MS/TP (RS-485)
– N2 (RS-485)
– Modbus RTU (RS-485)
– LON (FTT10)

12
Functional Summary
• Three Primary User Cases for E-LINK Development

– To replace the current range of MicroGateways
– To provide BACnet enabled equipment with
connectivity to other protocols
– To provide Modbus RTU enabled equipment
connectivity to other protocols.

13
Functional Summary (User Case 1)
• User Case 1– MicroGateway Replacement

– In this application the E-Link interfaces with a York
Chiller using F54
N2
F54 York MSV
York Talk Request Talk
York Equipment MS/TP
MASTER AV
SLAVE
York Talk Response Modbus RTU
BV
LON FTT10

14
• User Case 2– BACnet MS/TP Enabled Equipment

– In this application the E-Link interfaces with any
BACnet enabled equipment by using a combination of
F65, F28 and F29
N2
F65 MSV
BACnet Request Acquisition
York Equipment Modbus RTU
MASTER AV
BACnet Response LON FTT10
BV
BAC
net W
BAC rite
net
Wri F28Transfer
te
F29 Transfer

15
• User Case 3– Modbus RTU Enabled Equipment

– In this application the E-Link interfaces with any
Modbus enabled equipment using F66
N2
F66 MSV
Modbus Request Modbus
York Equipment MS/TP
RTU AV
SLAVE MASTER
Modbus Response LON FTT10
BV

16
Architecture
Flash
Port 1 – Isolated RS485
SDRAM
(32-Bit data bus)
ColdFire
Port 3 – RS485
DUART
Port 2A – RS485 Reset
Port 2B – RS232
Port 4 – TTL
Node Quick Quick

MAC Start A Start B Protocessor
24-VAC or
12-VDC Half Wave Circuit IPU-II
Power IN
+5 VDC Switching Protocessor
Regulator and SIM

17
Ordering Options
Ordering Information
Part Number Description

YK-ELNK100-0 E-Link Gateway with serial outputs
(BACnet MS/TP, Modbus RTU, and N2)
YK-ELNK101-0 E-Link Gateway with LON output
YK-ELNKE00-0 E-Link Gateway with serial outputs in
an enclosure
YK-ELNKE01-0 E-Link Gateway with LON output in an
enclosure
YK-ELNKOLK-0 OptiView / Latitude installation kit
YK-ELNKSTK-0 IPU-II Panel installation kit
(Not available in Europe)

18
Hardware Installation Options
The two installation options:
1. E-Link board Set.
– Used for YK, YT, YS, YR, YD OptiView and YCIV / YCAV equipment.
– In most instances, can be used as a direct MicroGateway replacement.
2. Enclosure with E-Link Board Set and Power Supply
– Used for all other YORK equipment supported by the E-Link,
– The YCAV / YCIV panels may use this due to VSD noise interference with BAS Protocols
(LON is highly susceptible). FSC has a procedure to follow in order to determine the need
of the enclosure installation.
YK Chiller
YPAL (eco2) unit
YCAV Chiller

YCAS Chiller 19
OptiView/Latitude Installation Kit
OptiView/Latitude Installation Kit
OptiView-I Panel
Latitude Panel
20
IPU-II Installation Kit
IPU-II Installation Kit
YCWL
York Talk 2
Panel
YCAL
YLAA

21
YLPA
Enclosure Installation Option
115 VAC / 230 VAC Supply Power
Com Shield Termination

22
Board Components
BDM Programming Header –
Power LED Status LED 100
(Older Board Sets Have Pins)
BaseT
Ethernet
RJ11
System Interface Module (SIM)
LON Interface (optional)

Intermediate Processor Unit (IPU-II)
24VAC
BAS
Power
Port4
12VDC FTT10
Power BAS Equipment Equipment BAS / (isolated)
Port1 Port2A Port2B RMP
RS-485 RS-485 RS-232 Port3
(isolated) RS-485
E-Link Theory of operation

23
Communication Ports
•Port 1 and Port 4 - Designated for BAS networking
•Port 3 - Auxiliary Remote Monitoring BAS Port / control and debugging
•Port 2 - Equipment connection
Port 2 TX / RX LED’s
Po
rt
1
TX
/RX
LE
D’
s
Port1 Port2A Port2B Port3 Port4

RS-485 RS-485 RS-232 RS-485 FTT10
BACnet MS/TP York Talk II York Talk III Modbus RTU LON
Modbus RTU BACnet MS/TP N2
N2 Modbus RTU BACnet MS/TP
Terminal
24
Protocessor Daughter Board Details
Notes:
LA LED – Heartbeat (continual sequenced flash)
TX /RX LED – LON Trunk Activity (intermittent

flashing as requests are received and replies are
sent on the LonTalk BUS)
Commission LED – Flashing RED device is not

commissioned, off device is commissioned.
PWR LED– solid green as soon as power is

applied
GPIO5 LED – solid green as soon as BACnet

communication is established with the E-LINK
Ethernet Service Port – Has an Ethernet Link

LED and a network activity LED. This port is
used to load the XIF files to the Protocessor.

25
Quick Start Commissioning
• MAC Address - Allowable range: 1-127. “T” switch ON supports Terminal.
• APP Group A - Selects equipment profile (QS1 thru QS63)
• APP Group B - Selects BAS output protocol (QS1 thru QS15)
Pushbutton activates Quick Start

selections
Diagnostics
Power LED – On Solid Green status
when power applied – status of
the 24 Volt Supply Power input
from the SIM board.
Status LED – RED Sequenced

status (see next slide for details)

26
Status LED Sequencing
An equipment to E-LINK communication fault is presently

occurring

27
How is the E-LINK Deployed in the Field?
The following information

depicts the E-LINK support
of the York equipment
-Micro Board, Quick Start,
Installation, Power and
Communication Wiring

28
York Equipment

29
Equipment Points Lists
All YORK Chillers use the

same standard equipment
points list format
(aka York Talk Points List)

30
YCAS Air-Cooled Screw Chiller (Master) Style F YORK TALK 2 Micro Board: 031-01095-xxx
Item Ref. Version Date YORK P N Checksum Baud COMMENTS
1 C.ACS.09.03 11/15/00 031-01798-001 D7C9 4800 DXST 2 Compressor Micro Board 031-01095-002 System 1 and 2
2 C.A06.09.03 031-01798-001 E10C 4800 DXST 2 Compressor Micro Board 031-01095-002 System 1 and 2
3 C.ACS.09.02 031-01798-001 D87E 4800 DXST 2 Compressor Micro Board 031-01095-002 System 1 and 2
4 C.A32.09.02 031-01798-001 0483 4800 DXST 2 Compressor Micro Board 031-01095-002 System 1 and 2
7 C.ACS.09.01 031-01798-001 F350 4800 DXST 2 Compressor Micro Board 031-01095-002 System 1 and 2
8 C.ACS.10.02 11/15/00 031-01798-002 67ED 4800 DXST 3 and 4 Compressor Micro Board 031-01095-002 System 1 and 2
9 C.A01.10.02 031-01798-002 E661 4800 DXST 3 and 4 Compressor Micro Board 031-01095-002 System 1 and 2
10
Use ASCII page column for interfaces utilizing an ASCII XL Translator or MicroGateway to communicate to a chiller LINC
ENG ASCII GPIC York Talk ISN LINC York Talk N2

PAGE PAGE Object Point Descriptive Character Address POINT LIST CODE: S = STANDARD O = OPTIONAL N = NOT AVAILABLE
REF REF Type Type Text Position POINT LIST DESCRIPTION 1 2 3 4 5 6 7 8 9 10
P03 P01 A. Control ADF 1 Setpoint S S S S S S S S S
P04 P02 A. Control ADF 2 ISN Current Limit S S S S S S S S S
P05 P03 A. Control ADF 3 Hot Setpoint (Heat Recovery Unit) S S S S S S S S S
P06 P04 A. Control ADF 4
P07 P05 D. Control BD 1 Start / Stop Command S S S S S S S S S
P08 P06 D. Control BD 2
P09 P07 D. Control BD 3
P10 P08 D. Control BD 4 History Buffer Request S S S S S S S S S
P11 P09 A. Monitor 8 - 11 ADF 5 Leaving Chilled Liquid Temp S S S S S S S S S
P12 P10 A. Monitor 12 - 15 ADF 6 Return Chilled Liquid Temp S S S S S S S S S
Mixed Chilled Liquid Temp (Standard Unit) O O O O O O O O O
P13 P11 A. Monitor 16 - 19 ADF 7 Hot Liquid Temp (Heat Recovery Unit) S S S S S S S S S
P14 P12 A. Monitor 20 - 23 ADF 8 Sys 1 Suction Temperature S S S S S S S S S
P15 P13 A. Monitor 24 - 27 ADF 9 Sys 1 Discharge Temperature S S S S S S S S S
P16 P14 A. Monitor 28 - 31 ADF 10 Ambient Air Temperature S S S S S S S S S
P17 P15 A. Monitor 32 - 35 ADF 11 Sys 1 Oil Temperature S S S S S S S S S
P18 P16 A. Monitor 36 - 39 ADF 12 Sys 1 Oil Pressure S S S S S S S S S
P19 P17 A. Monitor 40 - 43 ADF 13 Sys 1 Suction Pressure S S S S S S S S S
P20 P18 A. Monitor 44 - 47 ADF 14 Sys 1 Discharge Pressure S S S S S S S S S
P21 P19 A. Monitor 48 - 51 ADF 15 Sys 1% Full Load Amps S S S S S S S S S
P22 P20 A. Monitor 52 - 55 ADF 16 Sys 1 Total Run Hours S S S S S S S S S
P23 P21 A. Monitor 56 - 59 ADF 17 Sys 1 Total Number of Starts S S S S S S S S S
P24 P22 A. Monitor 60 - 63 ADF 18 Sys 1 Anti-Recycle Timer S S S S S S S S S
P25 P23 A. Monitor 64 - 67 ADF 19 Anti-Coincident Timer S S S S S S S S S
P26 P24 A. Monitor 68 - 71 ADF 20 Sys 2 Oil Temperature S S S S S S S S S
The complete set of equipment points lists is available on the Portal

31
YK OptiView with SSS YORK TALK 3 Micro Board: 031-01730 or 031-02430
Item Ref. Version Date YORK P N Checksum Baud COMMENTS
1 C.MLM.01.00 19.2K If data is requested in Metric mode, must use version C.MLM.01.05d.203 or later
2 C.MLM.01.05D.203 425C 19.2K temporary fix for Metric mode requirement. Problem was with digital points.
3 C.MLM.01.06.200 B918 19.2K adds missing data points and status codes; supports the Property Data Units feature.
4 C. MLM .01. 14 .111 19.2K Has overlapping warning code defects. Chiller engineering is corrrecting
5 C.MLM.01.16.100 19.2K Overlapping warning code defects fixed.
6
7
8
9
10
Use ASCII page column for interfaces utilizing an ASCII XL Translator or MicroGateway to communicate to a chiller LINC
ENG ASCII GPIC York Talk ISN LINC York Talk N2

PAGE PAGE Object Point Descriptive Character Address POINT LIST CODE: S = STANDARD O = OPTIONAL N = NOT AVAILABLE
REF REF Type Type Text Position POINT LIST DESCRIPTION 1 2 3 4 5 6 7 8 9 10
P03 P01 AV.1 A. Control LCHL.SP ADF 1 Leaving Chilled Liquid Setpoint-Selected
P04 P02 AV.2 A. Control %CURR.LIMIT ADF 2 Motor Current Limit Setpoint
P05 P03 A A. Control ADF 3
P06 P04 A A. Control ADF 4
P07 P05 BV.1 D. Control START.STOP BD 1 Remote Start/Stop [Stop/Start]
P08 P06 B D. Control BD 2
P11 P09 AI.1 A. Monitor LCHL.TEMP 8 - 11 ADF 5 Leaving Chilled Liquid Temperature
P12 P10 AI.2 A. Monitor RCHL.TEMP 12 - 15 ADF 6 Return Chilled Liquid Temperature
P13 P11 AI.5 A. Monitor EVAP.PRESS 16 - 19 ADF 7 Evaporator Pressure
P14 P12 AI.6 A. Monitor COND.PRESS 20 - 23 ADF 8 Condenser Pressure
P15 P13 AV.14 A. Monitor OIL.DP 24 - 27 ADF 9 Oil Pressure Differential
P16 P14 AI.4 A. Monitor RCNDL.TEMP 28 - 31 ADF 10 Return Condenser Liquid Temperature
P17 P15 AI.3 A. Monitor LCNDL.TEMP 32 - 35 ADF 11 Leaving Condenser Liquid Temperature
P18 P16 AI.11 A. Monitor % FLA 36 - 39 ADF 12 Motor Current Percent FLA
P19 P17 AI.16 A. Monitor SSS.PHA.CURR 40 - 43 ADF 13 Solid State Starter Phase A Current
P20 P18 AI.17 A. Monitor SSS.PHB.CURR 44 - 47 ADF 14 Solid State Starter Phase B Current
P21 P19 AI.18 A. Monitor SSS.PHC.CURR 48 - 51 ADF 15 Solid State Starter Phase C Current
P22 P20 AI.13 A. Monitor SSS.PHA.VOLT 52 - 55 ADF 16 Solid State Starter Phase A Voltage
P23 P21 AI.14 A. Monitor SSS.PHB.VOLT 56 - 59 ADF 17 Solid State Starter Phase B Voltage
P24 P22 AI.15 A. Monitor SSS.PHC.VOLT 60 - 63 ADF 18 Solid State Starter Phase C Voltage
P25 P23 AV.1 A. Monitor LCHL.SP 64 - 67 ADF 19 Leaving Chilled Liquid Setpoint-Selected
P26 P24 AV.20 A. Monitor % CURR.LIMIT 68 - 71 ADF 20 Motor Current Limit Setpoint-Selected
The complete set of equipment points lists is available on the Portal

32
Quick Start Equipment Profiles (Version 1.0)
Original Release APP GROUP A SWITCH (sw6, EQUIPMENT PROFILE QUICK STARTS OCSX_2_3_2_167.elf,
Version 1.0 sw5, sw4, sw3, sw2, sw1) ENG_0001_009.CNF,
Equipment Quick SSM4567JCF0003BL.JCF
Starts
Switch Settings 32 16 8 4 2 1 Functionality Release 2.2 LON XIF File

1 (YK SSS-IM-J) 0 0 0 0 0 1 YK with SSS Imperial J (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
2 (YK VSD-IM-J) 0 0 0 0 1 0 YK with VSD Imperial (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
3 (YT SSS-IM-J) 0 0 0 0 1 1 YT with SSS Imperial (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
4 (YT VSD-IM-J) 0 0 0 1 0 0 YT with VSD Imperial (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
5 (YSYR SSS IMJ) 0 0 0 1 0 1 YS / YR with SSS Imperial (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
6 (YK SSS-SI-J) 0 0 0 1 1 0 YK with SSS Metric (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
7 (YK VSD-SI-J) 0 0 0 1 1 1 YK with VSD Metric (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
8 (YT SSS-SI-J) 0 0 1 0 0 0 YT with SSS Metric (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
9 (YT VSD-SI-J) 0 0 1 0 0 1 YT with VSD Metric (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
10 (YSYR SSS-SIJ) 0 0 1 0 1 0 YS / YR with SSS Metric (York Talk-III) Rev J OPTIVIEW.XIF 11/9/2010
11 (YT2 1200-1) 0 0 1 0 1 1 York Talk II, 1200, 1 Section (York Talk-II) R2York2.XIF 11/9/2010
12 (YT2 4800-1) 0 0 1 1 0 0 York Talk II, 4800, 1 Section (York Talk-II) R2York2.XIF 11/9/2010
13 (YT2 4800-2) 0 0 1 1 0 1 York Talk II, 4800, 2 Sections (York Talk-II) R2York2.XIF 11/9/2010
14 (YD IM-J) 0 0 1 1 1 0 YD Imperial (York Talk-III) Rev J YDOPTI.XIF 11/9/2010
15 (YD SI-J) 0 0 1 1 1 1 YD Metric (York Talk-III) Rev J YDOPTI.XIF 11/9/2010
16 (YPAL_VER2) 0 1 0 0 0 0 ECO2 (BACnet MS/TP via an IPU-I) R2YPAL.XIF 11/9/2010

33
Release Version 2.0 APP GROUP A SWITCH EQUIPMENT PROFILE QUICK STARTS OCSX_2_3_2_211.elf,
Added Equipment (sw6, sw5, sw4, sw3, sw2, sw1) STD_02_00_30_211.CNF,
Quick Starts SSM4567JCF0006BL.JCF

17 (YK SSS-IM-K) 0 1 0 0 0 1 YK with SSS Imperial (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
18 (YK VSD-IM-K) 0 1 0 0 1 0 YK with VSD Imperial (York Talk-III) Rev K KVSDOPTI.XIF 11/9/2010
19 (YT SSS-IM-K) 0 1 0 0 1 1 YT with SSS Imperial (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
20 (YT VSD-IM-K) 0 1 0 1 0 0 YT with VSD Imperial (York Talk-III) Rev K KVSDOPTI.XIF 11/9/2010
21 (YRSN SSS IMK) 0 1 0 1 0 1 YS YR YN with SSS Imperial (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
22 (YK SSS-SI-K) 0 1 0 1 1 0 YK with SSS Metric (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
23 (YK VSD-SI-K) 0 1 0 1 1 1 YK with VSD Metric (York Talk-III) Rev K KVSDOPTI.XIF 11/9/2010
24 (YT SSS-SI-K) 0 1 1 0 0 0 YT with SSS Metric (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
25 (YT VSD-SI-K) 0 1 1 0 0 1 YT with VSD Metric (York Talk-III) Rev K KVSDOPTI.XIF 11/9/2010
26 (YRSN SSS SIK) 0 1 1 0 1 0 YS YR YN with SSS Imperial (York Talk-III) Rev K KSSSOPTI.XIF 11/9/2010
32 (YD IM-K) 1 0 0 0 0 0 YD Imperial (York Talk-III) Rev K KYDOPTI.XIF 11/9/2010
33 (YD IM-K) 1 0 0 0 0 1 YD Metric (York Talk-III) Rev K KYDOPTI.XIF 11/9/2010

34

27 (YST IM-K) 0 1 1 0 1 1 YST Imperial (York Talk-III) Rev K KYSTOPTI.XIF 11/9/2010
28 (YIA IM-K) 0 1 1 1 0 0 YIA Imperial (York Talk-III) Rev K KYIAOPTI.XIF 11/9/2010
29 (YST SI-K) 0 1 1 1 0 1 YST Metric (York Talk-III) Rev K KYSTOPTI.XIF 11/9/2010
30 (YIA SI-K) 0 1 1 1 1 0 YIA Metric (York Talk-III) Rev K KYIAOPTI.XIF 11/9/2010
Wuxi STC Metric (Modbus RTU - supporting YEWS-
31 (WXSTC SI-MOD) 0 1 1 1 1 1 STCWUXI.XIF I 11/9/2010
D1, YEAS, and YGAS Equipment)

35
34 (YMC2 IM-K) 1 0 0 0 1 0 YMC2 Imperial (York Talk-III) Rev K with Remote
YMC2.XIF 11/9/2010
Monitoring Port points list support
35 (YMC2 SI-K) 1 0 0 0 1 1 YMC2 Metric (York Talk-III) Rev K with Remote
YMC2.XIF 11/9/2010
Monitoring Port points list support
36 - 62 0 0 0 0 0 0 Future Release of Standard / Custom Profiles
63 1 1 1 1 1 1 Field Adjustments
NOTES:
1. Field Adjustments –
– User logs in with the “let me in” password
– The user copies the standard QS to QS63 via “copy f68snnn”
– Makes changes to QS63, changes saves to flash on reboot
2. Request for Custom Profiles –
– Contact SIS / Custom Solutions / Engineered Solutions for a quote.

36
Supported Equipment Micro Boards
Micro Board Number Equipment Native Language Equipment Model
031-02550 (IPU-II) York Talk 2 (4800 Baud), BACnet MS/TP, Modbus YCWL,YCUL,YCAL,YLAA,YCRL,YLPA
031-0195 York Talk 2 (4800 Baud) YCAS,YCWS, YCRS
031-02478 York Talk 2 (4800 Baud) YCAV, YCIV,YVAA
031-01065 York Talk 2 (1200 Baud) YIA,YPC,YG,YB, Older Revs of YK
031-01730 (OptiView-I) York Talk 3 (RS232) YN, OM Retrofits, CR
031-02430 (OptiView-I) York Talk 3 (RS232) YK, YT, YS, YR, YST, YIA,YD, YMC2
031-02496 (IPU-I) BACnet MS/TP, Modbus YPAL
York-003 (Wuxi) Modbus RTU YEWS-D1, YEAS, YGAS *
* NOTES:
1. Board Revisions for Wuxi STC Equipment Supported
– YEWS-D1 (RHSYEWSD1) V1.08 or higher
– YEAS (RHMASB) V1.06 or higher
– YGAS (RHMYGAS) V1.03 or higher

37
Equipment Connections
• Port 2A - Connects to equipment that uses York Talk II protocol, BACnet
MS/TP, or Modbus RTU via a 2-wire RS-485 connection.
• Port 2B - Connects to equipment using York Talk III protocol, via a 3-wire
RS-232 connection.
York Talk III – OptiView Panels
York Talk II – Single-line Micro Panels

38
031-02550 Micro Board and E-LINK Support
YK-ELNK100-0 (Standard BAS Protocols) Equip Protocol York Talk II, 4800 Baud
YK-ELNK101-0 (Standard BAS Protocols with LON Option) BAS Protocols MS/TP, Modbus, N2, LON
Points List YCAL_YCWL_YCUL_YLAA_YLUA

Small Tonnage Scroll (Rev K_03 )
BACnet List BACnet Yorktalk Points Map .xls

Dated 12/5/2011
See the following slides for Modbus List Elink Modbus Data Map
(extension) Rev_K_03
E-LINK “in Panel” LON List LON Data Map ELINK Rev_J.03.xls
Installation per equipment LON XIF File R2York2.XIF 11/9/2010
type. MSV Resource File N/A
QS - Imperial 12 (1 Section)
13 (2 Sections)
YCWL/YCRL
Imperial QS 2, 3, 4
Resource File
IPU-II York Talk 2 Panel QS-Metric Not Supported

YK-ELNKSTK-0 Installation Kit Metric QS N/A
Resource File
YCAL
YLAA
YCUL
YLPA
39
031-02550 E-LINK Equipment Panel Installation YCAL-D/E, YLAA
YCAL
YLAA
York Talk 2
Panel

40
031-02550 E-LINK Equipment Panel Installation YCAL-C, YCWL,
YCUL-C
YCWL
YCAL
York Talk 2 YCUL

Panel

41
031-02550 Micro Board and E-LINK Wiring

42
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols) Equip Protocol York Talk II, 4800 Baud
YK-ELNKE01-0 (Enclosure with Standard BAS Protocols and LON Option) BAS Protocols MS/TP, Modbus, N2, LON
NOTE: Requires external 115 VAC or 230 VAC Supply Points List YCAS Air-Cooled Screw (Rev
Power for Transformer Primary J_03).xls
YCWS & YCRS Water-Cooled Screw-F

(Rev J_01).xls

See the following slides for Dated 12/5/2011
E-LINK “in Panel” Modbus List Elink Modbus Data Map (extension)
Rev_K_03
Installation per equipment LON List LON Data Map ELINK Rev_J.03.xls
type. LON XIF File R2York2.XIF 11/9/2010
MSV Resource File N/A

YCAS
QS - Imperial 12 (1 Section)
13 (2 Sections)
York Talk 2 Panel Imperial QS 2, 3, 4
Resource File
QS-Metric Not Supported
Metric QS N/A
Resource File
YCWS
YCRS

43
031-01095 E-LINK / Equipment Panel Installation
YCWS
YCAS YCRS
York Talk 2
Panel
Remote
Wall Mount
Equipment
Panel
Mount
NOTE: Requires external 115 VAC or 230 VAC Supply

Power for E-LINK Transformer Primary

44
031-01095 (1 Section) Micro Board and E-LINK Wiring

45
031-01095 (2 Sections) Micro Board and E-LINK Wiring

46
NOTE: Requires external 115 VAC or 230 VAC Points List YCAS Air-Cooled Screw (Rev
Supply Power for Transformer Primary J_03).xls
**********************************************
YCWS & YCRS Water-Cooled
The YCAV / YCIV panels may use this Screw-F (Rev J_01).xls
due to VSD noise interference with
BAS Protocols (LON is highly BACnet List BACnet Yorktalk Points Map .xls
susceptible). FSC has a procedure to Dated 12/5/2011
follow in order to determine the need
of the enclosure installation. Modbus List Elink Modbus Data Map
**********************************************
LON List LON Data Map ELINK
Rev_J.03.xls
LON XIF File R2York2.XIF 11/9/2010
See the following slides for MSV Resource N/A

File
YCIV/YCAV
E-LINK “in Panel” QS - Imperial 12 (1 Section)
Installation per equipment 13 (2 Sections)
Imperial QS 2, 3, 4
AKA “Latitude”
YK-ELNKOLK-0 Installation Kit
type. Resource File
Metric QS N/A
York Talk 2 Panel Resource File
YVAA

47
YCAS
YVAA
York Talk 2
Panel
Notes:
Need drawing for in panel drawing, is this the same as the IPU-II drawing?

48
031-02478 VSD Noise E-LINK / Equipment Panel Installation
Notes:
If you use the remote wall mount method due to VSD Noise Interference an external 115VAC or 230 VAC power
source must be used to supply power for the primary side of the transformer mounted in the E-LINK enclosure.
A communication cable with adequate shielding specified by the FSC instructions must be used between the equipment
micro board and the board set in the E-LINK enclosure. The shield will be terminated within the E-LINK enclosure.
The minimum distance the enclosure can be mounted from the Micro Panel is 75 feet.
YCAS
York Talk 2
Panel
Remote
Wall Mount

49
Note: Enabling any of the Latitude’s

PRINT functions will disrupt BAS/E-Link
communications. See YORK Equipment For
201.21-NMx in the Installation, Operation
Maintenance (IOM)
Air-Cooled Screw Liquid Chillers manual
for more information.
Note: JP1 on the 031-02478-xxx

board must be set to the RS485
position when the E-Link BAS
communication is required
Note: If you use the remote wall mount method due to VSD Noise Interference the YK-ELNKOLK-0 Installation Kit
is no longer needed, the power harness and supplied communication cable of the kit are not used as indicated in this
drawing. An external 115VAC or 230 VAC power source must be used to supply power for the primary side of the
transformer mounted in the E-LINK enclosure. A communication cable with adequate shielding specified by the FSC
instructions must be used between the equipment micro board and the board set in the E-LINK enclosure. The shield
Installation Kit Communication Cable
will be terminated within the E-LINK enclosure.
50
NOTE: Requires external 115 VAC or 230 VAC Points List Absorption_Chillers (Rev J_03).xls
Supply Power for Transformer Primary
YGED & YB Micro Panel II (Rev
J_01).xls

Dated 12/5/2011
Modbus List Elink Modbus Data Map (extension)

Rev_K_03
LON List LON Data Map ELINK Rev_J.03.xls
LON XIF File R2York2.XIF 11/9/2010

YIA
See the following slides for QS - Imperial 11 (1 Section)
E-LINK “in Panel” Imperial QS

Resource File
2
Installation per equipment QS-Metric Not Supported
type. Metric QS
Resource File
N/A
York Talk 2 Panel

YPC
YB / YG

51
YIA
YPC
York Talk 2
Panel
Remote
Wall Mount
YB / YG
Equipment
Panel
Mount


52

53
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols) Equip Protocol York Talk III, RS232
Points List YS_YN OptiView (Rev K_03a)

Dated 12/5/2011
Modbus List Elink Modbus Data Map (extension)

Rev_K_03
LON XIF File Rev – J Support

None
YN Rev – K Support
KSSSOPTI.XIF 11/9/2010

See the following slides for QS - Imperial Rev – J Support
E-LINK “in Panel” None

Rev – K Support
Installation per equipment 21
Imperial QS Rev – J Support

type. Resource File None
Rev – K Support
18
York Talk 3 OptiView-I Panel
QS-Metric Rev – J Support
YK-ELNKOLK-0 Installation Kit Required
None
Rev – K Support
26
Metric QS Rev – J Support

Resource File None
Rev – K Support
OM Retrofits - Special
Contact SIS for Quote 22
CR - Special Contact
SIS for Quote

54

55

56
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols)
YK-ELNKE01-0 (Enclosure with Standard BAS Protocols and LON Option) Equip Protocol York Talk III, RS232
BAS Protocols MS/TP, Modbus, N2, LON
t
en
pm
ui
Dated 12/5/2011
eq
Modbus List Elink Modbus Data Map
c fi
ci
YK
io pe
at r s
See the following slides for Rev_J.03.xls
n
rm fo
LON XIF File Rev – J Support
E-LINK “in Panel”
fo s
in lide
None
Rev – K Support
Installation per equipment
s
g
KSSSOPTI.XIF 11/9/2010
in
type.
w
YT QS - Imperial Rev – J Support
l lo
None
fo
Rev – K Support
e
th
21
e
Se
QS-Metric Rev – J Support
None
York Talk 3 OptiView-I Panel Rev – K Support
YK-ELNKOLK-0 Installation Kit Required 26
YS
YR
YR
YMC2 YIA
YST

57
YD
031-02430 YK Equipment Support Information
YK
Equip Protocol York Talk III, RS232
Points List YK Optiview (Rev K_03)
BACnet List BACnet Yorktalk Points Map .xls Dated 12/5/2011
Modbus List Elink Modbus Data Map (extension) Rev_K_03
------------------------- Rev – J Support Rev – K Support

LON XIF File OPTIVIEW.XIF 11/9/2010 KSSSOPTI.XIF 11/9/2010, KVSDOPTI.XIF 11/9/2010
MSV Resource File N/A N/A
QS - Imperial 1 - SSS , 2 - VSD 17 - SSS , 18 - VSD
Imperial Resource File 1- SSS / VSD 18,32,34 – SSS, 15,16,17 – VSD
QS-Metric 6 - SSS , 7 - VSD 22 - SSS , 23 - VSD
Metric Resource File 1- SSS / VSD 22, 20, 21 – SSS, 19, 20, 21 – SSS

58
031-02430 YT Equipment Support Information
YT
Points List YT OptiView (Rev K_03)

QS - Imperial 3 - SSS , 4 - VSD 19 - SSS , 20 - VSD
Imperial Resource File 1- SSS / VSD 18 – SSS, 15,16,17 – VSD
QS-Metric 8 - SSS , 9 - VSD 24 - SSS , 25 - VSD
Metric Resource File 1- SSS / VSD 22, 20, 21 – SSS, 19, 20, 21 – SSS

59
031-02430 YS YN Equipment Support Information
YS YR
YR OptiView (Rev K_03)

QS - Imperial 5 - SSS 21 - SSS
Imperial Resource File 1- SSS 18 - SSS
QS-Metric 10 - SSS 26 - SSS
Metric Resource File 1- SSS 22 - SSS

60
031-02430 YD Equipment Support Information
YD
Points List YD Optiview (Rev K_03a)

LON XIF File YDOPTI.XIF 11/9/2010 KYDOPTI.XIF 11/9/2010
QS - Imperial 14 32
Imperial Resource File 5 23
QS-Metric 15 33
Metric Resource File 6 24

61
031-02430 YST Equipment Support Information
YST
Points List YST Optiview (Rev K_03)
BACnet List N/A – Contained in Points List
Modbus List N/A – Contained in Points List
LON List N/A – Contained in Points List

LON XIF File N/A KYSTOPTI.XIF 11/9/2010
QS - Imperial N/A 27
Imperial Resource File N/A 11
QS-Metric N/A 29
Metric Resource File N/A 12

62
031-02430 YIA Equipment Support Information
YIA
Points List YIA Optiview (Rev K_03) YIA Optiview

LON XIF File N/A KYIAOPTI.XIF 11/9/2010
QS-Metric N/A 30

63
031-02430 YMC2 Equipment Support Information
YMC2
Points List _YMC2 Optiview BAS (Rev K_04c)

* SUPPORTS THE ADVANTAGED / EXTENDED REMOTE MONITORING PORT (BACnet MS/TP on Port 3) POINTS LIST AS WELL

LON XIF File N/A YMC2.XIF 11/9/2010
MSV Resource File N/A 1, 2, 3, 4, 5, 6, 7, 8
QS-Metric N/A 35

64
YK
YT YIA

YS YK-ELNKOLK-0 Installation Kit Required
YR
YR
YST

65
YD
031-02430 YMC2 E-LINK / Equipment Panel Installation
YMC2


66

67
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols) Equip BACnet MS/TP
YK-ELNKE01-0 (Enclosure with Standard BAS Protocols and LON Option) Protocol
BAS N2, LON

Protocols
NOTE: Requires external 115 VAC or 230 VAC Points List ECO2_IPU_LON and N2
Supply Power for Transformer Primary ver J_03.xls
BACnet List BACnet Yorktalk Points

Map .xls Dated
12/5/2011
Modbus List Elink Modbus Data Map


Rev_J.03.xls
LON XIF File R2YPAL.XIF 11/9/2010

YPAL (eco2) unit
See the following slides for MSV N/A
Resource
E-LINK “in Panel” File
Installation per equipment QS -

Imperial
16
type. Imperial
Resource
7, 8
File
Equipment Panel Metric N/A

Resource
File

68
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols)
YK-ELNKE01-0 (Enclosure with Standard BAS Protocols and LON Option)
YPAL (eco2) unit
Equipment Panel
Remote
Wall Mount


69
031-02496 IPU-I Board and E-LINK Wiring
Equipment Cable
BACnet
MS/TP
(38400 baud)
YPAL (ECO2) Setup for MS/TP Bus

DE Modifier Address set to 50.
DE Modifier Offset set to -1.
P1 Protocol Set to BACnet,
P1 Manual MAC Address set to -1.
P1 Baud Rate set to 38400.
P1 Parity Set to None.
P1 Stop Bits set to 1.
MAC address Switch (SW2) set 1 ON, all others OFF.
Note:
Do not set the equipment address and the E-LINK address to the same value. This causes a conflict on the MS/TP
Bus resulting in no communication between the chiller IPU-I board and the E-LINK Gateway.

70
York-003 Micro Board and E-LINK Support
YK-ELNKE00-0 (Enclosure with Standard BAS Protocols) Equip Protocol Modbus RTU
YK-ELNKE01-0 (Enclosure with Standard BAS Protocols and LON Option) BAS Protocols MS/TP, N2, LON
Points List Wuxi_PRC_Generic_LAB for E-

Link_20090730 r3.xls
BACnet List N/A
Modbus List N/A
NOTE: Requires external 115 VAC or 230 VAC LON List N/A
Supply Power for Transformer Primary
LON XIF File STCWUXI.XIF 11/9/2010
MSV Resource N/A

File
QS - Imperial Not Supported
Imperial Resource N/A

YEWS-D1 See the following slides for File
E-LINK “in Panel” QS-Metric
Metric Resource
31
13, 14
Installation per equipment File
type. NOTE: The supporting points list is not

published on the web, Wuxi and Louisville
engineering have the original copies.
Equipment Panel
YEAS

71
YGAS
York-003 E-LINK / Equipment Panel Installation
YEAS
YEWS-D1
Equipment
York Talk 2
Panel
Panel YGAS
Equipment
Panel
Mount
Remote
Wall Mount


72
York-003 Equipment Board and E-LINK Wiring

73
Building Automation System Connections

depicts the E-LINK support
of the BACnet MS/TP,
Modbus RTU, LON, and N2
BAS Connections

74
Quick Start BAS Output Protocols
Release Version 2.2 APP GROUP B OUTPUT PROTOCOL QUICK STARTS
SWITCH
Switch Settings 8 4 2 1 Port 1 Port 3 Port 4

1 (P1B,P3M,P4X) 0 0 0 1 MS/TP, AUTO, N, 8, 1 Modbus, 19200, N, 8, 1 Factory Diagnostic Terminal
2 (P1B,P3M,P4X) 0 0 1 0 MS/TP, AUTO, N, 8, 1 Modbus, 19200, N, 8, 2 Factory Diagnostic Terminal
3 (P1B,P3N2,P4X) 0 0 1 1 MS/TP, AUTO, N, 8, 1 N2, 9600, N, 8, 1 Factory Diagnostic Terminal
4 (P1N2,P3B,P4X) 0 1 0 0 N2, 9600, N, 8, 1 MS/TP, 38400, N, 8, 1 Factory Diagnostic Terminal
5 (P1M,P3B,P4X) 0 1 0 1 Modbus, 19200, N, 8, 1 MS/TP, 38400, N, 8, 1 Factory Diagnostic Terminal
7 (P1M,P3M,P4X) 0 1 1 1 Modbus, 9600, E, 8, 1 MS/TP, 38400, N, 8, 1 Factory Diagnostic Terminal
9 (P1N2,P3M,P4L) 1 0 0 1 N2, 9600, N, 8, 1 Modbus, 19200, N, 8, 2 LON ~ Conversion (IM-SI)
10 (P1N2,P3M,PL) 1 0 1 0 N2, 9600, N, 8, 1 Modbus, 19200, N, 8, 2 LON ~ Pass through (SI)
11 (P1M,P3N2,P4L) 1 0 1 1 Modbus, 19200, N, 8, 2 N2, 9600, N, 8, 1 LON ~ Conversion (IM-SI)
12 (P1M,P3N2,P4L) 1 1 0 0 Modbus, 19200, N, 8, 2 N2, 9600, N, 8, 1 LON ~ Pass through (SI)
13 (P1M,P3M,P4X) 1 1 0 1 Modbus, 9600, E, 8, 1 Modbus, 19200, N, 8, 2 Factory Diagnostic Terminal
14 (P1B,P3N2,P4X) 1 1 1 0 MS/TP, 38400, N, 8, 1 N2, 9600 , N, 8, 1 Factory Diagnostic Terminal
15 1 1 1 1 Field Adjustments Field Adjustments Field Adjustments
Note:
Setting Switch T = ON within the MAC address switch bank forces TERMINAL mode on Port 3, @ 57600 baud, N, 8, 1
(This is only needed to debug the E-Link’s operation and set user controlled application options)

75
BAS Connections
• Port 1 - Electrically isolated. The only port capable of supporting 3-wire
systems
• Port 3 - Supports only 2-wire systems
• Port 4 - Electrically isolated. Supports only 2-wire LON connections.
Maintaining BAS Com Cable Shield Integrity with Multiple E-LINK Units

76
3-Wire BAS Connections (Internal to the Equipment Panel)
Note: Connect a ground strap between the panel's ground path and the
E-Link's common path only if this connection has not been made elsewhere in the
physical equipment wiring.
77
3-Wire BAS Connections (External to the Equipment Panel)

78
2-Wire BAS Connections (Internal to the Equipment Panel)
Note: Connect a ground strap between the panel's ground path and the
E-Link's common path only if this connection has not been made elsewhere in the
physical equipment wiring. Port 1 utilizes the physical ground path for the
communications common. 79
2-Wire BAS Connections (External to the Equipment Panel)
Note: Port 1 utilizes the physical ground path for the communications common.

80
Overview of Field Troubleshooting

depicts the troubleshooting
of the E-LINK by field
technicians. This is just a
short introduction, in depth
training with a terminal
session will occur on Day 3.

81
Troubleshooting Methods
• Diagnostic LED’s
– Status LED flash rate
– Each port has an associated Green (RX) and Red (TX) LED to
indicate the port’s communication status
• Port 3 Terminal Mode Requirements

– Computer or terminal with VT-100 emulation. When using a
WindowsTM based computer, Microsoft® HyperTerminal is the
preferred VT-100 emulation program.*
– RS-232 to RS-485 converter
*HyperTerminal was approved as the preferred terminal emulation program with version 1.0 of the E-LINK.
Due to unreliable communication problems between the E-LINK and the Terminal PC in the field, Tera
Term Pro has since been identified as the current preferred terminal emulation program.
Details about a terminal session connection to the E-LINK will be discussed in detail on Day 3.

82
E-Link Supporting Literature
There are several documents to assist in
installation, commissioning and troubleshooting:
Document Title LIT number
Product Bulletin LIT-12011237
Installation instructions 24-10404-9
Technical bulletin LIT-12011238
PICCS statement LIT-12011243
Enclosure Catalog page LIT- 1900508

83
E-LINK Sites
•• Equipment
Equipment Integration
Integration
•• Product
Product Literature
Literature Internal
Internal
•• Field
Field Support
Support Center
Center
•• Systems
Systems Integration
Integration Services
Services

84
JCI Portal Sites

85
JCI Portal Sites

86
JCI Portal Sites

87
JCI Portal Sites

88
JCI Portal Sites

89
JCI Literature Sites

90
JCI Literature Sites

91
Field Support Center Sites

92

93

94

95

96

97
System Integrated Services NA Sites

98
System Integrated Services EU Sites

99
BACnet Technology Overview
100
•• BACnet
BACnet Services
Services Tech
Tech Spec.docx
Spec.docx
•• BACnet
BACnet Binding
Binding Tech
Tech Spec.docx
Spec.docx
•• BACnet
BACnet Services
Services Tech
Tech spec.docx
spec.docx

101
What is BACnet?
• BACnet is "a data communication protocol for Building
Automation and Control networks." A data communication
protocol is a set of rules governing the exchange of data
over a computer network that covers everything from what
kind of cable to use to how to form a particular request or
command in a standard way. What makes BACnet special is
that the rules relate specifically to the needs of building
automation and control (BAC) equipment, i.e., they cover
things like how to ask for the value of a temperature, define
a fan operating schedule, or send a pump status alarm.
E-Link BACnet Overview

102
Where BACnet did come from?
• BACnet was developed by a committee formed by the
American Society of Heating, Refrigerating and Air-
Conditioning Engineers (ASHRAE). The committee's main
objective was to create a protocol that would allow building
systems from different manufacturers to interoperate, that
is to work together within a single building control system.
• A standard / specification was formed to control the
implementation of the BACnet protocol: ANSI/ASHRAE
Standard 135-2010 “A Data Communication Protocol for
Building Automation and Control Networks.”

103
Achieving Interoperability
• To achieve interoperability across a wide spectrum of
equipment, the BACnet specification consists of three major
parts:
– The first part describes a method for representing any
type of building automation equipment in a standard
way.
– The second part defines messages that can be sent
across a network to monitor and control such
equipment.
– The third part defines a set of acceptable LAN
configurations that can be used to convey BACnet
communications.

104
Representing BAC equipment in a standard way
• BACnet Objects:
– BACnet provides a standard way of representing the
functions of any device, such as analog and binary
inputs and outputs, schedules, control loops, and
alarms, by defining collections of related information
called "objects," each of which has a set of "properties"
that further characterize it. For example: Each analog
input is represented by a BACnet "analog input object"
which has a set of standard properties like present
value, sensor type, location, alarm limits, and so on.
– Some object properties are required while others are
optional. One of the object's most important required
properties is its identifier, a numerical value that allows
BACnet messages to uniquely identify and access the
object.
– The standard also supports optional vendor proprietary
object properties .
105
Representing BAC equipment in a standard way (continued)
• BACnet Object Identifier value shall consist of two
components :
– A 10-bit object type, representing the

BACnetObjectType of the object, with bit 9 the most
significant bit and bit 0 the least significant. For objects
defined in this standard, the value for this field shall be
determined by the BACnetObjectType enumeration (next
slide for details) in Clause 21.
– A 22-bit object instance number, with bit 21 the most
significant bit and bit 0 the least significant.

106
Representing BAC equipment in a standard way (continued)
• BACnet Object Type:

107
Providing standard messages for monitoring / control
• BACnet Services :
– BACnet defines message types, or "services," that are
divided into classes. For example, one class contains
messages for accessing and manipulating the properties
of the analog input object described previously. A
common one is the "ReadProperty" service request. This
message causes the server machine to locate the
requested property of the requested object and send its
value back to the client. Other classes of services deal
with alarms and events; file uploading and downloading;
managing the operation of remote devices; and virtual
terminal functions (accessing equipment across the
network as if you were using a directly-connected
terminal or laptop).

108
Interoperability
• IOC:
– The five BACnet interoperability classes (IOC) define
various services that are used for communication
between building automation devices. These services
are divided into the following classes:
􀂄 Data sharing, DS
􀂄 Alarm and event management, AE
􀂄 Scheduling, SCHED
􀂄 Trending, T
􀂄 Device and network management, DM
– The standard defines various object types as well as
procedures for alarm processing.
– Interoperability between devices can be verified with the
aid of the BIBB list and the PICS Statement

109
Interoperability (continued)
• BIBBS:
– BACnet ensures interoperability between the devices of
different manufacturers, provided that all partners
involved in the project agree upon specific BIBBS
defined by the standard. A BIBB (BACnet
Interoperability Building Block) defines which services
and procedures must be supported on the server and
the client side in order to implement a specific
requirement of the system).
• PICS:
– The PICS (Protocol Implementation Conformance
Statement) document is written for a specific device and
is produced by the manufacturer. The document lists
all of the supported BIBBs, object types, character sets
and communication options for that specific device.

110
Defining a set of acceptable LAN configurations
• BACnet LANs : Devices on the BACnet network are
identified and discovered by their BACnet Device ID.
– BACnet Ethernet is based on "raw" Ethernet packets,
and as such is limited to a very local Ethernet "Layer 2"
network (i.e. connected via Ethernet switches). Packets
cannot be routed via IP Routers. The BACnet MAC
address is the same as the Ethernet MAC address (eg.
00.c0.12.34.af.2e).
– BACnet IP is based on TCP/IP packets. The packets
can be routed over the internet . The BACnet MAC
address is the TCP/IP address for the Device (e.g.
192.168.1.12).

111
Defining a set of acceptable LAN configurations (continued)
• BACnet LANs : Devices are identified and discovered by
their BACnet Device ID
– ARCNET is based on token-passing protocol, with
packet lengths of from 0 to 507 bytes.
The data rate is defined as 2.5 Mbps [10Mbps max.
ARCNET is a registered trademark of Datapoint
Corporation.
– LonTalk is the physical LAN of an Echelon LonWorks
network. It is used only as a transport medium for
BACnet messages. The BACnet messages are conveyed
across a LonTalk LAN in what LonWorks calls "Foreign
Frames," which are "typically used by application
gateways to other networks." "Foreign Frames" means
LonWorks devices don't look at the messages
themselves, they just pass them on. LonWorks and
LonTalk are registered trademarks of Echelon
Corporation.
112
Defining a set of acceptable LAN configurations (continued)
• RS485 LAN: Devices are identified and discovered by their BACnet

Device ID
– MS/TP (master-slave/token-passing) network designed to run
at speeds of 1 Mbps or less over twisted pair wiring (RS-485).
• RS232 LAN: Devices are identified and discovered by their BACnet
Device ID
– PTP "point-to-point" or dial-up protocol for use over phone lines
or hardwired RS-232 connections. Because the PTP connection is
likely to be made over a toll connection such as the telephone
network it will normally not be continuously active.

113
BACnet Data Transport
BACnet data transport
LAN Standard Speed in kB/s
Ethernet TCP/IP ISO/IEC 8802-3 10,000 - 100,000
ARCNET ATA/ANSI 878.1 156 - 7,500
LonTalk EIA/CEA 709.1-B 4.8 - 1,250
MS/TP EIA RS 485 9.6 - 76.8
PTP EIA RS 232-C 9.6 - 56
NOTES:

114
Open System Interconnection Model
ISO-OSI Model
Layer Description Functionality
7 Application Layer Communication services for the application
6 Presentation Layer Language and character settings
5 Session Layer Session start-up and shut-down, subscriber identification
4 Transport Layer Connection and disconnection of end-to-end connections,
flow control
3 Network Layer Routing
2 Data Link Layer Frame alignment, point-to-point data storage, media
Data storage layer access control
1 Physical Layer
Bit transmission Specification of all physical and mechanical parameters
layer
1. ISO – International Organization for Standardization

2. OSI– Open System Interconnection

115
OSI Model Details
User 1 User 2
Application Handles the actual interface with the user’s application program Application
Presentation Converts Codes, encrypts/decrypts, or reorganizes data Presentation
Session Manages dialog, synchronizes data transfers with checkpoints Session
Transport Provides end-to-end error checking and data segmentation

Transport
Network
Network Establishes logical circuits and routing between two machines
Data Link
Data Link Controls orderly access to the physical medium
Physical
Physical Transmits and receives individual bits on the physical medium
Physical medium between the two machines

116
BACnet OSI Model
BACnet Layers Equivalent OSI Layers

BACnet Application Layer Application (7)
BACnet Network Layer Network (3)
ISO 8802-2 (IEEE 8802.3) Data Link (2)
MS/TP PTP ZigBee
Type 1 Lon Talk
ISO 8802-3 ARCNET Physical (1)
EIA-485 EIA-232 802.15.4
(IEEE 802.3)
Since BACnet is a non-connection protocol, the need for message segmentation and
end-to-end error checking is much less than in a connection-based protocol. Thus,
the overhead of a discrete transport layer is not justified and the functions normally
contained in a transport layer are delegated to the application layer. The session
layer is not needed. Since BACnet uses a fixed encoding scheme and offloads security
to the application layer, a separate presentation layer is not needed, as well.

117
BACnet Messaging and Segmenting
• MESSAGES and SEGMENTING :
– Some BACnet messages can exceed the packet size limits of any
of its networks. The BACnet standard makes it possible to send
an oversize message by "segmenting," breaking the message
into chunks, or "segments," for transmission and then re-
assembling it from the segments as they are received.
– Segmenting is an optional feature for BACnet devices. It will
usually be implemented in more complex devices such as field
panels or workstations but might not be in the smaller unitary
controllers which are less likely to need to send or receive large
messages.

118
BACnet Messaging and Segmenting (continued)
– When a message segment is received, the receiver checks that
the segment is intact before accepting it and sending an
acknowledgement to the transmitter. The receiver can
alternatively request that the sequence of segments be
retransmitted, starting with the bad segment. This avoids the
necessity of retransmitting the preceding good segments when a
bad one is detected, thus reducing the amount of traffic on the
internetwork when errors do occur.
– To gain some performance in transferring segments, BACnet
allows several segments to be sent and received before the
reply is returned. The maximum number of segments which
can be sent before a reply is received is called the "window
size."

119
BACnet Messaging and Segmenting (continued)
– The degree of performance gain is somewhat dependent upon
the "quality" of the networks. If the networks were perfect, if
packets were never lost or delivered in the wrong sequence, the
window size could be infinite. In the real world where packets
are sometimes lost in transit7, the window size needs to be
lower. If internetwork transit times are small, window size can
also be small.
– Before a BACnet message is transmitted in segments the
sending and receiving devices negotiate the mechanics of the
transmission. They determine whether both sides support
segmentation and what the window size will be (i.e., the
smallest number supported by both devices). They also need
to agree on the packet size; it will be the largest size that can
be handled by both devices. If these negotiations fail an error
message is generated because operator intervention will be
required; some element of the BAS internetwork will need to
be reconfigured
120
PTP - BACnet Half Routers
• BACnet PTP Half Routers:

– EXAMPLE:
– KMC Controls BAC-5050 BACnet Router
– The BACnet standard defines messages by which the half-router

can report the status of its PTP connection to the routers on its
"local" networks (those on the same side of the PTP connection
as the half-router). It also defines messages by which the half-
router can be instructed to establish or terminate the
connection.

121
PTP - BACnet Half Routers (continued)
• BACnet PTP Half Routers:

– A PTP connection is established when a BACnet device needs to
communicate with a device on a network on the other side of
the connection. The initiating device sends out a request for
information on how to reach that network; the half-router
responds with a message stating that the network is the other
side of a PTP connection. The initiating device then instructs the
half-router to make the connection.
– When the connection is made the half-router broadcasts that
fact. It then transfers message packets it receives destined for
networks on the other side of the PTP connection. The
connection terminates on the occurrence of one of three
conditions: the connection is explicitly terminated, the
connection times out, or if the protocol discovers that multiple
connections to the remote network exist.

122
BACnet LAN Overview
NOTE:
The E-Link can reside on any MS/TP LAN E-Link BACnet Overview
123
Tools Used for BACnet Testing / Troubleshooting
• BACnet MS/TP
– Cimetrics U+4 Interface
– Cimetrics BAS-O-MATIC (using the U+4 Interface and MS/TP
Module initialized by the USB Dongle)
– WireShark (using the U+4 Interface, after installed with BAS-O-
MATIC)
– NAE5520-2 using the FC Integration’s MS/TP Trunk
• BACnet TC/IP
– Cimetrics BAS-O-MATIC (The BACnet IP Module initialized by the
USB Dongle)
– WireShark
– NAE5520-2 using the BACnet IP Integration
– Contemporary Controls BAS-RT BACnet MS/TP to IP Router
– Visual Test Shell from Ashrae
124
BAS-RT BACnet MS/TP to IP Router Overview
Overview
The E-Link Gateway BACnet IP solution will require a BASRT-B BACnet router
purchased directly from Contemporary Control Systems, Inc.
There are no special configurations or setup procedures required for the BASRT-B
BACnet router to connect and operate properly with the E-LINK Gateway.
Ordering and Contact Information

Contemporary Controls System, Inc.
2431 Curtiss Street
Downers Grove, Il 60515 USA
Telephone: 1-630-963-7070
Fax: 1-630-963-0109
Email: info@ccontrols.com
Web: http://www.ccontrols.com/basautomation/basrouter.htm

125
BAS-RT BACnet MS/TP to IP Router Installation
Installation
Refer to the installation guide, TD071200-01B, supplied with the BASRT-B BACnet
router for details on the power and communication requirements, installation, wiring,
and setup instructions.
The MS/TP port of the BASRT-B will be connected to the selected MS/TP port on the
E-LINK Gateway, as selected by the group B switch settings on the E-LINK Gateway.
Notes:
1) Before version 2.0.17 BACnet Ethernet (RAW) protocol was not available - YORK
ICE uses the Ethernet (RAW) Protocol to communicate to the E-LINK.
2) Only 1 Router can be set to the Ethernet (RAW) protocol per site, or
communication problems will occur
3) If more than one router is installed at a site, the MS/TP network numbers MUST
be different for each router.

126
BAS-RT BACnet MS/TP to IP Router Configuration Screen

127
Modbus Technology Overview
March 2012
128
•• E-Link
E-Link Modbus
Modbus Server.docx
Server.docx

129
What is Modbus?
• MODBUS is an application-layer messaging protocol,
positioned at level 7 of the OSI model. It provides
client/server communication between devices connected on
different types of buses or networks.
• The industrial serial standard since 1979, MODBUS
continues to enable millions of automation devices to
communicate. Today, support for the simple structure of
MODBUS continues to grow. The Internet community can
access MODBUS at a reserved system port 502 on the
TCP/IP stack.
• MODBUS is a request/reply protocol and offers services
specified by function codes. MODBUS function codes are
elements of MODBUS request/reply PDUs. This protocol
specification document describes the function codes used
within the framework of MODBUS transactions.
E-Link MODBUS Overview

130
What is Modbus?
Modbus has its roots in the late seventies of the previous
century. It is 1979 when PLC manufacturer Modicon—now a
brand of Schneider Electric's Telemecanique—published the
Modbus communication interface for a multidrop network
based on a master/client architecture. Communication between
the Modbus nodes was achieved with messages. It was an
open standard that described the messaging structure. The
physical layer of the Modbus interface was free to choose. The
original Modbus interface ran on RS-232, but most later
Modbus implementations used RS-485 because it allowed
longer distances, higher speeds and the possibility of a true
multi-drop network. Because of this, Modbus became the first
widely accepted fieldbus standard. In a short time hundreds of
vendors implemented the Modbus messaging system in their
devices and Modbus became the de facto standard for
industrial communication networks.

131
Modbus message structure
The Modbus communication interface is built around
messages. The format of these Modbus messages is
independent of the type of physical interface used. On plain old
RS232 are the same messages used as on Modbus/TCP over
ethernet. This gives the Modbus interface definition a very long
lifetime. The same protocol can be used regardless of the
connection type. Because of this, Modbus gives the possibility
to easily upgrade the hardware structure of an industrial
network, without the need for large changes in the software. A
device can also communicate with several Modbus nodes at
once, even if they are connected with different interface types,
without the need to use a different protocol for every
connection.

132
On simple interfaces like RS485 or RS232, the Modbus
messages are sent in plain form over the network. In this case
the network is dedicated to Modbus. When using more
versatile network systems like TCP/IP over ethernet, the
Modbus messages are embedded in packets with the format
necessary for the physical interface. In that case Modbus and
other types of connections can co-exist at the same physical
interface at the same time. Although the main Modbus
message structure is peer-to-peer, Modbus is able to function
on both point-to-point and multidrop networks.

133
Each Modbus message has the same structure. Four basic
elements are present in each message. The sequence of these
elements is the same for all messages, to make it easy to
parse the content of the Modbus message. A conversation is
always started by a master in the Modbus network. A Modbus
master sends a message and—depending of the contents of
the message—a slave takes action and responds to it. There
can be more masters in a Modbus network. Addressing in the
message header is used to define which device should respond
to a message. All other nodes on the Modbus network ignore
the message if the address field doesn't match their own
address.

134

135
Modbus serial transmission modes
Serial Modbus connections can use two basic transmission
modes, ASCII or RTU, remote terminal unit. The transmission
mode in serial communications defines the way the Modbus
messages are coded. With Modbus/ASCII, the messages are in
a readable ASCII format. The Modbus/RTU format uses binary
coding which makes the message unreadable when
monitoring, but reduces the size of each message which allows
for more data exchange in the same time span. All nodes on
one Modbus network segment must use the same serial
transmission mode. A device configured to use Modbus/ASCII
cannot understand messages in Modbus/RTU and vice versa.

136
When using Modbus/ASCII, all messages are coded in
hexadecimal values, represented with readable ASCII
characters. Only the characters 0...9 and A...F are used for
coding. For every byte of information, two communication-
bytes are needed, because every communication-byte can only
define 4 bits in the hexadecimal system. With Modbus/RTU the
data is exchanged in a binary format, where each byte of
information is coded in one communication-byte.

137
Modbus messages on serial connections are not sent in a plain
format. They are framed to give receivers an easy way to
detect the beginning and end of a message. When using
Modbus/ASCII, characters are used to start and end a frame.
The colon ':' is used to flag the start of a message and each
message is ended with a CR/LF combination. Modbus/RTU on
the other hand uses time gaps of silence on the
communication line for the framing. Each message must be
preceded by a time gap with a minimum length of
3.5 characters. If a receiver detects a gap of at least
1.5 characters, it assumes that a new message is coming and
the receive buffer is cleared. The main advantage of
Modbus/ASCII is, that it allows gaps between the bytes of a
message with a maximum length of 1 second. With
Modbus/RTU it is necessary to send each message as a
continuous stream.

138

139
Modbus addressing
The first information in each Modbus message is the address of
the receiver. This parameter contains one byte of information.
In Modbus/ASCII it is coded with two hexadecimal characters,
in Modbus/RTU one byte is used. Valid addresses are in the
range 0..247. The values 1..247 are assigned to individual
Modbus devices and 0 is used as a broadcast address.
Messages sent to the latter address will be accepted by all
slaves. A slave always responds to a Modbus message. When
responding it uses the same address as the master in the
request. In this way the master can see that the device is
actually responding to the request.

140
Modbus addressing
Within a Modbus device, the holding registers, inputs and
outputs are assigned a number between 1 and 10000. One
would expect, that the same addresses are used in the Modbus
messages to read or set values. Unfortunately this is not the
case. In the Modbus messages addresses are used with a
value between 0 and 9999. If you want to read the value of
output (coil) 18 for example, you have to specify the value 17
in the Modbus query message. More confusing is even, that for
input and holding registers an offset must be subtracted from
the device address to get the proper address to put in the
Modbus message structure. This leads to common mistakes
and should be taken care of when designing applications with
Modbus. The following table shows the address ranges for
coils, inputs and holding registers and the way the address in
the Modbus message is calculated given the actual address of
the item in the slave device.

141
Modbus addressing

142
Modbus function codes
The second parameter in each Modbus message is the function
code. This defines the message type and the type of action
required by the slave. The parameter contains one byte of
information. In Modbus/ASCII this is coded with two
hexadecimal characters, in Modbus/RTU one byte is used. Valid
function codes are in the range 1..255. Not all Modbus devices
recognize the same set of function codes. The most common
codes are discussed here.

143
Modbus function codes
Normally, when a Modbus slave answers a response, it uses
the same function code as in the request. However, when an
error is detected, the highest bit of the function code is turned
on. In that way the master can see the difference between
success and failure responses.

144
Function 01: Read coil status
In Modbus language, a coil is a discrete output value. Modbus
function 01 can be used to read the status of such an output.
It is only possible to query one device at a time. Broadcast
addressing is not supported with this Modbus function. The
function can be used to request the status of various coils at
once. This is done by defining an output range in the data field
of the message.

145
Function 01: Read coil status
When receiving a Modbus query message with function 01, the
slave collects the necessary output values and constructs an
answer message. The length of this message is dependent on
the number of values that have to be returned. In general,
when N values are requested, a number of ((N+7) mod 8)
bytes are necessary to store these values. The actual number
of databytes in the datablock is put in the first byte of the data
field. Therefore the general structure of an answer to a
Modbus function 01 query is:

146
Function 02: Read input status
Reading input values with Modbus is done in the same way as
reading the status of coils. The only difference is that for
inputs Modbus function 02 is used. Broadcast addressing mode
is not supported. You can only query the value of inputs of one
device at a time. Like with coils, the address of the first input,
and the number of inputs to read must be put in the data field
of the query message. Inputs on devices start numbering at
10001. This address value is equivalent to address 0 in the
Modbus message.

147
Function 02: Read input status
After receiving a query message with Modbus function 02, the
slave puts the requested input values in a message structure
and sends this message back to the Modbus master. The
length of the message depends on the number of input values
returned. This causes the length of the output message to
vary. The number of databytes in the data field that contain
the input values is passed as the first byte in the data field.
Each Modbus answering message has the following general
structure.

148
Function 03: Read holding registers
Internal values in a Modbus device are stored in holding
registers. These registers are two bytes wide and can be used
for various purposes. Some registers contain configuration
parameters where others are used to return measured values
(temperatures etc.) to a host. Registers in a Modbus
compatible device start counting at 40001. They are
addressed in the Modbus message structure with addresses
starting at 0. Modbus function 03 is used to request one or
more holding register values from a device. Only one slave
device can be addressed in a single query. Broadcast queries
with function 03 are not supported.

149
Function 03: Read holding registers
After processing the query, the Modbus slave returns the 16 bit
values of the requested holding registers. Because of the size
of the holding registers, every register is coded with two bytes
in the answering message. The first data byte contains the
high byte, and the second the low byte of the register. The
Modbus answer message starts with the slave device address
and the function code 03. The next byte is the number of data
bytes that follow. This value is two times the number of
registers returned. An error check is appended for the host to
check if a communication error occurred.
150
Modbus OSI Model
Modbus Layers Equivalent OSI Layers

Modbus TCP Modbus Application Protocol Application (7)
Client / Server Transport (4)
TCP N/A Network (3)
IP Data Link (2)
ISO 8802-2 (IEEE 8802.3) Modbus Serial Modbus Serial
Type 1 Line Protocol - Line Protocol -
ASCII RTU Physical (1)
ISO 8802-3 (IEEE 802.3) EIA-232 EIA-485

151
Modbus Networks
MODBUS is an application layer messaging protocol for client/server
communication between devices connected on different types of buses or
networks.
It is currently implemented using:

􀁹 TCP/IP over Ethernet. See MODBUS Messaging Implementation Guide
V1.0a.
􀁹 Asynchronous serial transmission over a variety of media (wire : EIA/TIA-

232-E, EIA-422, EIA/TIA-485-A; fiber, radio, etc.)
􀁹 MODBUS PLUS, a high speed token passing network.
The same communication can be done as well on serial line as on an Ethernet

TCP/IP networks. Gateways allow a communication between several types of
buses or network using the MODBUS protocol

152
Modbus Network Topology
The MODBUS protocol allows an easy communication within all types of
network architectures.
MODBUS Communication
Drive PLC HMI I/O I/O PLC I/O

MODBUS on TCP/IP
Gateway Gateway Gateway
PLC PLC
ASCII
RS232 I/O RTU
MB+ HMI RS485
Device I/O
Drive
I/O E-LINK
I/O
Every type of devices (PLC, HMI, Control Panel, Driver, Motion control, I/O
Device…) can use MODBUS protocol to initiate a remote operation.
153
Tools Used for Modbus Testing / Troubleshooting
• Modbus RTU
– Cimetrics U+4 Interface
– Cimetrics BAS-O-MATIC (using the U+4 Interface and Modbus
RTU Module initialized by the USB Dongle)
– WireShark (using the U+4 Interface, after installed with BAS-O-
MATIC)
– NAE5520-2 using the Modbus RTU Vendor Integration
– ModScan32
• Modbus IP
– Cimetrics BAS-O-MATIC (The Modbus IP Module initialized by
the USB Dongle)
– WireShark
– NAE5520-2 using the Modbus IP Vendor Integration
– LANTRONIX MODBUS RTU to MODBUS IP ROUTER
– ModScan32
154
LANTRONIX Modbus RTU to IP Bridge Router Diver Installation
Overview
The E-Link Gateway Modbus IP solution will require a LANTRONIX XPress-DR-IAP
Modbus bridge router purchased directly from LANTRONIX. This solution has been
used in the field already. Once the correct communication parameters are setup, no
other programming is required. Part number XSDRIN-02
A field sever Modbus RTU to IP device has been used in the field as well, but requires
special programming (at extra cost) to convert the RTU addressing schema to IP
addressing schema.
Ordering and Contact Information

LANTRONIX
167 Technology Drive
Irvine, CA 92618 USA
Telephone: (800) 526-8766 / +1 (949) 453-3990
Fax: +1 (949) 450-7249
Email: sales@lantronix.com
Web: http://www.lantronix.com/device-networking/external-device-servers/xpress-
dr_dr-iap.html
155
LANTRONIX Modbus RTU to IP Bridge Router Diver Installation
Installation
Install the “Device Installer” application from the CD with the LANTRONIX Device on
to the PC that will be used to setup the LANTRONIX device.

156
LANTRONIX Modbus RTU to IP Bridge Router Driver Installation

157
LANTRONIX Modbus RTU to IP Bridge Router Driver Upgrade
Upgrade to DA-Modbus Bridge Firmware
From the manuals included on the disc, determined that the LANTRONIX device
needed to be upgraded to the “DA-Modbus Bridge” firmware.
This will allow the device to handle the timing of the MODBUS messages better than
the “Standard Tunnel” firmware. Using the upgrade icon on the toolbar, I upgraded
the device to the “DA-Modbus Bridge” firmware.

158

159

160

161

162
Select next to install the firmware on the device.

163
LANTRONIX Modbus RTU to IP Bridge Router Device Settings
Once the firmware is upgraded, use the Device Installer -> Telnet Configuration tab
to finish the MODBUS Setup.

164
LANTRONIX Modbus RTU to IP Bridge Router Diver Device Settings
IMPORTANT: Be sure to save the changes you make after each parameter set – if
the telnet session times out and you have not saved the changed parameters -> all
changes will be lost and you will have to reenter them.

165
LANTRONIX Modbus RTU to IP Bridge Router Device Settings – Web Interface

166
LANTRONIX Modbus RTU to IP Bridge Router Diver Device Connections
Connect the LANTRONIX Device communication terminals to the E-LINK BAS port 1
terminals as follows (per the installation manual for the LANTRONIX device):
The E-LINK switch settings are:

1) Switch set “A” is set to QSxx – the desired
equipment profile
2) Switch set “B” was set to QS13 - MODBUS
9600, 8, E, 1 on Port 1
3) Switch set “C” is set to the desired Modbus
If you are using the NAE for testing, set up a

MODBUS TCP vendor integration on the NAE and
program in the points for the E-LINK.
The setup as described above was used for troubleshooting a field Modbus
communication problem with the LANTONIX device and E-LINK connected to the YST
equipment.
167
LON Technology Overview
168
•• E-Link
E-Link LON
LON Tech
Tech Spec.docx
Spec.docx

169
What is LON?
• The LonTalk protocol implements all seven layers of the OSI
model, and does so by using a mixture of hardware and
firmware on a silicon chip, thus eliminating any possibility of
modification. It is a 1-Persistant Carrier Sense Multiple
Access (1-Persistent CSMA) protocol modified for peer to
peer networks.

170
What is LON?
The LonTalk protocol is designed as a collection of services
that can be optionally invoked. They may be chosen by the
programmer and fixed at compile time or changed by an
installer during commissioning and maintenance. The services
can be broken down into the following:
Physical channel management (layers 1 and 2)

Naming, addressing and routing (layers 3 and 6)
Communication services (layers 2 and 4)
Prioritizing messages (layer 2)
Authentication (layers 4 and 5)
Network management (layer 5)
Network interface (layer 5)
Data interpretation (layer 6)
Application compatibility (layer 7)

171
What is LON?
The way in which a Lonworks product must comply with the
OSI model and the basis of the LonTalk protocol is set out in
the LonMark standards. These standards allow us to develop
LonWorks devices.

172
LonWorks
Echelon is the creator of LonWorks networking technology. A LonWorks system
consists of a network of micro-controllers which have peer to peer
communications over a variety of different media, including twisted pair, power
line and radio frequencies. The heart of the system is the Neuron chip, which
is a specialized chip that incorporates three 8-bit microprocessors, one for
handling application code and two for handling network communication.
LonWorks conforms to all 7 layers of the OSI model.
The success of LonWorks applications can be attributed to the communications

protocol LonTalk, much like Ethernet but optimized for small data packets.
Each Neuron has embedded firmware necessary for running the protocol and
communicates with other devices on the network through network variables. A
comprehensive list of Standard Network Variable Types (SNVTs) is available but
custom structures can also be defined. The interconnection of network
variables is done in a binding process by a network management tool at
installation. This information is stored in EEPROM in each Neuron chip to allow
complete recovery in case of a power failure. Neuron software is written in an
event driven variant of ANSI C known as Neuron C. A network is capable of
control on a number of levels. E-Link MODBUS Overview 173
LonWorks
At a low level there is enough control capabilities available on a Neuron to deal
with low level IO, dealing with sensors, actuators and running control loops. At
a middle level the network can be made into an integrated system that co-
ordinates low level nodes to give good system performance. At a high level,
network management and front-end co-ordination can be achieved through
comprehensive Application Programming Interface (API) facilities. LonWorks
offers impressive network control tools, particularly with the introduction of the
LonWorks Network Services (LNS) Architecture. This brings client server
architectures to control networking. Component based software design and
the LonWorks Component Architecture (LCA) allows ActiveX and DLL links
directly into high level operating systems including OLE services for Windows
95 and NT. This is very much the future of control networking as IO is
translated to IT.


174
Physical Channel
The LonTalk protocol is media independent. Therefore through
the use of various transceivers LonWorks devices support a
wide variety of media, including twisted pair, power line, radio
frequency, infrared, coaxial cable and fiber optics.
Specifications are available for each LonWorks transceiver and
provide the distance, bit rates and topologies supported.

175
Transceiver
The transceiver implements layer one of the OSI Model and
the LonTalk protocol. Each Neuron chip has a five-pin
communications port that interfaces with a range transceivers
for different network media. A list of some of the different
types of network media is given below:
Twisted pair
Co-axial
Power-line
Infra-red
Radio frequency
A major function of the transceiver is to isolate the
device’s electronics from harmful energy on the
network channel. Routers, which can utilize many
different transceivers, can be used to transfer data
from one media to another.

176
Neuron Chip
The Neuron chip runs the LonTalk protocol and supports
LonWorks services with embedded firmware. The Chip is
manufactured by Motorola and Toshiba in two basic forms: the
3120 (32 pins) and the 3150 (64 pins). A unique non-
changeable 48-bit Neuron ID string is assigned at manufacture
to ensure that every Neuron has an individual identity.
The Neuron chip contains three pipelined CPUs. Each CPU is

an 8-bit processor responsible for different layers of the OSI
model:
• Media Access CPU – executes LonTalk Protocol Layer 2
(sends and receives messages to and from the network);
• Network CPU – executes LonTalk Protocol Layers 3-6
(addressing, reliable message delivery, duplication
detection and security);
• Application CPU – executes LonTalk Protocol Layer 7 user
application written in Neuron C).

177
Neuron Chip
Having two processors dedicated to network tasks and one
dedicated to application tasks ensures that the complexity of
the application does not reduce the network responsiveness
and vice versa. The CPUs are connected with memory via an
internal 16-bit address bus and an internal 8-bit data bus.
The 3120 supports applications of up to 2 Kbytes, equivalent to

about 40 pages of Neuron C code and all of the required Read
Only Memory (ROM), Random Access Memory (RAM) and
Electrically Erasable Programmable Read Only Memory
(EEPROM) is included within the chip.

178
Neuron Chip
The ROM is the Neuron Chip Firmware, or system image, and
represents memory that can not be changed or written to.
The firmware which is written, tested, debugged and burnt into
the chip at manufacture, is the operating system that runs on
the Media Access Control and Network processors. A number
of runtime libraries for the application program running on the
application processor are also included here. The RAM is used
for stack space for the three processors, for application
variables and communications buffers and is volatile memory.
The EEPROM is the memory space for the application code and
non-volatile network variables. It can be erased and used over
by exposing it to an electric charge.

179
Neuron C
Neuron C is a programming language designed specifically for
the Neuron chip. Neuron C has a set of IO drivers in firmware
that deal with most IO requirements. It is an event driven
version of ANSI C. Certain C libraries are included, but it has a
few extensions:
• A ‘when’ statement, to introduce events and define task

execution order;
• 37 additional data types, 35 I/O objects and 2 timer
objects, to simplify and standardize device controller
usage;
• Integral message-passing mechanisms for both explicit
(physical, logical and destination-name addressing) and
implicit (network variable) message formats to simplify
data sharing across the network.

180
Naming Addressing and Routing
A name, in a LonWorks network, is a unique 48-bit Neuron ID
burnt into each individual Neuron at manufacture and does not
change over its lifetime. An address is an identifier that
uniquely identifies an object or group of objects within an
object class and may be changed at any time. LonTalk
addresses uniquely identify the source node and destination
nodes of a LonTalk packet.
To simplify routing, the LonTalk protocol defines a hierarchical
form of addressing using:
• Domain – identifies a subsystem on an open media or in a
large installation. There can be 248 domains in a network. A
node may simultaneously belong to 2 domains;
• Subnet – is a subset of a domain. There can be 255
subnets to a domain. Routing is based on subnets;
• Node – uniquely identifies a node within its subset. There
can be 127 nodes in a subnet and thus 32,385 nodes in a
domain.

181
LON Talk Packet

182
Naming Addressing and Routing
This form of addressing allows the protocol to adopt a number
of addressing modes:
• Unicast addressing (subnet/node) – sends messages to a

single node;
• Multicast addressing (group) – sends a message to a
group of nodes;
• Broadcast addressing (subnet/domain) – sends a message
to a subnet, or to an entire domain.
This form of naming addressing and routing saves on the

controls network capacity and thus improves the performance
and response times of larger networks.

183
Communication Services
The communication services are utilized to provide a trade off
between reliable communications, better response times and
efficient use of channel bandwidth. The LonTalk protocol offers
four types of message service options:
• Unacknowledged – fastest possible service;
• Repeated – also an unacknowledged service but reduces
the probability of a collision without sacrificing bandwidth;
• Acknowledged – end to end messages that re-try after
timeout period if messages are lost due to noise or
congestion. Message can be sent to individual nodes, or
groups of nodes. Duplicate message detection and
reminders are fully implemented;
• Request/Response – application to application message
where the acknowledgement also carries data. Message
can be sent to individual nodes, or groups of nodes.
Duplicate message detection and reminders are fully
implemented.

184
In order of most reliable to least reliable, the
Request/Response and Acknowledged are equally reliable
followed by Repeated and then Unacknowledged. However the
most reliable message options utilize more of a channel’s
capacity and on large networks can cause problems.
The LonTalk protocol provides duplicate message detection,

and normally delivers a message to the destination only once.
Duplicate packets can occur when using unacknowledged
repeated service or if a acknowledgement or response
message has been lost. The duplicate detection capability is
provided by a received transaction database in each node.

185
The success of the LonTalk protocol is due to its small packet
size and random back-off algorithm related to channel backlog
information. In checking the network for the relevant
destination address, a particular node receives and extracts
information about the channel backlog information. It uses this
information to build a model of the likelihood of being able to
reply to its own messages and expands the range over which it
randomizes a time slot selection in case of collisions. As all the
nodes on the network are doing this the likelihood of collision
is reduced, enabling more linear network usage at a higher
bandwidth.

186
The mechanism for reducing this range in periods of light
traffic is based on packet elapse time. Indicating the average
time a packet occupies the network. The default time is based
on the average LonTalk packet of 10-14 bytes. For each
elapsed packet cycle the backlog number is reduced by one,
reducing the backlog range. This scheme allows the network to
adapt to changing network usage preventing multiple collisions
when network traffic is heavy and allowing faster responses
when the network traffic is light.

187
Priority Messages
The performance of the control networks are measured in
response time not data throughput, thus a linear time response
at higher bandwidth usage might not be good enough. In
critical applications, important messages need to get through
no matter what the network traffic conditions, the LonTalk
protocol provides priority message slots for such messages.
These slots could be used for vital messages such as fire,
security or other possible life dependent services.

188
Authentication
The LonTalk protocol also supports authenticated messages,
which allow the receivers of a message to determine whether
the sender is authorized to send that message. When an
authenticated message is sent, the receiver challenges the
sender to provide authentication, using a different random
challenge (8bytes) every time. The sender then responds with
a transformation performed on the challenge, using an
authentication key. The receiver compares the reply to the
challenge with its own transformation on the challenge. If the
transformations match, the transaction goes forward. The
transformation used is designed so that it is extremely difficult
to deduce what the key is, even if the challenge and response
are both known. Authentication is a vital part of implementing
access control and security systems as well as keeping hackers
off the system.

189
Network Management
The LonTalk protocol provides network management services
for installing and configuring nodes, downloading software and
diagnosing the network. There are many functions provided by
the network management services. Two of them, the Modify
Address Tables and Modify Net Variables messages may be
used to dynamically connect network variables and message
tags. This process is termed binding and is used during
installation and reconfiguration to establish the addressing
information needed to route messages and network variable
updates between nodes. These services are implemented
through a network management tool which runs from a
computer on the network.

190
Standard Network Variable Types (SNVTs)
Application compatibility is facilitated in the LonTalk protocol
through the use of Standard Network Variable Types (SNVTs).
A list of nearly 100 SNVTs, that cover a wide range of
applications, can be found in the SNVT Master List and
Programmer’s Guide compiled by the LonMark Interoperability
Association. The definition of each SNVT includes its units, its
range and its resolution; some examples are given in the table
below. Using the appropriate network management tool can
allow a LonWorks node to extract SNVT information (ID# and
optional text string) from any other node.

191
Standard Network Variable Types (SNVTs)
Table showing examples of some Standard Network Variable
Types :
SNVT Measurement Units Range Resolution
SNVT_temp Temperature Degrees Celsius -274 – 6271 0.1 degree

SNVT_angle Phase/Rotation Radians 0 - 65 0.001 rads
SNVT_speed Speed Meter/Sec 0 - 6553 0.1 m/s
SNVT_elapsed_tm Elapsed Time HH:MM:SS 0 – 65535 days 1 msec
SNVT_lev_count Continuous Level Percent 0 – 100% 0.50%
SNVT_ascii ASCII String Characters 30 Chars N/A
SNVT_count Events Count 0 – 65535 1 Count

192
Network Interface
The LonTalk Protocol includes an optional network interface
protocol that can be used to support LonWorks applications
running on any host processor. A host processor may be any
microcontroller, microprocessor or computer. The host
processor manages layers 6 and 7 of the LonTalk protocol and
uses the LonWorks network interface to manage layers 1 to 5.
The LonTalk network interface protocol defines the format of
packets exchanged between the network interface and the
host.
A host application running on the host processor
communicates with the network interface through a network
driver. The network driver manages the buffer allocation,
buffer transfers to and from the network interface and isolate
the host application from any differences in the network
interface link layer protocol. The LonTalk network driver
protocol defines a standard message format between the host
application and network driver.

193
Network Interface
For Example: the computer on the network utilized a standard
ISA slot network interface card to allow the computer to
communicate on the network.
In order for the computer to be able to communicate on the

controls network for the purposes of network management,
monitoring and control, a computer network interface card was
needed. The card used was an Echelon PCLTA-10 PC LonTalk
Adapter which was installed in one of the ISA slots of the
computer, next to the PC's LAN communications card. Other
types of network interface card are available for the use on
laptops and palmtops but this card was the most appropriate
for use in a desktop PC. The Neuron Chip on the card is
responsible to translating messages on the network to a
language the computer can understand and there would
normally only be a need for one or two of these in a typical
system.

194
Data Interpretation
The LonTalk protocol employs a data orientated application approach. In this
approach, application data items such as temperatures, pressures, states, text
strings, etc are exchanged between nodes in standard engineering and other
predefined units. Commands are encapsulated within the application programs
of the receiver nodes rather than being sent over the network. In this way, the
same engineering value can be sent to multiple nodes, which have a different
application program for that data item.

195
Data Interpretation
The data items in the presentation layer of the LonTalk protocol are called
network variables. Network variables can be any single data item or a data
structure. Each network variable has a data type declared by the application
program. Network variables are declared much like local C variables except that
the ‘network’ keyword is used to make the variable available to any other node
on the network. When output network variables change via assignment
operations within the application program, the Neuron Chip firmware
automatically propagates the new value over the network using the LonTalk
protocol services. Network variables are transmitted as LonTalk messages, but
the Neuron chip firmware automatically handles the buffer management,
message initialization and error handling.

196
Data Interpretation
Applications requiring different data interpretation model than network
variables can send and receive explicit messages. Explicit messages use the
messaging services of the LonTalk protocol with the minimum data
interpretation. Each explicit message contains a message code that the
application can use to determine the type of interpretation to be used on the
contents of the message.

197
Application Compatibility
Application compatibility is facilitated in the LonTalk protocol through the use of
Standard Network Variable Types (SNVTs). A list of nearly 100 SNVTs, that
covers a wide range of applications, can be found in the SNVT Master List and
Programmer’s Guide compiled by the LonMark Interoperability Association. The
definition of each SNVT includes its units, its range and its resolution. Using the
appropriate network management tool can allow a LonWorks node to extract
SNVT information (ID# and optional text string) from any other node.

198
Application Compatibility
In addition to SNVTs, which can be exchanged from device to device, a
Lonworks device can have Standard Configuration Properties Types (SCPTs).
SCPTs are used to customize and optimize the performance of a particular
node’s application program, by utilizing parameters such as range, resolution,
maximum send time and operating mode.
The SNVTs and SCPTs are often grouped into a series of functional objects,
with the nature of those objects depending on the application.

199
Network Management
The LonTalk protocol provides network management services for installing and
configuring nodes, downloading software and diagnosing the network. There
are many functions provided by the network management services. Two of
them, the Modify Address Tables and Modify Net Variables messages may be
used to dynamically connect network variables and message tags. This process
is termed binding and is used during installation and reconfiguration to
establish the addressing information needed to route messages and network
variable updates between nodes. These services are implemented through a
network management tool which runs from a computer on the network.

200
Network Management Tool
A LonWorks network management tool is any tool that installs, diagnoses or
maintains devices on a LonWorks network, or that monitors and controls a
LonWorks system. These tools are needed to bind the various system
components together in order to realize the full system functionality. The
network management tool creates a database of all the nodes on the system
and their relationships. This database is based either on Echelon's LNS or API
standards.

201
Network Management Tool
The LNS standard was designed with multi-vendor systems in mind, and allows
for the use of plug-in software modules which manufacturers can design to
make configuration of their products easier. Indeed, the installer should be
able to just physically plug in the devices and have then configure themselves
with minimal or no user interaction. End users want tools that are tailored to
their application. Tools must provide an application view of the system, hiding
the network when the user is uninterested in the network details.
Network management tools can be created using Human Machine Interface

(HMI) and Supervisory Control and Data Acquisition (SCADA) packages. In
addition, the LonWorks Component Architecture (LCA) is a software
architecture that provides co-operation between LNS software components and
the host Windows components.

202
LNS Plug-ins
Plug-ins are a special kind of LNS application, implemented as ActiveX

automation servers, that implement the LNS plug-in API to provide add-ons to
the network management tool. Plug-ins provide a standard way to extend and
customize the functionality of LNS applications. For example, plug-ins allow
device manufacturers to provide custom add-ins that simplify configuration,
monitoring and control of their devices. Plug-ins can also add new functionality
to tools, such as alarming logging and trending.

203
LNS Plug-ins
Plug-ins make tools easier to use and more productive thus benefiting the end
user. They reduce the cost of training users and reduce the time and cost of
installing, configuring and maintaining systems. Tool and device manufacturers
also benefit from plug-ins. For tool manufacturers, plug-ins make their tools
extensible and thus more valuable. Users can incrementally add features, from
the tool’s manufacturer or from other plug-in vendors, to adapt to their needs.
Devices that come with LNS plug-ins are devices that come with a competitive
edge, they are lower cost to install, lower cost to service and easier to use.

204
LonMark
The distinction between LonTalk and LonMark is very subtle. LonMark

subsumes the LonTalk protocol and as a whole provides a set of standards that
allow independently designed systems to be integrated without the need to
develop custom application code. The LonMark approach creates an application
layer interoperability interface by the generic description of a series of objects:
Node Object – provides the mechanism for requesting object modes and for
reporting status of objects within the node. In addition, the node object
includes network variables and configuration properties related to the node as
a whole, such as for network management support;
Open Loop Sensor Object – suitable for use with sensing devices that report
absolute rather than relative values and for use with devices that do not
require feedback information for correct operation;

205
LonMark
Closed Loop Sensor Object – contains a feedback feature that enables multiple
sensors to control a common actuator and a single sensor to control multiple
actuators, while retaining synchronization between the actual and desired
states of objects in both sensors and actuators. An example would be when
multiple remote dimmer light controls are located round a space to control the
same lighting load;
Open Loop Actuator Object – suitable for use in applications where the
actuator provides no feedback information;
Closed Loop Actuator Object – contains a feedback feature that enables

multiple actuators to be arbitrarily combined with multiple sensors. The
feedback feature allows synchronization between the actual and desired states
of the objects in multiple sensors and actuators;

206
LonMark
Controller Object – allows control algorithms to be introduced between data

producing objects such as sensor objects and data consuming objects such as
actuator objects.
Sets of interoperability guidelines and standard functional profiles are available

from the LonMark Interoperability Association. The LonMark Interoperability
Association is an open global organization dedicated to promoting and
facilitating interoperability between LonWorks-based products. It has over 190
members who together develop standards and guidelines for producing
interoperable products. Devices that conform to the standards set out by the
organization get their products certified with the LonMark Logo

207
LON OSI Model (Layers 7 to 3)
LON Layers Equivalent OSI Layers
Standard network variables Application (7)
•Network variable Presentation (6)
•Foreign frame transmissions
•Request-Response Session (5)

•Sender authentication
•Network management
•Network interface
•Acknowledged & Unacknowledged Transport (4)

•Unicast & Multicast authentication
•Common ordering
•Duplicate message detection
•Automatic retries
•Addressing routers Network (3)

•Unicast/multicast/broadcast addressing
E-Link LON Overview

208
LON OSI Model (Layers 2 and 1)
LON Layers Equivalent OSI Layers
•Framing Data Link (2)
•Data encoding
•CRC error checking
•Predictive CSMA
•Priority transmission
•Collision avoidance
•Optimal priority and collision detection through mixed data
rates
EIA-709.1 Superseded by EIA-709.1-A, ANSI/CEA 709.1-A
ISO/IEC 14908-1 (Protocol):
•Twisted pair Physical (1)

•ISO/IEC 14908-2 (media),
•ANSI/CEA-709.3 – LonMark TP/FT-10 free-topology and bus twisted-pair channel specification
•Power-line
•ANSI/CEA-709.2 – LonMark PL-20 channel specification
•IP Tunneling
•ANSI/CEA-852 – LonMark IP-852 channel specification,
•ANSI/CEA-852.1 – Enhanced channel specification
•Fiber Optic
•ANSI/CEA-709.4 – LonMark FO-20S and FO-20L (lightwave) channel specification
E-Link LON Overview

209
LON LAN Overview

210
Creating an Equipment XIF File
Using the E-Link Application Guide_Ver 4.7.xlsm spreadsheet select the desired
equipment tab. Columns G and H are the required information for a XIF File.

211
Creating an Equipment XIF File
Row 1 contains a description of the XIF file, and what will be displayed as the name of
the E-LINK when using the Protocessor Tools (covered later)
Row 2 contains the XIF file name that will be created when the Generate XIF button is
selected.
Row 3 is the E-LINK program ID for the desired equipment to be incorporated in the XIF
file. There are different Program IDs for the supported equipment.
From Row 10 and down:

Column G contains the NV Name
(16 characters MAX)
Column H contains the SNVT Description
(SNVT Number)
Use the points list to populate the required

values. When the entries are correct, select the
Generate XIF File Button. The resulting XIF file
is created in the same directory as the
spreadsheet.
212
Tools Used for LON Testing / Troubleshooting
• Tools used in Louisville

– LNBuilder (requires a LonTalk Converter for the PC)
– FX Supervisor – when troubleshooting a problem with a Tridium
Niagra front end integration.
– LonMark Certification Tool – to certify the E-LINK profile
– Loytech LON Protocol Analyzer (requires a hardware NIC
interface from the PC to the LonTalk trunk)
– NAE5520-2 using the LON Integration
– WireShark

213
N2 Technology Overview
March 2012
214
•• N2
N2 Server
Server Tech
Tech Spec.docx
Spec.docx

215
What is N2?
The N2 Bus is an open Johnson Controls field communications trunk that
links Application Specific Controllers (ASCs) and programmable controllers to
a supervisory controller. ASCs include the Air Handling Unit (AHU) controller,
Unitary (UNT) controller, VAV controllers, and VAV Modular Assembly
devices.
Programmable controllers include the DX9100. The N2 Bus supports Metasys
system compatible devices from other manufacturers and the Metasys
Integrator® system.

216
N2 Protocol
The N2 protocol is based on Opto-22 Optomux protocol, which was designed
for industrial applications, and is a proven communication network. The
N2 Bus follows the electrical characteristics of Electronics Industry
Alliance (EIA) Standard RS-485. It is optically isolated between itself and
other devices (except UNT100/101, VAV100/101, and Companion
Personal Computer), assuring reliable operation and noise immunity.

217
N2 Protocol
The N2 System protocol is a general interface for accessing data that resides
in devices on the N2 network. Each device on the N2 can be thought of as a
data base manager. The key to referencing a specific N2 device’s data base
is the device’s N2 address. The data under the management of a particular
N2 device can further be subdivided into groupings called regions. Each
region is made up of one or more records, each record within a region
having the same structure.
For the N2 System protocol, the N2 model hardware device is the “virtual
object.” The virtual object is shown below. It is made up of other objects:
1) analog inputs, 2) binary inputs, 3) analog outputs, 4) binary outputs, 5)
float internal values, 6) integer internal values (16 bit), and 7) byte (8 bit)
internal values. There may be a maximum of 256 of each type.

218
N2 Protocol
The virtual objects are defined with a Target, Net Point Type (NPT) and a
Net Point Address (NPA). For the E-LINK the net point types are defined as
an ADF, ADI, or BD.

219
N2 Protocol
an ADF, ADI, or BD.
Example using the conversion worksheet per equipment type (discussed
later):

220
N2 Protocol
an ADF, ADI, or BD.
Example using the conversion worksheet per equipment type (discussed
later):

221
N2 Communication Bus
The N2 Communications Bus is a local network that links controllers and
point interfaces to a Supervisory Controller (an NAE or Network Control
Module (NCM)). The N2 Bus uses a master/slave protocol, in which the
master device, the NCM, initiates all communication with the N2 Bus devices.
These N2 Bus devices include the Digital Control Modules (DCMs), Point
Multiplex Modules (XBN,XRE, XRL, XRM), and all Application Specific
Controllers (ASCs).

222
N2 Communication Bus
The N2 Bus carries all communication between the NCM and the N2 devices.
The types of data that go across the bus include:
• commands from the Supervisory Controller to an N2 device
• data requests from the Supervisory Controller to an N2 device
• responses from an N2 device to the Supervisory Controller, including
identification, changes-of-state, advisories, and requested data values
• complete databases for N2 devices
• time synchronization message from Supervisory Controller
The N2 Bus has three different types of communication, four priority

levels, and a specific method of data transmission.

223
Communication Types
The N2 Bus features three different types of communication, which may
come from either a Supervisory Device or any user interface device: offline
poll, online poll, and general communication. The Supervisory Device
initiates all three communication types.

224
Communication Types
Offline Poll—
a request from the NCM to re-establish communication
with an offline device. This type of poll occurs continually between the
NCM and each offline N2 device that is defined in the NCM database.
An offline device is polled once after every complete scan of all online
devices. Once communication is established, the NCM begins sending
online polls to the device.

225
Communication Types
Online Poll—
a request from the Supervisory Controller to the N2 device for any status
changes. The Supervisory Controller polls devices continually, according to
the priority levels assigned to the devices. Polling is interrupted momentarily
when a command is issued through general communication.

226
Communication Types
General Communication—
commands and requests that come from application programs or operator
devices. These can occur anywhere on the network. This type of
communication takes precedence over polling. After general communication
finishes, polling of online and offline devices resumes.

227
Priority Levels
There are four priority levels assigned to N2 devices: 0, 1, 2, and 3, where
0 is the highest. The priorities establish how often a device is to be polled.
For example, a Priority 2 device will be polled more often than a Priority 3
device. How often a device will be polled depends on its assigned priority.
You set the priority level when defining the N2 device.
We recommend the priority levels remain the system defaults (e.g., DCMs at
Priority 1 and ASCs at Priority 3). However, you may assign higher priorities
to a limited number of devices if your application requires faster response
time

228
Data Transmission
The figure illustrates how a data request from an Operator Workstation
(OWS) travels over the N1 Local Area Network (LAN) and the N2 Bus:
1. The request is created at the OWS.
2. The message is transmitted over the N1 LAN to the NCM that has this
object defined. The NCM reformats the message.
3. The NCM sends the message over the N2 Bus to the appropriate
device to obtain the requested information. The N2 device responds.
4. The NCM sends the data to the requesting OWS.
5. If the N2 device in the request loop is offline, the NCM notifies the
OWS.

229
Data Transmission
To take this example one step further, suppose a point object at an N2
device changes state and needs to notify you at the OWS. As mentioned
before, the NCM continually polls all N2 devices over the N2 Bus for
changes in status. When a change occurs, the NCM will be sent that
change when it polls the N2 device. The NCM then formats a
Change-of-State (COS) message and sends it over the N1 LAN to the
OWS (and other devices in the NCM’s routing table for that particular
COS message).

230
Estimating Your System’s N2 Traffic
The number of messages allowed on the N2 Bus differ depending on the
ASC firmware revision.
A maximum of 1100 messages per minute are allowed on the N2 Bus
unless it is connected to one of the following controllers (in which case
900 messages per minute are allowed):
• Air Handling Unit (AHU) Version C02 or lower
• One Unitary (UNT) Controller Version B02 or lower
• Variable Air Volume (VAV) Controller Version A02 or lower

231
Estimating Your System’s N2 Traffic
Refer to the following steps to determine the average rate at which
messages are traveling over the N2 Bus:
1. Using the N2/L2/S2 Statistics window, track the number of polls,
commands, and offline polls for a five minute period during peak
usage.
To do this, clear the statistics and reread them after the five minute
period.
2. Using the statistics from the five minute period, multiply the number
of offline polls by four (since offline polls take four times longer to
complete), add it to the total number of commands and polls, and
divide the total by five to calculate the total number of polls per
minute.
commands + polls + 4 (offline polls) = number of polls per minute

5

232
N2 OSI Model
N2 Layers Equivalent OSI Layers

Application Protocol Client / Server (NCM / NAE) Application (7)
TCP (NCM / NAE) Transport (4)
IP (NCM / NAE) Network (3)
ISO 8802-2 (IEEE 8802.3) Data Link (2)
N2 Serial Line Protocol
Type 1IP (NCM / NAE)
ISO 8802-3 (IEEE 802.3) IP Physical (1)
EIA-485
(NCM / NAE)
E-Link N2 Overview
233
N2 LAN Overview

234
Creating an Equipment N2 Import File
Using the Individual worksheets per equipment type, fill in the mapping
information required by the equipment points list.

235
Run the csv2xml.exe within the same directory as the equipment csv file.

236
The csv2xml.exe window appears, use the File -> Select CSV File to Convert to
IMP (XML File) to convert the equipment csv file to an XML import file for the
NAE

237
Select the desired CSV file and select Open

238
The select file is converted into an IMP file for the NAE, in the same directory
as the executable was ran. Select OK.

239
The conversion Tool window displays the IMP file contents.

240
The directory contains the IMP file.

241
Now that you have an equipment template, you can provide a tool to the filed
that will change the N2 address within the IMP foile for the E-LINK. You would
use the Mod_N2.exe to accomplish this,

242
Changing an N2 Equipment Address within the N2 Import File
Run the Mod-N2.exe within the same directory as the equipment csv file.

243
The Mod_N2.exe window appears, use the File -> Select IMP File to modify N2
Address to change the equipment address within the IMP file.

244
Select the desired IMP file and select Open

245
Enter the desired equipment address and select OK

246
The conversion Tool window displays the IMP file contents.

247
Tools Used for N2 Testing / Troubleshooting
• Tools used in Louisville

– N2 Simulator – JCI Engineering
– Yomotori N2 Simulator – JCI Japan Engineering
– N2 MON JCI Engineering
– N2 Certification Program
– NAE5520-2 N2 Integration

248
Support of the E-LINK CNF Files
(Introduction to IcE 2.0)
March 2012
249
IcE 2.0 Installed – Location and Files
Password =
cow&chicken

250
IcE 2.0 Installed – Location and Files
Password =
cow&chicken

251
IcE 2.0 Installed – TPL Files

252
IcE 2.0 BACdoc.in – Location

253
IcE 2.0 BACdoc.in – File Contents

254

255

256

257
IcE 2.0 Connections Tab

258
IcE 2.0 Connections Tab – Connection Settings

259
IcE 2.0 BACdoc.in – Connections Settings - Configure

260
IcE 2.0 Connections Tab – Auto Discovery

261
IcE 2.0 Connections Tab – Connections Tab

262
IcE 2.0 Units Tab – Save Template From

263
IcE 2.0 Units Tab – Connections Tab – Save From

264
IcE 2.0 Units Tab – Connections Tab – Save From

265
IcE 2.0 Connections Tab – Open A Database

266
IcE 2.0 Connections Tab – Open A Database – Database Selected
Visio 2003 Required for install

Newer versions or missing Visio
2003 will not allow install

267
IcE 2.0 Connections Tab – Open A Database – Data Base Open

268
Known Issues with IcE (Installation and Use)
• There are known problems with using the IcE tool. The IcE
2.0 tool was in development when Johnson Controls
acquired York, the product had identified problems but root
causes were not identified prior to the shelving any further
development to this tool.
– IcE 2.0 requires Visio 2003 to be installed on the pc prior to the
IcE install. No other version of Visio will allow the IcE install to
complete.
– IcE 2.0 requires a dongle to run. A new version of the
YorkComm32.exe has been developed that does not require the
dongle, but the use of this version is restricted for engineering
purposes only.

269
Known Issues with IcE (Random File Problems)
• There are known problems with using the IcE tool. The IcE
2.0 tool was in development when Johnson Controls
acquired York, the product had identified problems but root
causes were not identified prior to the shelving any further
development to this tool.
– There have been intermittent CNF file corruptions, some causing
the status LED to indicate a custom database when it was not.
– There have been random missing changes found in the different
versions of the CNF file. The change was in the previous
version, but when a new version was developed the CNF file
were missing some of the previous changes.
– There have been instances where edits / changes were not
saved even though a save database was performed prior to
shutdown of IcE.
Due to the above problems, a complete (all equipment and protocol
profiles) test of the E-LINK application is required for each new version
of the CNF file.

270
Questions?
Thank you for participating
End of E-Link Boot Camp Day1

271

Day 1 E-Link Overview - Version 1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Day 1 E-Link Overview - Version 1

Hochgeladen von

Copyright:

Verfügbare Formate

Welcome to E-LINK BOOT CAMP

E-Link Theory of Operation

FSP MicroGateway ISN Gateway Era

E-Link Theory of Operation

FSP MicroGateway Quick Start Gateway Era

E-Link Theory of Operation

FSP MicroGateway RMD Gateway Era

E-Link Theory of Operation

FSP MicroGateway ConneXsys Gateway Era

E-Link Theory of Operation

• Johnson Controls E-LINK

FSP E-LINK Switch Bank “A”

IcE OS Switch Bank “C”

E-Link Theory of Operation

E-Link Theory of Operation

E-Link Theory of Operation

E-Link Theory of Operation

• YORK Equipment Protocols – Profile Quick Starts

• Open Network Protocols – Protocol Quick Starts

E-Link Theory of Operation

• Three Primary User Cases for E-LINK Development

E-Link Theory of Operation

• User Case 1– MicroGateway Replacement

E-Link Theory of Operation

• User Case 2– BACnet MS/TP Enabled Equipment

E-Link Theory of Operation

• User Case 3– Modbus RTU Enabled Equipment

E-Link Theory of Operation

Node Quick Quick

E-Link Theory of Operation

Part Number Description

E-Link Theory of Operation

E-Link Theory of Operation

OptiView/Latitude Installation Kit

E-Link Theory of Operation

115 VAC / 230 VAC Supply Power

Com Shield Termination

E-Link Theory of Operation

LON Interface (optional)

E-Link Theory of operation

Port1 Port2A Port2B Port3 Port4

TX /RX LED – LON Trunk Activity (intermittent

Commission LED – Flashing RED device is not

PWR LED– solid green as soon as power is

GPIO5 LED – solid green as soon as BACnet

Ethernet Service Port – Has an Ethernet Link

E-Link Theory of Operation

Pushbutton activates Quick Start

Status LED – RED Sequenced

E-Link Theory of Operation

An equipment to E-LINK communication fault is presently

E-Link Theory of Operation

The following information

E-Link Theory of Operation

E-Link Theory of Operation

All YORK Chillers use the

E-Link Theory of Operation

ENG ASCII GPIC York Talk ISN LINC York Talk N2

The complete set of equipment points lists is available on the Portal

ENG ASCII GPIC York Talk ISN LINC York Talk N2

The complete set of equipment points lists is available on the Portal

Switch Settings 32 16 8 4 2 1 Functionality Release 2.2 LON XIF File

E-Link Theory of Operation