ControlNet Network For Developers

Allen-Bradley
ControlNet
Network
(Cat. No. 9220PDG51)
Product
Developers
Guide
Important User
Information
Because of the variety of uses for the products described in this

publication, those responsible for the application and use of this
control equipment must satisfy themselves that all necessary steps
have been taken to assure that each application and use meets all
performance and safety requirements, including any applicable laws,
regulations, codes and standards.
The illustrations, charts, sample programs and layout examples
shown in this guide are intended solely for purposes of example.
Since there are many variables and requirements associated with any
particular installation, Allen-Bradley does not assume responsibility
or liability (to include intellectual property liability) for actual use
based upon the examples shown in this publication.
Allen-Bradley publication SGI-1.1, Safety Guidelines for the
Application, Installation, and Maintenance of Solid-State Control
(available from your local Allen-Bradley office), describes some
important differences between solid-state equipment and
electromechanical devices that should be taken into consideration
when applying products such as those described in this publication.
Reproduction of the contents of this copyrighted publication, in
whole or in part, without written permission of Allen-Bradley
Company, Inc., is prohibited.
Throughout this manual we use notes to make you aware of safety
considerations:
ATTENTION: Identifies information about practices

or circumstances that can lead to personal injury or
death, property damage or economic loss.
Attention statements help you to:

identify a hazard
avoid the hazard
recognize the consequences
Important:
Identifies information that is critical for successful

application and understanding of the product.
ControlNet is a trademark; PLC is a registered trademark of Allen-Bradley Company, Inc.
Table of Contents
An Introduction To The
ControlNet Network
Chapter 1
ControlNet Network Protocol
Chapter 2
The ControlNet Network Mission . . . . . . . . . . . . . . . . . . . . . . . . . .

The ControlNet Network as a part of an Allen-Bradley Architecture .
Object Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ControlNet Communication Model . . . . . . . . . . . . . . . . . . . . .
Communication Model Components . . . . . . . . . . . . . . . . . . . . .
ControlNet Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Product Components . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Media Access Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scheduled Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unscheduled Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guardband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Configuration
21
22
23
24
Chapter 3
Network and Station Management Introduction . . . . . . . . . . . . . . . .
ControlNet Configuration Manager Node . . . . . . . . . . . . . . . . . . . .
Kept Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Communication
11
12
13
14
15
17
18
19
110
31
32
32
Chapter 4
ControlNet Network Packet Format . . . . . . . . . . . . . . . . . . . . . . . .
MAC Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lpacket Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unconnected Message Manager (UCMM) . . . . . . . . . . . . . . .
Message Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Producer/Consumer Model . . . . . . . . . . . . . . . . . . . . . . . . . .
Object Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Producer/Consumer Connection Types . . . . . . . . . . . . . . . . . . .
Transport Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Class 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Connection Types . . . . . . . . . . . . . . . . . . . . . . . . . . .
Point-to-Point Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Point-to-Point Class 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multicast Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Release 0.91 (Preliminary)
41
42
43
44
45
45
46
47
47
48
48
49
49
410
410
411
412
413
Publication 92206.5.1 January 1997
tocii
Table of Contents
ControlNet Enablers
Chapter 5
The CNA10 ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dual-port RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CNA10 Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unconnected Message Manager (UCMM) . . . . . . . . . . . . . . . . .
Message Router (MR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Manager (CM) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Time Critical Bandwidth Allocation in the Connection Manager .
ControlNet Configuration Manager . . . . . . . . . . . . . . . . . . . . . .
Communication Example Code . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messaging Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adapter Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scanner Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Physical Media
Chapter 6
Overview of Physical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Specifications And Parameters . . . . . . . . . . . . . . . . . . . .
Tap Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical Layer Repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redundant Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alternate Network Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview Of The ControlNet

Cable System
Planning A ControlNet Cable

System
51
54
55
55
56
56
57
57
57
58
58
59
59
510
510
61
62
63
63
64
64
Chapter 7
Understanding The
ControlNet Cable System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding ControlNet Components . . . . . . . . . . . . . . . . . . . . .
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trunk Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cable Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
73
73
74
74
75
75
75
76
76
77
77
Chapter 8
Determining How Many Taps You Need . . . . . . . . . . . . . . . . . . . . .
Connecting Programming Devices . . . . . . . . . . . . . . . . . . . . . . . .
Determining What Type Of Cable You Need . . . . . . . . . . . . . . . . . .
82
83
84
Table of Contents
Determining Trunk-Cable Section Lengths . . . . . . . . . . . . . . . . . . .

Determining How Many Terminators You Need . . . . . . . . . . . . . . . .
Determining If You Need Repeaters . . . . . . . . . . . . . . . . . . . . . . .
Configuring Your Link with Repeaters . . . . . . . . . . . . . . . . . . . .
Installing Repeaters in Series . . . . . . . . . . . . . . . . . . . . . . . .
Installing Repeaters in Parallel . . . . . . . . . . . . . . . . . . . . . . .
Installing Repeaters in a Combination of Series and Parallel . .
Determining What Type Of Connectors You Need . . . . . . . . . . . . . .
Using Redundant Media (optional) . . . . . . . . . . . . . . . . . . . . . . . .
Application Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Wiring Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wiring External to Enclosures . . . . . . . . . . . . . . . . . . . . . . . .
Wiring Inside Enclosures . . . . . . . . . . . . . . . . . . . . . . . . . . .
Surge Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ferrite Beads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordering Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Link Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordering Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing A ControlNet Cable

System
tociii
84
85
86
87
88
89
810
811
812
815
815
815
816
816
816
817
817
817
817
818
Chapter 9
Installing The Trunk Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wiring External to Enclosures . . . . . . . . . . . . . . . . . . . . . . . . . .
Wiring Inside Enclosures . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting The Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting Where to Mount the Taps . . . . . . . . . . . . . . . . . . . . . .
Mounting the Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting a tie wrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting a Tap using a Universal Mounting Bracket . . . . . . . .
Mounting a Tap through the Body Holes . . . . . . . . . . . . . . . . .
Installing A Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
European Union Directive Compliance . . . . . . . . . . . . . . . . . . . .
EMC Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low Voltage Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting Where to Mount the Repeater(s) . . . . . . . . . . . . . . . . .
Mounting the Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grounding the Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting Power and Relay Circuitry . . . . . . . . . . . . . . . . . . . .
Installing Cable Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecting Your Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stripping the Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing for Electrical Shorts and Continuity . . . . . . . . . . . . . . . . .
Attaching the Connectors to the Cable . . . . . . . . . . . . . . . . . . . .
Testing for Electrical Shorts and Continuity . . . . . . . . . . . . . . . . .
91
91
91
92
92
92
92
93
94
94
95
95
95
95
96
96
97
99
99
910
914
915
917
tociv
Table of Contents
Connecting Cable Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Terminating Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting Programming Terminals Through the NAP . . . . . . . .
Connecting a Repeater to a ControlNet Link . . . . . . . . . . . . . . . .
Mounting Dimensions
Chapter 10
Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Universal Mounting Bracket . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adjusting The Cable Strip

Tool
101
102
102
Chapter 11
Adjusting The Cutting Blades . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reversing/Replacing
The Cutting Blades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing The Memory Blade Holder . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Cable System

Component List
Chapter 12
Installing The ControlNet

Coax Repeater
Chapter 13

Network Access Cable
Chapter 14

Coax Tap
Chapter 15
918
918
919
919
921
ControlNet Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contacting Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About The Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Preparing For Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
European Union Directive Compliance . . . . . . . . . . . . . . . . . . . . . .
EMC Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low Voltage Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting The Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grounding The Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connecting Power And Relay Circuitry . . . . . . . . . . . . . . . . . . . . .
Connecting The Repeater To Your ControlNet Segments . . . . . . . .
Front-panel Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Status Indicators Under Normal Conditions . . . . . . . . . . . . . . . .
Status Indicators Under Fault Conditions . . . . . . . . . . . . . . . . . .
Agency Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifying Package Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
112
114
122
124
132
133
133
133
134
135
136
137
139
1310
1311
1311
1311
1312
1312
141
151
Table of Contents
Selecting Where To Mount The Tap . . . . . . . . . . . . . . . . . . . . . . . .

Mounting The Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting a Tap using a Universal Mounting Bracket . . . . . . . . . .
Mounting a Tap through the Body Holes . . . . . . . . . . . . . . . . . . .
Mounting Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Universal Mounting Bracket . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Coax Physical

Layer
Chapter 16
ControlNet Physical And

Publication Standards
Chapter 17
The Physical Layer As A Component . . . . . . . . . . . . . . . . . . . . . .

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Electrical Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mechanical/Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coax Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simplified Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coax Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simplified Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Media Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Over Voltage Diodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schottky Diodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cable Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Access Port (NAP) . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technical Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
NAP Support on the ASIC . . . . . . . . . . . . . . . . . . . . . . . . . .
Ground Isolation Requirement . . . . . . . . . . . . . . . . . . . . . . .
ATPT Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NAP Cable Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layout Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Hybrid Transceiver . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Physical Layer Specifications . . . . . . . . . . . . . . . . . . .
Network Access Port Cable Schematic . . . . . . . . . . . . . . . . . . . . .
Selecting And Using LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General Use of LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tocv
152
152
153
154
155
155
156
162
162
163
163
163
164
165
165
166
166
167
167
168
168
1610
1610
1610
1611
1611
1612
1612
1616
1618
1618
1619
1619
1619
1620
1621
1622
1622
1624
171
171
tocvi
Table of Contents
LED Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module Status LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LEDs at Power Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Status LED (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LED Flash Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standardizing Switch Behavior . . . . . . . . . . . . . . . . . . . . . . . . .
Switches Read at Power Turn On . . . . . . . . . . . . . . . . . . . . . . .
Software Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Product Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Publication Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . .
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Do not . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Data
Management
171
172
173
175
175
176
176
176
176
177
177
177
177
178
179
Chapter 18
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Type Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Type Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Elementary data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Derived Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Character String Data Types . . . . . . . . . . . . . . . . . . . . . . . . .
Structured Bit String Types . . . . . . . . . . . . . . . . . . . . . . . . . .
Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Elementary Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations on Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . .
IEC Extended Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IEC 11313 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compliance Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementation-dependent Parameters . . . . . . . . . . . . . . . . . . .
Language Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstract Syntax Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Type Specification/Dictionaries . . . . . . . . . . . . . . . . . . . . . . .
Transfer Syntax: Compact Encoding . . . . . . . . . . . . . . . . . . . . . . .
Compact Encoding Constraints . . . . . . . . . . . . . . . . . . . . . . . . .
Encoding Rules and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOL Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
182
182
183
183
183
183
184
184
184
186
186
186
187
187
187
187
187
188
189
1813
1814
1814
1815
1818
1821
1821
1822
1822
Table of Contents
SignedInteger Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UnsignedInteger Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FixedLengthReal Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AnyTime Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FTIME Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LTIME Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AnyString Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Array Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of How More Complex Data Formats are Encoded .
Example 1: Encoding an Array of Structures . . . . . . . . . . . . .
Example 2: Encoding a Structure with an Array Element . . . . .
ControlNet Object Overview
1822
1823
1823
1825
1825
1825
1826
1827
1829
1830
1830
1830
Chapter 19
Where Objects Fit In The ControlNet Network . . . . . . . . . . . . . . . .
Terms Used In This Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding An Object Specification . . . . . . . . . . . . . . . . . . . . .
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get_Attributes_All Response . . . . . . . . . . . . . . . . . . . . . . . .
Set_Attributes_All Request . . . . . . . . . . . . . . . . . . . . . . . . . .
Class-specific Extensions to Common Services . . . . . . . . . . . . .
Class-specific Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Response Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ContolNet Addressing
tocvii
191
191
192
193
193
193
193
196
196
197
198
198
198
199
1910
1910
1910
1912
Chapter 20
Connection Path (Conn_path) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Connection ID (Conn_ID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Selecting Connection IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Allocating CIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Multicast Producer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Point-to-Point Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Specifying The Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Multi-port Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Logical Address - Internal Object Identifier (IOI) . . . . . . . . . . . . . . . 208
Connection Path Specified By Path Segments . . . . . . . . . . . . . . . . 209
Connection Path Size (Conn_Path_Size) . . . . . . . . . . . . . . . . . . 2010
tocviii
Table of Contents
Path Segment Type (Path_Seg_Type) . . . . . . . . . . . . . . . . . . . . . .

Segments in the Connection Path . . . . . . . . . . . . . . . . . . . . . . .
Path Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Path Connection Through Bridges . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Messaging
Chapter 21
Messaging Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure of a General Request Message . . . . . . . . . . . . . . . . . .
Message Service Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Object Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure of a General Response Message . . . . . . . . . . . . . . . .
Object/Service-Specific Extended Status . . . . . . . . . . . . . . . . . .
Data Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allocation of Service Codes for Common Services . . . . . . . . . . .
Allocation of General Status Error Codes . . . . . . . . . . . . . . . . . .
Message Router (MR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using a Message Router in a Device . . . . . . . . . . . . . . . . . . . . .
Data Sent by Message Router to Destination Object . . . . . . . . . .
Message Router Interpretation of the IOI . . . . . . . . . . . . . . . . . .
Interpretation of Commonly Used IOIs . . . . . . . . . . . . . . . . . .
Interpretation of Complex IOIs . . . . . . . . . . . . . . . . . . . . . . .
Handling the Response from the Destination Object . . . . . . . . . .
Unconnected Message Manager . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples Of Messaging Packets . . . . . . . . . . . . . . . . . . . . . . . . .
Establshing A ControlNet
Network Configuration
2010
2011
2011
2012
2013
2014
211
212
212
212
213
213
214
215
215
215
216
217
219
219
2110
2111
2111
2111
2111
2112
2113
Chapter 22
Setting Up Connections Before Any Connections Are Made . . . . . . 222
Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Data Flow within the Connection Manager . . . . . . . . . . . . . . . . . 223
Example Connection Based On The Data Flow Diagram For The Connection
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Before the Connection can be Opened . . . . . . . . . . . . . . . . . . . 226
Originating Application Opens the Connection . . . . . . . . . . . . . . 226
Originating Connection Manager Receives the OPEN Message . . 226
Originating (Client) UCMM Sends Message . . . . . . . . . . . . . . . . 227
Target Connection Manager Receives FWD_OPEN . . . . . . . . . . 227
Target Application Builds Transport . . . . . . . . . . . . . . . . . . . . . . 227
Target Connection Manager Completes Connection . . . . . . . . . . 228
Target UCMM Forwards Reply . . . . . . . . . . . . . . . . . . . . . . . . . 228
Originating Connection Manager Completes the Connection . . . . 228
Table of Contents
Originating Application Uses the Connection . . . . . . . . . . . . . . .

Connection Manager Services . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Manager Service Parameters Description . . . . . . . . .
Nomenclature Used in the Descriptions . . . . . . . . . . . . . . . . . . .
Service (Service_Code) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IOI Address Size (IOI_Size) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Object Identifier (IOI) . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Manager Service Descriptions . . . . . . . . . . . . . . . . . . .
OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPEN_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lack of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Invalid Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Target node is powering up . . . . . . . . . . . . . . . . . . . . . . . . . .
FWD_OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the FWD_OPEN Service . . . . . . . . . . . . . . . . . . . . . .
FWD_OPEN_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the FWD_OPEN_REPLY Service . . . . . . . . . . . . . . . .
CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLOSE_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FWD_CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of FWD_CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FWD_CLOSE_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the FWD_CLOSE_REPLY . . . . . . . . . . . . . . . . . . . . .
APP_OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
APP_OPEN_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
APP_CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
APP_CLOSE_REPLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GET_ATTRIBUTES_LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SET_ATTRIBUTES_LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating A ControlNet
Statement Of Compliance
Chapter 23
ControlNet Conformance
Criteria
Chapter 24
Whats Included . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Required Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completing The Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guidelines for Object-specific Information . . . . . . . . . . . . . . . . .
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completion Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical Compliance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Technology Compliance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Compliance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . .
tocix
228
229
229
229
229
2210
2210
2211
2215
2215
2216
2216
2216
2217
2217
2218
2219
2219
2221
2222
2222
2223
2223
2224
2225
2226
2226
2226
2226
2226
231
231
232
232
232
233
242
243
244
tocx
Table of Contents
Using The ControlNet

Network Compliance Tool
Chapter 25
Developing A ContolNet
Conformance Test Plan
Chapter 26
Introduction To ControlNet
Configruration
Chapter 27
Manager (CCM)
Chapter 28
Network And Port

Parameters
Chapter 29
Understanding The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Installing The Compliance Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Configuring The Traffic Analyzer Tool . . . . . . . . . . . . . . . . . . . . . . 255
Using The Compliance Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2510
Understanding The Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2512
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2513
Purpose Of The Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risks/Contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support Personnel And Resources . . . . . . . . . . . . . . . . . . . . . . . .
Audit Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network And Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

Device-specific Application Configuration Data . . . . . . . . . . . . . . . .
Device-specific Non-volatile Storage Data . . . . . . . . . . . . . . . . . . .
CCM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporary CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Real CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auto-address Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
smax (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
umax (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
slot_time (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
blank_time (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
gb_start (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
gb_center (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
261
261
261
262
262
263
263
263
263
263
264
272
273
273
281
282
283
285
285
291
292
292
292
292
292
292
293
Table of Contents
redundancy: Redundancy Control (USINT) . . . . . . . . . . . . . . . .

int_cnt_mod (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
gb_prestart (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sched_max_frame (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . .
status (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
macrocycle_start (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
macrocycle_length (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . .
macrocycle_count (USINT) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
macrocycle_multiplier (USINT) . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Rates
tocxi
293
293
293
293
293
294
294
294
294
294
Chapter 30
Network Update Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Possible Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Multiple Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Accepting/Rejecting Connections . . . . . . . . . . . . . . . . . . . . . . . . . 306
Order Of Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
ControlNet Rates Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 308
Sample Breadth-first Accept/Reject Algorithm . . . . . . . . . . . . . . . . 309
Sample Delete Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3012
Offline Configuration
Chapter 31
Online Configuration
Chapter 32
Who Command (For Active

And Inactive Nodes)
Chapter 33
Network Change
Chapter 34
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suggested Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reservation Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changes/Assumptions About Connection Manager and ControlNet
Object
Assumptions Prior to Starting the Network Change . . . . . . . . . . .
331
331
331
331
332
341
341
341
342
342
342
342
342
343
343
tocxii
Table of Contents
Network Change Description . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Change
Chapter 35
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Miscellaneous
Information
Chapter 36
System Configuration
Glossary
Chapter 37
344
Adding A Device To An Existing Network . . . . . . . . . . . . . . . . . . . .

Deleting A Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replacing A Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying Device Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Scheduled Max Bytes . . . . . . . . . . . . . . . . . . . . . . . .
Cold Power Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Powering Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Warm Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Powering Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removal and Insertion under Power . . . . . . . . . . . . . . . . . . . . .
Dup Node Listen-only Behavior . . . . . . . . . . . . . . . . . . . . . . . . .
Rogue And Dup Node Error Recovery . . . . . . . . . . . . . . . . . . . . . .
Rogue Node Listen-only Behavior . . . . . . . . . . . . . . . . . . . . . . .
Redundant Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior: Unplugged And Moved Node . . . . . . . . . . . . . . . . . . . .
Node Un-powered when Moved . . . . . . . . . . . . . . . . . . . . . . . .
Node under Power when Moved (Cable Swap) . . . . . . . . . . . . . .
Evil CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior: Shared ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior: Listen-only Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Save And Restore Behavior . . . . . . . . . . . . . . . . . . .
CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporary CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Listen-only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moderator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Powered-on Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reservation Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
351
351
351
352
352
361
361
361
362
362
362
362
362
362
362
363
363
363
363
363
363
363
364
364
364
364
371
371
371
371
371
371
372
372
372
372
372
Table of Contents
Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rogue Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evil CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rogue Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lonely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Message/Traffic Generator
Tool
Chapter 38
Using The ControlNet Traffic

Analyzer Tool
Chapter 39
Introducing The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Network Update Time . . . . . . . . . . . . . . . . . . . . .
Changing the Port Number of the 9220-KTCT Card . . . . . . . . . .
Changing the MAC ID of the 9220-KTCT Card . . . . . . . . . . . . . .
Viewing the Current Status of the Tool . . . . . . . . . . . . . . . . . . . .
Sending a Message to a Target Node . . . . . . . . . . . . . . . . . . . .
Sending Unconnected Messages . . . . . . . . . . . . . . . . . . . . . . .
Sending Predefined Unconnected Messages . . . . . . . . . . . . .
Getting Attribute Information . . . . . . . . . . . . . . . . . . . . . . . . .
Resetting a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Closing a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Traffic Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running a Separate DOS Program . . . . . . . . . . . . . . . . . . . . . .
Taking the Card Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exiting the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing The Tools Configuration File . . . . . . . . . . . . . . . . . . . . . . .
Example CNXOR.CFG File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message/Traffic Generator API Functions . . . . . . . . . . . . . . . . .
Introducing The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Navigating Through The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initializing The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpreting the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Details of a Single Packet . . . . . . . . . . . . . . . . . . . . . .
Customizing Your Operating Environment . . . . . . . . . . . . . . . . .
Adding and Editing Filter and Trigger Patterns . . . . . . . . . . . . . .
Editing the Tag and Control Bytes . . . . . . . . . . . . . . . . . . . . . . .
Using the Search Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Print Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tocxiii
372
372
373
373
373
373
382
382
383
385
386
386
387
387
388
388
3812
3812
3812
3813
3813
3814
3816
3817
3817
3817
3823
3827
391
392
393
394
395
3910
3910
3911
3912
3913
3914
3915
3915
tocxiv
Table of Contents
Using the File Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using the Statistics Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resetting the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initializing the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Transceiver
Hybrid Data Sheet
Chapter 40
Crystal Data Sheet
Chapter 41
Shipping Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solvent Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solderability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mechanical Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Package Pinouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommended Operating Conditions . . . . . . . . . . . . . . . . . . . . . .
Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allen-Bradley Manufacturing Notes . . . . . . . . . . . . . . . . . . . . . . . .

Solderability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shelf Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Package Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environmental Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crystal Oscillator Data Sheet
401
401
402
402
404
406
406
407
407
407
408
408
411
411
411
411
412
412
413
413
413
Chapter 42
Package Marking And Shipping Protection . . . . . . . . . . . . . . . . . . .
A-B Manufacturing Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solderability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wave Solderable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shelf Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3916
3917
3919
3919
3925
3928
3928
3928
421
421
421
422
422
422
422
423
424
Table of Contents
Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pin Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environmental Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Transformer Data

Sheet
Chapter 43
CNA10 ControlNet ASIC Data

Sheet
Chapter 44
Shipping Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solderability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Industry Standards Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
Approved Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mechanical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Construction Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dielectric Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CNA10 Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TQFP Pin Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MQFP Pin Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auto-configured and Run-time Configured Pins . . . . . . . . . . . . .
Description and Use of the Auto-configured Pins . . . . . . . . . .
Description and Use of the Run-time Configured Pins . . . . . . .
Tristated Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NAP Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Channel with No NAP in Coax Mode . . . . . . . . . . . . . . . .
Single Channel with NAP in Coax Mode . . . . . . . . . . . . . . . . . .
Redundant with No NAP in Coax Mode . . . . . . . . . . . . . . . . . . .
Redundant with NAP in Coax Mode . . . . . . . . . . . . . . . . . . . . . .
Redundant with NAP in Fiber Mode . . . . . . . . . . . . . . . . . . . . . .
Repeater in Coax Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeater in Fiber Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Oscillator and Crystal Specifications . . . . . . . . . . . . . . . . . . . . . . .
Host Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
StartOfCycle and CycleReset . . . . . . . . . . . . . . . . . . . . . . .
Normal Operation Definition . . . . . . . . . . . . . . . . . . . . . . . . .
Alternate Operation Definition . . . . . . . . . . . . . . . . . . . . . . . .
tocxv
424
424
425
425
426
431
431
432
432
432
432
434
435
435
442
443
446
447
448
4419
4429
4430
4430
4431
4432
4432
4433
4434
4436
4437
4439
4441
4443
4445
4447
4449
4450
4451
4451
4451
4452
tocxvi
Table of Contents
Spurious Internal Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EndOfCycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Read Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Write Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LED Request Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description of Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . .
LED Reflection of NAP Operation, Normal Network . . . . . . . . . .
LED Reflection of NAP Operation, NAP Only Mode . . . . . . . . . .
Blanking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Holdoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeater Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External Comm Processor ROM . . . . . . . . . . . . . . . . . . . . . . . . . .
Data[7:0] Pins are CMOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ready and /Dtack Stay Inactive During Reset . . . . . . . . . . . . . .
LBE must be active within 80ns for correct 16bit mode operation
Generic Screener is not disabled when transmitting . . . . . . . . . .
Example Hardware
Implementation
Chapter 45
General Design
Overview/Porting Guide
Chapter 46
Read-only Flash Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ROM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TTL Oscillator And LED Interfaces . . . . . . . . . . . . . . . . . . . . . . . .
Crystal Oscillator And LED Interfaces . . . . . . . . . . . . . . . . . . . . . .
Isolated NAP Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-isolated NAP Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . .
Redundant Coax Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCB Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCB Layout Figure 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coax Repeater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Food Chain And Its Components . . . . . . . . . . . . . . . . . . . . .
Foundation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FD Fundamental Definitions . . . . . . . . . . . . . . . . . . . . . . . .
BU Bit Manipulation Utilities . . . . . . . . . . . . . . . . . . . . . . . .
OS Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OE Operating Environment . . . . . . . . . . . . . . . . . . . . . . . .
4453
4455
4457
4459
4461
4461
4462
4465
4466
4467
4467
4468
4469
4469
4470
4471
4471
4471
4471
4471
452
453
454
455
456
457
458
459
4510
4511
4512
4513
4514
4515
462
464
464
464
465
465
465
Table of Contents
UC Utilities Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LQ Linked Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GS Global Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CB Communications Buffers . . . . . . . . . . . . . . . . . . . . . . .
CN ControlNet Specifics . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet ASIC Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CA CNA10 ASIC Specifics . . . . . . . . . . . . . . . . . . . . . . . . .
CS Communication Services . . . . . . . . . . . . . . . . . . . . . . .
CIP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DM Diagnostic Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . .
MR Message Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UM Unconnected Message Manager . . . . . . . . . . . . . . . . .
DO Device Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CM Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . .
RO Rack Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Program Interface (API) . . . . . . . . . . . . . . . . . . . . . .
AB Basic Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AM Messaging Services . . . . . . . . . . . . . . . . . . . . . . . . . .
AA Adapter Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EA Example Application . . . . . . . . . . . . . . . . . . . . . . . . . .
PC PC Specific Support Utilities . . . . . . . . . . . . . . . . . . . . .
PD PC Display Routines . . . . . . . . . . . . . . . . . . . . . . . . . .
TS Test Script Processor . . . . . . . . . . . . . . . . . . . . . . . . . .
DC Data Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Porting Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coding Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Function Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variable and Member Names . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typedefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static Storage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Listing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parenthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Increment and Decrement Operators . . . . . . . . . . . . . . . . . . .
Branch Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Braces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tocxvii
466
466
466
468
468
468
469
469
469
469
469
469
4610
4610
4610
4610
4610
4610
4610
4610
4611
4611
4611
4611
4611
4611
4612
4612
4613
4613
4613
4614
4614
4615
4615
4615
4616
4616
4616
4617
4617
4617
4617
4618
4618
tocxviii
Table of Contents
Parameter Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conditional Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Code blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Critical Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comment Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Banner comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Major block comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Minor block comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service prototype (.h file) comment . . . . . . . . . . . . . . . . . . . .
Data declaration (.h file) comment . . . . . . . . . . . . . . . . . . . . .
Service code (.c file) comment . . . . . . . . . . . . . . . . . . . . . . .
Code block comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Function Block comment . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conditional Block comment . . . . . . . . . . . . . . . . . . . . . . . . .
Operating Environment (OE)

Porting Guide
Chapter 47
API For Basic Service
Chapter 48
Why An RTOS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Description Of RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
RTOS Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
RTOS Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Detailed Requirements Of The RTOS . . . . . . . . . . . . . . . . . . . . . . 476
OE Defined Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
OE Defined Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
OE Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Creation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Task Control Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Event Control Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4710
Interrupt Entry/Exit Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 4712
RTOS Porting Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4714
AB Component Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AB Component Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ControlNet Example

Code AM API
4618
4618
4619
4619
4619
4619
4620
4621
4621
4621
4621
4622
4622
4622
481
482
Chapter 49
About The AM API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is supported by this API? . . . . . . . . . . . . . . . . . . . . . . . . .
What is not supported by this API? . . . . . . . . . . . . . . . . . . . . . .
Other Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CNEC Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AM API Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CS_ComBufType Data Type . . . . . . . . . . . . . . . . . . . . . . . . .
Task/Queue Object Model (TQOM) . . . . . . . . . . . . . . . . . . . .
AM Server (i.e., AM Object) . . . . . . . . . . . . . . . . . . . . . . . . . . .
491
492
492
493
493
493
493
495
496
Table of Contents
AM Server API Requirements . . . . . . . . . . . . . . . . . . . . . . . .

AM Server API Support . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tribbles for InterTask Object Communication . . . . . . . . . . . . .
AM Server API Interface Definition . . . . . . . . . . . . . . . . . . . .
PCCC API Design Detail Description . . . . . . . . . . . . . . . . . . . . . . .
DeQueue next PCCC Request . . . . . . . . . . . . . . . . . . . . . . . . .
Deencapsulate the PCCC Request . . . . . . . . . . . . . . . . . . . . .
Process the PCCC Request via the Application Function . . . . . . .
Encapsulate the PCCC Response . . . . . . . . . . . . . . . . . . . . . . .
QueuePCCC Response via Tribble . . . . . . . . . . . . . . . . . . . . .
AM API Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AM.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Globals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Public Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AM_Appl.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of Reading File Data . . . . . . . . . . . . . . . . . . . . . . . . . .
Declaring Array Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Packets
496
496
498
499
4910
4910
4910
4911
4912
4912
4912
4912
4913
4913
4913
4913
4914
4916
4916
4916
Chapter 50
Test Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Net and Port Parameter Updates . . . . . . . . . . . . . . . . . . . . . . .
Get_Attribute request/ reply to/ from the Device Object . . . . . . . .
Get_Attribute request / reply to / from the Rack Object . . . . . . . .
Forward Open Request / Reply to / from Message Router . . . . . .
Message to / from Message Router Object . . . . . . . . . . . . . . . . .
Forward Close Request / Reply to / from Message Router . . . . . .
Forward Open Request / Reply to the Rack Object . . . . . . . . . . .
Realtime Data to / from the Rack Object . . . . . . . . . . . . . . . . .
Forward Close Request / Reply to the Rack Object . . . . . . . . . . .
CNA30F Dualport
Description Version .9
tocxix
502
503
504
506
508
5010
5011
5013
5016
5017
Chapter 51
Dualport Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dualport Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASIC_Fault_Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Field Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASIC_to_HOST_Mask, ASIC_to_HOST_Request, and
ASIC_to_HOST_Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HOST_to_ASIC_Request and HOST_to_ASIC_Ack . . . . . . . . .
ASIC_Selftest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MAC Processor Fault Code Values . . . . . . . . . . . . . . . . . . . .
COMM Processor Fault Code Values . . . . . . . . . . . . . . . . . .
ASIC_WD_Count and HOST_WD_Count . . . . . . . . . . . . . . . . .
511
512
513
513
513
515
515
515
516
516
tocxx
Table of Contents
Start_Stop_Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Channel_Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Buffer_A_ASIC and Buffer_B_ASIC . . . . . . . . . . . . . . . . . . . . . . 518
Buffer_A_Host and Buffer_B_Host . . . . . . . . . . . . . . . . . . . . . . 519
Buffer_RX_Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Tx_Buffer_A_Mask and Tx_Buffer_B_Mask . . . . . . . . . . . . . . . . 5110
RX_Buffer_A_Mask and RX_Buffer_B_Mask . . . . . . . . . . . . . . . 5110
Event_Queue_Write_Index, Event_Queue_Read_Index, and
Event_Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110
Node_Address, Config_Type 279, Current_Net_Mode, Config_Result,
and Config_Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5114
Configuration Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5114
Node_Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5115
Config_Type and Config_Result . . . . . . . . . . . . . . . . . . . . . . 5116
Current_Net_Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5118
Config_Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5118
Feature Select Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5121
Operating Mode Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5121
Interval_Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5122
Comm_Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5123
UCMM_Tx_Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5123
UCMM_Tx_Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5123
UCMM_Rx_Source_MAC_TAG_Index . . . . . . . . . . . . . . . . . . . . 5123
UCMM_Rx_Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5124
Rx_Channel_Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5124
Tx_Channel_Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5125
Sanity Check Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5126
Objects Required In All

ControlNet Networks
Appendix A
Device / Identity Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reset Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get_Attributes_All Response . . . . . . . . . . . . . . . . . . . . . . . . . .
Object-specific Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication Module Example . . . . . . . . . . . . . . . . . . . . . . .
Controller Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Module Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message Router Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set_Attributes_All Request . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Object-specific Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A2
A5
A8
A9
A9
A9
A10
A10
A10
A11
A12
A14
A15
A16
A16
A16
Table of Contents
Message Router Connections . . . . . . . . . . . . . . . . . . . . . . . . . .

Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Manager Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class-specific Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCCC Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class-specific Services provided by the PCCC Object . . . . . . . .
Rack Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services for the 1771 Discrete I/O Rack . . . . . . . . . . .
Class-specific Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1771 Discrete I/O Connections . . . . . . . . . . . . . . . . . . . . . . . . .
Inputs Open_Connection Request Application Data . . . . . . . . . .
Packed Inputs Connection Structure . . . . . . . . . . . . . . . . . . . . .
Packed Outputs Connection Structure . . . . . . . . . . . . . . . . . . . .
Behavior Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set_Attributes_Single Request . . . . . . . . . . . . . . . . . . . . . . . . .
Set_Attributes_All Request . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class-specific Services provided by the ControlNet Object . . . . .
Sync Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get_And_Clear Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get_And_Clear Response . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Check_For_Moderator Service . . . . . . . . . . . . . . . . . . . . . . . . .
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Object Connections . . . . . . . . . . . . . . . . . . . . . . . . .
ControlNet Object MAC IDs . . . . . . . . . . . . . . . . . . . . . . . . . . .
External Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Listen-Only Network Parameters . . . . . . . . . . . . . . . . . . . . . . . .
Synchronization of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Indications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Object And Common

Service Definition Process
tocxxi
A16
A17
A17
A17
A18
A19
A20
A21
A21
A21
A25
A25
A27
A28
A28
A28
A28
A29
A29
A29
A32
A35
A40
A41
A42
A43
A46
A46
A47
A47
A47
A48
A49
A50
A50
A50
A51
A53
A56
A57
A59
Appendix B
Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process For Creating Or Modifying An Object Specification . . . . . . .
B1
B1
tocxxii
Table of Contents
Introduction to the Object Definition Process . . . . . . . . . . . . . . .

Overview of the Object Definition Process . . . . . . . . . . . . . . .
Participants in the Object Definition Process . . . . . . . . . . . . .
Detailed Object Definition Process . . . . . . . . . . . . . . . . . . . . . . . .
Guidelines for Creating or Modifying Object Specifications . . . . .
Rules for Modifying an Object Specification . . . . . . . . . . . . . .
Defining ControlNet Common Services . . . . . . . . . . . . . . . . . . . . .
How Services are Processed by Objects Whose Versions Differ .
Transport And Application

Connections
B1
B1
B2
B3
B5
B6
B8
B9
Appendix C
Transport Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C2
Tools Used to Discuss Transport Services . . . . . . . . . . . . . . . . . C3
Components Of Transport Connections . . . . . . . . . . . . . . . . . . . . . C3
Network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C3
Link Producer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C4
Data Flow Diagram (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . C4
State Transition Diagram (STD) . . . . . . . . . . . . . . . . . . . . . . C5
State Event Matrix (SEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . C5
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C5
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C5
Link Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C5
Data Flow Diagram (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . C6
State Event Matrix (SEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . C6
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C6
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C7
Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C7
TPDU Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C7
TPDU Buffer Management . . . . . . . . . . . . . . . . . . . . . . . . . C8
Transport Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C8
Classes 1, 2, and 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C9
Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C9
Creating Transport Connections . . . . . . . . . . . . . . . . . . . . . . . . . . C9
Binding Transports to Producers and Consumers of Network Connections
C10
Transport Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C13
Transport Class 1 (Duplicate Detection) . . . . . . . . . . . . . . . . . . . . . C13
Class 1 Client Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C15
State Event Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C16
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C16
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C16
Class 1 Server Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C16
State Event Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C18
Table of Contents
tocxxiii
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Class 3 (Verified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class 3 Client Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Transition Diagram (STD) . . . . . . . . . . . . . . . . . . . . . .
State Event Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class 3 Server Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Event Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unconnected Message Manager (Single-link Transport Class) . . . . .
Client Unconnected Message Manager (UCMM) . . . . . . . . . . . .
Client Transaction Record . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Transaction State Transition Diagram (STD) . . . . . . . . .
Client Transaction State Event Matrix . . . . . . . . . . . . . . . . . .
UCMM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Unconnected Message Manager (UCMM) . . . . . . . . . . . .
Server Transaction Record . . . . . . . . . . . . . . . . . . . . . . . . . .
High-end Server Transaction State Transition Diagram (STD) .
High-end Server Transaction State Event Matrix . . . . . . . . . . .
Low-end Server Transaction State Transition Diagram (STD) . .
Low-end Server Transaction State Event Matrix . . . . . . . . . . .
UCMM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UCMM Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Retry Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Flow Diagram (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . .
State Event Matrix (SEM) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interoperability of Transport Classes . . . . . . . . . . . . . . . . . . . . . . .
Transport Classes and Network Connections . . . . . . . . . . . . . . . . .
Transport Class 1 Duplicate Detection . . . . . . . . . . . . . . . . . . . .
Transport Class 3 Verified . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interoperability of Transport Classes and Network Connections . .
Transport Class/Network Connection Interoperability Matrix . . . .
Application Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Production Trigger, Transport Class and EPR . . . . . . . . . . . . . . .
C18
C18
C21
C26
C27
C28
C28
C28
C29
C30
C31
C32
C32
C33
C37
C37
C38
C39
C39
C40
C40
C40
C41
C42
C43
C43
C44
C44
C45
C46
C46
C47
C47
C47
C47
C48
C48
C48
C48
C48
C54
C54
C55
tocxxiv
Table of Contents
Chapter

This chapter introduces the ControlNet network. It contains these
sections:
The ControlNet Network

Mission
Control and I/O data is
information critical to the
operation of a process.
Section
Page
The ControlNet Network Mission
11
The ControlNet Network as a Part of an Allen-Bradley Architecture
12
Object Modeling
13
The ControlNet Communication Model
14
ControlNet Product Overview
17
ControlNet Enablers
19
ControlNet Media
110
The ControlNet networks mission is to provide reliable, high-speed

transport of two basic types of application information:
control and I/O data
non-time critical messaging data related to the controlled system
Control and I/O data are given highest priority. Other information,
such as programming or parameter upload and download operations,
does not interfere with the transport of control and I/O data.
The ControlNet network:
provides a high-speed control and I/O network
facilitates deterministic data transfer over the network
supports transparent media redundancy (optional)
combines the functions of RIO and DH+ networks into a single
LAN
supports easy configuration, maintenance, and troubleshooting
12
An Introduction To The ControlNet Network
The ControlNet Network as

a part of an Allen-Bradley
Architecture
The ControlNet network is designed to be the central communication

architecture for interoperating automation products. Figure 1.1
represents the ControlNet networks broad environment.
Figure 1.1
ControlNet-based Architecture
Customer Host Computer
Ethernet
Human
Interfaces
MultiVendor
Devices
Ethernet
Ethernet
Bridges/
Gateways
Numerical
Control
Drives
Weld
Control
Operator
Interfaces
ControlNet
PLCs
Chassis
ControlNet
Other
Automation
Suppliers
Products
PLCs
RIO
1771 I/O
Intelligent
Sensor/Actuator
DH+
DeviceNet
Sensor/Actuator
Flex I/O
DeviceNet
Single Point I/O
Sensor/Actuator
Single Point I/O
Object Modeling
13
The ControlNet network is designed through object modeling.

Object modeling organizes related data and procedures into one
entity: the object.
ControlNet
node
Objects
An object is a collection of related services and attributes. Services

are procedures an object performs. Attributes are characteristics of
objects represented by values, which can vary. Typically, attributes
provide status information or govern the operation of an object.
Attributes often represent the state of an object. The value
associated with an attribute may or may not affect the behavior of an
object. An objects behavior is an indication of how the object
responds to particular events.
Classes categorize objects. A class defines a particular type of
object and defines the characteristics shared by all the objects within
a class. For example, the human race could be represented by the
class Human with millions of objects within it.
A Class of
Objects
Objects within a class are called object instances. An object instance

is the actual representation of a particular object within a class. Each
instance of a class has the same set of attributes, but has its own set
of attribute values, which makes each instance in the class unique.
Each person in the human race can be represented by an instance
within the class Human. All humans have the same set of
attributes: eyes, ears, age, gender, etc. Yet, because the values of
each attribute vary, each of us looks different and performs in
distinct ways.
Class
Instances
Attributes
Attribute Values
Sex
Female
Age
31
Sex
Male
Age
50
Christy
hri ty
Human
uman
Charles
harle
A message is a
signal sent to an
object to request
a service.
Application objects communicate with each other by sending

messages. As shown in Figure 1.2, messages can be sent between
objects within a single node and across networks.
Figure 1.2
Application Object Message Paths
Object
Object
Object
Node 3
Object
Ethernet
Node 2
Node 1
Messages are shown as dashed arrows.
Object
ControlNet
14
The ControlNet
Communication Model
General relationships between the functions that comprise the

ControlNet communication model are illustrated in Figure 1.3.
All of the figures blocks below the Users Application Objects
reside within either a ControlNet ASIC or ControlNet class-specific
Example Code.
Figure 1.3
Model
Users Application Objects
control and
I/O data
connect request and

message data
Unconnected
Message
Manager
(UCMM)
Message
Router
data
trigger
Application Layer
Transport
Services
Transport Layer
Connection Manager
Connection
Tables
Network Layer
Link Layer Driver

Link Layer
Media Access Services

Media Access
Physical Layer Interface

Media
and
Physical
Layer
15
Communication Model Components

This section provides a bottom-up definition of each of the
ControlNet Communication Models components illustrated in
Figure 1.3, on page 14.
Media Access Service
Link Layer Driver
Unconnected
Message
Manager
(UCMM)
The Physical Layer Interface consists of the hardware components

which are necessary to get on and off the networks physical media.
It is responsible for:
providing transceiver components for the redundant coax media
ports
providing transceiver components for the Network Access Port
(NAP)
Media Access Service allows an application to transmit on the
networks media. This service is contained within the ControlNet
ASICs. It is responsible for:
providing transmit and receive data flow-control on and off the
media
checking received data for errors
adding the proper header and trailer information on transmit
frames
deleting header and trailer information from received frames
controlling the media redundancy switch-over algorithm
The Link Layer Driver assembles data into correctly-formatted
ControlNet frames and is responsible for:
setting up the Media Access Service
moving data to and from the Media Access Service
controlling the Media Access Services transmit and receive data
flow
holding received data in temporary storage until checked for
errors by the Media Access Service
The Unconnected Message Manager (UCMM) provides the ability
to send a message without an established connection. It is
responsible for:
receiving incoming UCMM messages
sending and receiving unconnected messages to and from UCMM
objects on other nodes
sending and receiving unconnected messages to and from its local
Message Router
16
Message Router
Connection
Manager
Connection
Tables
Transport
Services
The Message Router (MR) allows an application to open

connections to objects within the same node and is responsible for:
interpreting the part of a message that indicates the local
destination object
routing the message to the appropriate object for execution
The Connection Manager (CM) opens and closes connections as
well as maintains the networks connection tables. It is responsible
for:
setting up a connection within its node
processing all connection requests sent on the local service
forwarding an open connection service via the UCMM to the next
node in a connection path
establishing a connection to a target node
Connection Tables hold information about all connections in which
the node participates.
Transport Services define the type of data delivery an application

object requires. They are responsible for:
notifying the transmitting application of the datas arrival
detecting duplicate data delivery
Important:
Once a connection is established, objects such as the

MR, UCMM and CM are no longer required. Data can
go directly to the destination object.
The Users Application Objects are the functions for which data is
transmitted or received. They are responsible for:
making a connection request to establish a path that allows the
exchange of information between application objects
selecting the connection type that defines how many application
objects can use the data
deciding the connection priority which defines the time-critical
nature of the data to be sent
defining the trigger mode, which determines when new data
should be sent
choosing the transport service which defines the quality of
delivery required
generating the data that has been requested by other applications
ControlNet Product
Overview
17
A ControlNet product is made up of several components. In general,

a product developer is responsible for supplying the host
micro-processor and application specific software that resides above
the ControlNet enabling hardware and software. The general
components required to implement ControlNet-based communication
within a product are illustrated below:
.
ControlNet Product
Application
Specific
Software
Class-specific
Example Code
ControlNet
Example
Software
ControlNet
Enabling
Software
ControlNet
Enabling
Hardware
Network
Access
Port
Interface
Components
ControlNet
ASICs
ASIC
Firmware
Coax
Interface
Components
ControlNet Media
Products
18
ControlNet Product Components
Application specific
Software
Class-specific
Example Code
ControlNet
Example
Software
ControlNet
ASICs
Coax
Interface
Components
Network
Access
Port
Interface
Components
ASIC
Firmware
ControlNet Enabling Software provides access to enabling

hardware as well as defines a products behavior.
Application-specific Software, provided by the product
designer, resides above the ControlNet enabling components;
it provides the added value of the customers specific product or
application.
ControlNet Example Software is an example implementation
that demonstrates the required protocol for the network. It
includes:
opening/closing connections
maintaining connections
directing data transmission and reception
supporting specific, product-based requirements
supporting interfaces to several product classes:
Message Class
Adapter Class
Scanner Class
ControlNet Enabling Hardware implement lower levels of
ControlNets protocol and provide physical connections to the
network. These components include: ASICs, transceivers,
transformers, crystals, and connectors.
A ControlNet ASIC is an Application Specific Integrated
Circuits developed for the ControlNet network.
ControlNet Coax Interface Components allow a ControlNet
ASIC to access the networks physical signalling.
Network Access Port (NAP) Interface Components include an
RJ45 connector and transceiver that provide a tapless, full-speed,
temporary network connection at every node.
ASIC Firmware provides a product class-specific personality to
the ControlNet node. Much of the computationally intensive
parts of the ControlNet protocol are done here, offloading the
host CPU.
ControlNet Media Products are items that compose the networks
physical environment such as the cable and taps. (See Chapter 6,
ControlNet Physical Media.).
ControlNet Enablers
19
ControlNet enablers are the software and hardware components

necessary for a product to function on the ControlNet network.
Figure 1.4 illustrates these components.
Important:
All application-specific software resides in a

user-provided host micro-processor, not on ControlNet
ASICs.
Figure 1.4
Components that Enable Communication on the ControlNet
Network
ControlNet Product Components
ControlNet Product
Micro-processor
host
microprocessor
Application
Specific
Software
USER
APPLICATION
ControlNet
Enabling
Software
ControlNet
Example
Software
ASIC
SOFTWARE
FIRMWARE
ASICs
ControlNet
Enabling
Hardware
Network
Access
Port
Interface
Components
EXAMPLE
NAP
RJ-45
CNA10
ControlNet
ASICs
ASIC
Firmware
Transformers
Coax
Transceiver
Hybrid
BNC
Female half
Coax Interface
Components
NAP
Transceiver
Crystal or Oscillator
Taps
Repeaters
ControlNet Media
Products
Tools
BNC
Male half
Cable
110
ControlNet Media
ControlNet media consists of the trunk-cable, connectors, taps, and

repeaters through which data travels. In contrast to the logical
components such as software or protocols, the media are the physical
components that make up a ControlNet network.
A link is a collection of nodes with unique addresses (in the range of 1-99).
Segments connected by repeaters make up a link; links connected by
bridges make up a network.
Taps connect components to the ControlNet

trunk-cable. A tap is required for each node
and for both sides of each repeater.
Cable connectors attach

trunk cable sections to the
taps.
cable A =
Terminators are 75-ohm resistors

(mounted in BNC plugs) placed on the
ends of segments to prevent
reflections from occurring at the ends
of cables.
cable B =
A segment is a trunk-cable section connected via

taps with terminators at each end; a segment does
not include repeaters.
Redundant Segment
Drop cable is a cable that
connects a node to the trunk
cable (this is an integral part
of the taps)
Node
Node
A Node is the port of a physical device

connecting to the network which requires a
network address in order to function on the
network; a link may contain a maximum of 99
nodes.
segment 1
Repeaters increase the number of taps permitted

on a link or extend the total length of a link. A
repeater is a two-port active physical-layer device
that reconstructs and retransmits all traffic it hears
on one segment to another segment. A repeater
can be installed on any tap.
segment 2
Chapter

This chapter describes the method by which the ControlNet network:
provides determinism for control and I/O data
facilitates unscheduled messaging
allocates resources
allows access to the networks media
This chapter contains these sections:
The Media Access Method

Concurrent Time Domain
Multiple Access (CTDMA)
is the algorithm with which
the ControlNet network
transmits data.
The Network Update Time

(NUT) is the repetitive time
interval in which data can
be sent on the ControlNet
network.
Section
Page
The Media Access Method
21
Scheduled Service
22
Unscheduled Service
23
Guardband
24
Access to the network is determined by time. Each node may

transmit only during its assigned turn, which falls within a specified
time frame. An algorithm called Concurrent Time Domain
Multiple Access (CTDMA) regulates the opportunity to transmit.
This opportunity repeats itself at precise intervals. The Network
Update Time (NUT) is the fixed and known rate at which this
network update interval (NUI) is repeated. Figure 2.1 illustrates the
repeating NUI in which nodes can transmit their scheduled and
unscheduled messages. As depicted below, the NUI is divided into
three sections:
Scheduled
Unscheduled
Guardband (network maintenance)
Figure 2.1
The ControlNet Networks Media Access Method
Network Update Interval
This time is reserved for

scheduled message traffic
This time is reserved for

unscheduled message traffic
This time, called the

Guardband, is reserved for
network maintenance
Time
22
Scheduled Service
The first portion of the NUI is reserved for scheduled message

traffic. Message delivery in this portion of the NUI is deterministic
and repeatable. Every node with a network address falling between
one and SMAX is guaranteed exactly one opportunity to transmit per
NUT.
Scheduled traffic is time-critical data that

is sent at a fixed and repetitive rate.
Each node can transmit up to 510 bytes during its turn. The
bandwidth in this portion is reserved and configured in advance to
support real-time data transfers. Typical types of scheduled
messages include:
digital data
analog data
peer-to-peer inter-locking data
SMAX is the highest network address that

can reserve bandwidth in the scheduled
portion of the NUI.
Important:
The scheduled service is from 0 to SMAX. Nodes with

network addresses above SMAX will not send messages
during the scheduled portion of the interval.
Figure 2.2
ControlNet Scheduled Media Access Service
NUI
G this boundary moves according to

how much bandwidth is used for
scheduled message traffic
Time
Slot time is the

duration a node will
wait for a missing
network address
before taking its
turn to transmit.
The actual time is
based on cable
length and the number of repeaters.
G each node can G SMAX is the highest

G an implied token
reserve the
method regulates
network address that
bandwidth for its can reserve bandwidth
network addresses
real time data
during this portion of
in the scheduled
transfer
portion of the network
the network interval
interval
Important:
G for example: node 3

G nodes wait one slot
waits one slot time
time for each missing
node (network address) because node 2
was turned off
from 0 to SMAX
An implied token is the manner in which a network

address determines when to transmit in relation to the
other nodes on the network. No actual token is passed;
the pass is implied because it is based on time. Each
network node either waits to hear the end of the
previous address transmission or a slot time for each
missing node before sending its message. Each node
remains silent until its opportunity to transmit.
Unscheduled Service
UMAX is the highest network address that can
communicate during the unscheduled portion
of the NUI. The default is SMAX + 8.
23
The unscheduled portion of the NUI begins after all scheduled

nodes have had an opportunity to transmit. The time remaining
before the beginning of the guardband is available on a sequentially
rotating basis to all nodes, with a network address between 0 and
UMAX. This rotation continues until the beginning of the
guardband. The right to transmit first in the unscheduled portion
rotates one node per NUI.
Important:
Unscheduled traffic is data which has no

time-critical constraints.
A node may have the opportunity to transmit many

times during the unscheduled portion of the NUI;
however, a node is not guaranteed an opportunity every
NUI.
In Figure 2.3, node 7 begins the unscheduled portion in the

examples first NUI. Node 8 transmits first in the second NUI
regardless of who finished the last interval. Typical types of
unscheduled data include:
connection establishment
peer-to-peer messaging data
programming data (uploads and downloads)
Important:
the unscheduled service is from 0 to the value of UMAX. In

addition, UMAX is always greater than or equal to SMAX
nodes with addresses greater than SMAX and less than or equal
to UMAX may only send unscheduled messages
nodes with a network address less than or equal to SMAX may
send both scheduled and unscheduled messages
nodes with network addresses above UMAX may not
communicate on the ControlNet network
Figure 2.3
ControlNet Unscheduled Media Access Service
The opportunity to transmit first in the unscheduled
portion of the NUI passes on a rotating basis.
NUI
10
11
UMAX
10
11
12
Time
G An implied token method
regulates network addresses
during this portion of the
network interval
G unscheduled delivery is
not deterministic or
repeatable
G nodes wait one slot

time for each missing
node (network address)
from 0 to UMAX
G each node may

transmit many times
or not at all
24
Guardband
The moderator is the node with the lowest

network address. During the guardband, this
node transmits the moderator frame.
The Guardband is the final part of the NUI and is reserved for
network maintenance. During this time, the moderator transmits
information, called the moderator frame, which keeps all nodes
synchronized (Figure 2.4).
Important:
As the application dictates, the user can perform a

network change algorithm to edit configuration
information within a moderator frame. This change
may or may not force a change in the NUT.
Figure 2.4
The Moderator Frame Transmitted During a NUI
Guardband
NUI
Guardband
Guardband
Guardband
Time
Moderator Frame
G NUT
G SMAX and UMAX
G Slot Time, based on
physical network size
and configuration
Important:
Each nodes ASIC has the ability to act as a moderator.

If the current moderator node ceases to operate, the
node with the next lowest address assumes the
moderator duties.
Chapter

This chapter discusses how the ControlNet network is configured
and maintained. This chapter contains these sections:
Network And Station

Management Introduction
Section
Page
Network And Station Management Introduction
31
ControlNet Configuration Manager Node
32
Kept Node
32
The ControlNet configuration method prevents any single node from

disrupting the networks normal operations. This method includes a
common set of operating rules for all nodes:
all nodes on a link must agree on a common set of network
configuration parameters before transmitting scheduled or
unscheduled data
each node is required to have node-specific information before
transmitting scheduled data
node-specific information is not required before transmitting
unscheduled data
The required configuration information consists of:
Parameter
Content
network configuration
NUT
SMAX
UMAX
slot time
node-specific port configuration
the maximum size of each nodes scheduled data

serial number
revision information
Important:
The above listing of network and node-specific

configuration parameters is abbreviated. It lists only
general parameters without detail. More parameters are
contained within the network and node-specific
configuration but are omitted for the general purpose of
this document.
32
Manager Node
The ControlNet Configuration Manager (CCM)

node is a device that holds the network and
node-specific configuration parameters in its
non-volatile memory for distribution to other
nodes.
The ControlNet Configuration Manager (CCM) node is

responsible for maintaining and distributing the network and
node-specific port parameters. (See Network Station Management
Introduction, on page 31.) This function resides in a ControlNet
product at network address 1. The CCM node must hold the network
attributes in non-volatile storage, allowing re-distribution after a
power-fail event. Every ControlNet link must have a CCM-capable
node to:
support scheduled and unscheduled traffic
save and distribute the network parameters
establishing the network at power-up
Link
Master
CCM
Node
A kept node is a device that cannot go on-line

without receiving configuration parameters
from the CCM node.
Kept
Node
Kept
Node
Kept
Node
Kept
Node
Kept
Node
Kept
Node
A network may contain only one CCM. The CCM must be installed
at network address 1. The CCM is responsible for:
making sure that ControlNet configuration information survives a
power cycle
distributing continuously:
network parameters to all nodes on the link, which must be
done before a node can send any data
node specific port parameters, which must be done before a
node can send scheduled data
Kept Node
A kept node is any node on a link that receives its configuration

attributes from a CCM. A CCM node differs from a kept node in
that the CCM node can go on-line under its own control. A kept
node is any node that cannot go on-line without a CCM. A kept
node must have a network address higher than 1. Address 1 is
reserved for the CCM node.
Kept nodes are streamlined for low cost and minimal communication
software overhead. As a result, these nodes do not store network or
port configuration parameters in non-volatile storage and can only go
on-line when initialized by a CCM. Therefore, while waiting to be
initialized after a network fault or power cycle event, a kept node
defaults to a listen-only state.
Chapter

This chapter presents the fundamentals of ControlNet connections.
It contains these sections:
Section
ControlNet Network Packet Format
Connections
The Producer/Consumer Model
ControlNet Network
Packet Format
Media Access
Control (MAC)
frames are the
form in which a
node transmits a
group of data.
This group of data
is in the form of
Lpackets. A single
MAC frame can
contain several
Lpackets.
A link packet, or
Lpacket is data
that has been
packaged and
labeled by a node
in preparation for
transmission.
Page
41
44
47
When a node sends data over the ControlNet network, it packages

that data into a MAC frame. Each MAC frame can contain multiple
Lpackets which are transmitted together. (See Figure 4.1.)
Important:
Each node can send only one MAC frame of up to a

maximum of 510 bytes during each transmission
opportunity.
Figure 4.1
MAC Frame and Lpacket Formats
MAC Frame
(16 bits)
PRE
(8 bits)
(8 bits)
SD
SRC
(16 bits)
MAC Data
(510 Bytes Max)
(8 bits)
CRC
ED
(variable)
GAP
Interframe Gap
End Delimiter
Preamble
Start Delimiter
Cyclic Redundancy
Check
Source Network
Address
Lpacket
Lpacket
....
Lpacket
variable
(nominal 3 bytes)
8 bits
Length
8 bits
Control
Connection ID
Link Data
42
MAC Frame Format

The following items are inserted into MAC frames before
transmission on the ControlNet network:
preamble
start delimiter
source network address
CRC
end delimiter
The network address is written to a register in the ASIC. Once this
is done, the system needs to provide only the contents of the MAC
data. The MAC frame allows several pieces of information, called
Lpackets, to be sent in a single transmission. Each Lpacket within
the MAC data field could be destined for different consumers.
(See Figure 4.2.)
Figure 4.2
MAC Frame Containing Multiple Lpackets
(16 bits)
PRE
(8 bits)
(8 bits)
(510 Bytes Max)
(16 bits)
SD
SRC
MAC Data
CRC
(8 bits)
ED
Start Delimiter
Source Network
Address
GAP
Interframe Gap
End Delimiter
Preamble
Lpacket
(variable)
Cyclic Redundancy
Check
Lpacket
....
Lpacket
43
Lpacket Format
A connection ID (CID) is
a numeric identifier on a
network. It names the
information to
follow.
As shown in Figure 4.2, the MAC data field can contain several
Lpackets, which are the packets of interest to a users application.
Each Lpacket contains a single piece of application information
destined for one or more nodes on the network. Packets sent or
received on the physical wire contain data of interest to the
application layers as well as a connection ID (CID), control byte,
and length byte. (See Figure 4.3.) An application uses the CID to
determine whether or not a particular Lpacket contains the data it
needs.
Figure 4.3
Lpacket Format
either 2 or 3 bytes
8 bits
Length
8 bits
Control
Connection ID
Link Data
The CID is an identifier or name automatically created by

ControlNet nodes. A CID is a shorthand method for referring to a
particular object message. In the figure above, the CID can be one
of two formats:
fixed connection ID (2 bytes)
general connection ID (3 bytes)
A Fixed Connection ID is two bytes long and contains a service
code and destination network address byte. (See Figure 4.4.)
The code byte is used to indicate the service required, while the
destination byte indicates to which network address it is to be
delivered. Lower ControlNet layers use this for a small set of
services.
Figure 4.4
Fixed CID Format
Length
Control
Connection ID
Link Data
2 bytes
Fixed connection ID
Service
Code
Destination
Network Address
44
A General Connection ID is three bytes long and contains a number

used to identify a specific data packet. (See Figure 4.5.) A general
CID must be a unique value on any specific link.
Figure 4.5
General CID Format
Length
Control
Connection ID
Link Data
3 bytes
General connection ID
Unique Values
Connections
In some ways, a ControlNet connection can be compared to a

telephone circuit. When you place a call, the telephone system
selects a path for your call and sets up each switching station in the
route to handle it. As long as the call continues, the resulting virtual
circuit remains open, carrying data or voice traffic. In the telephone
system, a single call can traverse multiple and different-type links.
Through all of this, the connection appears the same to both the
caller and the party called: sound in one end becomes sound in the
other.
A connection also provides a path between two end points. Once the
connection manager determines the virtual circuit, the route between
end points is fixed. (See Connection Manager, on page 47.)
The end points of connections are applications that need to share
data. Figure 4.6 illustrates a virtual circuit that traverses one or more
intermediate nodes between the source and destination.
Important:
The terms source and destination imply that a

connection has been established and currently exists.
Figure 4.6
Virtual Circuit
Source
ControlNet
Network
Many nodes
Destination
45
Establishing a Connection
Every node contains the following objects:
unconnected message manager (UCMM)
message router (MR)
connection manager (CM)
A connection does not yet exist. Purpose of contact is to set up a connection.
An originator is an
application that
requests a
connection.
Originator
request to open
Target
a connection
A target is an
application with which
the originator is
requesting to connect.
The following sections about establishing a connection provide:

a brief functional description on each connection object listed
above
a graphic as well as written explanation of how these components
interact while a connection is initiated and established
Unconnected Message Manager (UCMM)
The UCMM facilitates the exchange of information used to establish,
open, or close a connection between applications. In addition, it is
used to convey non-repetitive, non-time critical data on a single link.
To establish a connection, the Connection Manager provides the
UCMM with the network address and path to the target application.
Once the connection is established, the address and path are no
longer required. Opening the connection establishes a CID, which
will be used to exchange application information.
As shown in Figure 4.7, each message the UCMM receives is
forwarded to the Message Router where it is analyzed and sent to its
specified function or object. The UCMM keeps a transaction record
of each message received so that a reply can be sent to the proper
location. Open and Close connection request messages are always
sent via the UCMM. In addition, the UCMM provides:
duplicate detection
automatic retries
message time-out
46
Figure 4.7
UCMM and Message Router Interaction
Node 1
Node 2
Message
Router
Message
Router
ControlNet
Network
UCMM
Important:
UCMM
UCMM messages are always sent in the unscheduled

portion of the network interval.
Message Router
The Message Router (MR) allows an application to open connections
to multiple objects within the same node. It acts much like an
internal switchboard for a nodes objects. Other nodes may establish
a connection with the MR through the UCMM and connection
manager. Figure 4.8 is an example of how the MR functions.
Figure 4.8
Message Router Functions
Message
Router
Requesting
Object
4
Connection
2
3
Destination
Object
Node
1. The MR determines which object is to perform the specified

service by interpreting the identifying portion of the message.
2. The message is forwarded to the destination object.
3. A response from the destination object for the requesting object is
received.
4. The MR forwards the response to the requesting object via an
established connection.
Important:
Connections can be created without a MR connection; a

messaging connection to the MR is only mandatory
when the originating application requires access to
multiple internal objects through the same connection.
47
Connection Manager
The Connection Manager (CM) allocates internal resources
necessary for each connection. Connection requests are originated
by:
other nodes via the UCMM
an application on a node
Figure 4.9 is an example of how the the CM of a target node
functions upon receiving a connection request by an originating
node.
Figure 4.9
Object Components of the Connection Manager
Link
Producer/
Consumer
UCMM
Link
Resource
Allocator
Connection
4
3
Connection
Processor
Message
Router
Connection Manager
1. The originators UCMM contacts the targets UCMM with a

connection request.
2. The request is routed through the targets MR to the CM.
3. The CM allocates the needed resources.
4. A connection is made to the originator node.
The Producer/Consumer
Model
The ControlNet network uses the Producer/Consumer model to

exchange application information. This model is the basis for
understanding all ControlNet transactions. The following builds a
producer/consumer model by discussing its basic components:
object messages
connection ID
producer/consumer connection types
transport services
transport connection types
48
Object Messages
An object message
is a piece of
information that
interests one or
more nodes on the
network.
In the ControlNet networks Producer/Consumer model, object

messages are used to exchange information. An object message is a
piece of information that interests one or more nodes on the network.
It carries a value or set of values with a description of the values
meaning. The ControlNet network transfers object messages
between producers and consumers to convey information.
The network view of messages, shown below, is simplified to
facilitate minimal processing, high performance, and small
code-requirements. It contains only that part of an objects value that
changes with time.
Connection ID
A producer is a
transmitting node.
A consumer is a
receiving node.
Object Data
Nodes watch for certain CIDs transmitted by producer nodes.

Once a node recognizes a CID, it consumes the message, therefore
becoming a consumer. The network assumes that each object
message has exactly one meaning but may have one or more
consumers.
Producer/Consumer Connection Types

The concept of one producer and one consumer, illustrated in Figure
4.10, is known as a point-to-point connection.
Figure 4.10
Point-to-Point Producer/Consumer Connection
Node 1 Producer
Node 2 Consumer
The concept of more than one consumer per message, or multicast,

is shown in Figure 4.11. The dashed arrow represents an object
message. In Figure 4.11, Node 1 produces a message on the
network. Nodes 4, 7, and 8 consume the message. Nodes 2, 3, 5, and
6 see the message but are not interested in it and do not consume that
message.
49
Figure 4.11
Multicast Producer/Consumer Connection
Node 3
Node 1 Producer
Node 2
Node 5
Node 4 Consumer
Important:
Node 7 Consumer
Node 8 Consumer
Node 6
Nodes can be producers, consumers, or both. For

example, in Figure 4.12, Node 4 may want to send an
object message to Node 3 based on the information it
just consumed from Node 1.
Figure 4.12
A Single Node as Both a Producer and Consumer
Node 1
Producer
Node 3 Consumer
Node 2
Node as both
producer and consumer
Node 4 Consumer
Producer
Transport Services
Table 4.A lists the two general-purpose transport classes that have
been defined for the ControlNet network. Each transport class
provides a different level of service. It is these services that allow
communication between applications. Transport classes with higher
numbers incorporate and build upon the functions of lower transport
classes. The originating application must determine which transport
class best suits its needs for a particular data transfer.
Table 4.A
Transport Classes
Class Number
Class Name
Duplicate detection
Verified
Transport Class 1
Transport class 1 is illustrated in Figure 4.13. Class 1 provides the
minimum level of service only, duplicate data detection.
410
Figure 4.13
Transport Class 1
1 indicates initial message delivery
Class 1 Transport
Node 1
Producer
D
D
D
D
uses one connection

provides a header sequence count to detect duplicate
data packet delivery
does not burden target application with duplicate detection
used for cyclic data transfer
Node 2 Consumer
Transport Class 3
Figure 4.14 illustrates transport classes 3. Class 3 provides data
verification.
Figure 4.14
Transport Class 3
2 indicates the reverse data path for delivery notification
Node 1
Producer
Consumer
2
verification message:
packet has arrived
and has been read.
Consumer
Producer
Class 3 Transport
D
D
D
uses one connection to deliver application data

employs second connection for verification that the transmitted
data has been received and read by the consumer
used for change of state and application triggered data transfer
Node 2
Transport Connection Types

The ControlNet network supports two types of connections:
point-to-point connections use one producer and only one
consumer. No additional connections can be added.
multicast connections allow one producer of data with more than
one consumer.
Both types of connections can be defined further by the application,
depending on the particular services that application requires.
411
Point-to-Point Class 1
Figure 4.15 illustrates a point-to-point connection between
applications. In this example, data is simply sent from one
application to another. No services other than data delivery and
duplicate detection are provided by class 1. This type of connection
is commonly used for cyclic I/O data transfers (class 1).
Figure 4.15
Point-to-Point Connection Using Transport Class 1
Connections within the dashed line boxes are logical. Connections outside the dashed line
boxes are physical.
Node 1
Application
Transport
Producer
1
Node 2
Consumer
Transport
Duplicate delivery
detection (class 1)
occurs here
Application
duplicate
notification
412
Point-to-Point Class 3
Figure 4.16 illustrates a point-to-point connection with delivery
verification. In this type of connection, the application can specify a
class 3 transport. The delivery notification is used for message
verification (class 3). A typical use for this type of connection is
client/server message traffic.
A client is an
application that
requests data
from another
application on
an existing
connection.
Figure 4.16
Point-to-Point Connection Using Transport Class 3
A server is an
application that
responds to a
clients request
by sending the
requested data
on an existing
connection.
boxes are physical.
Node 1 Client
Application
Transport
indicates the reverse data path for delivery verification
Producer
Consumer
1
2
Consumer
Producer
Important:
Node 2 Server
Transport
Application
Delivery verification is not a point-to-point connection

requirement, only an available augmentation.
413
Multicast Class 1
Figure 4.17 illustrates a multicast connection that can be defined
further as class 1 by the application. This example is similar to
Figure 4.15. The application may specifies that duplication detection
is required. A common use for this type of multicast connection
could be an adapter sending inputs to multiple scanners.
Figure 4.17
Multicast Connection Using Transport Class 1
boxes are physical.
Node 2
Node 1
Application
Transport
Producer
Consumer
Transport
Application
1
Node 3
Application
Transport
Consumer
414
Notes:
Chapter

The CNA10 ASIC
Section
Page
The CNA10 ASIC
51
Protocol Functions
54
Communication Processor
55
Dual-port RAM
55
CNA10 Software Components
56
Communication Example Code
59
ControlNet media-access control-hardware (ASICs) are interface

chips that allow a product to access a ControlNet network.
The ControlNet ASIC is called CNA10. The CNA10, in conjunction
with class-specific firmware, provides connection layer services,
as shown in Figure 5.1.
Figure 5.1
ControlNet CNA10 and the Connection Layer Coverage
It Provides
ControlNet
Communication
Software
ControlNet
Access Control
Hardware
ControlNet
Transceiver
Application Layer
CNA10
Transport
Layer
Network
Layer
Link (physical)
Layer
The CNA10 ASIC is an interface chip for Intelt and Motorolar

host processors. It provides the following features:
a 16-bit communication processor
a 3K byte dual-port RAM interface
hardware support for 31 multicast connections
a data quarantine service
transport services
52
ControlNet Enablers
The protocol machine within the CNA10 provides:

contains media access controller
receives data from the host processor and network
transmits data via its modem and a transceiver onto the network
filters data received from the network
holds data to be transmitted or received in buffers within the
ASIC
supports optional redundant media
The CNA10, Allen-Bradleys ControlNet ASIC, supports all
required media access functions. In addition, through a dedicated
on-chip communication processor, the CNA10 ASIC supports much
of the required transport protocol, shown in Figure 5.2.
This facilitates a simple dual-port RAM interface to a user-supplied
host-processor, shown in Figure 5.3
ControlNet Enablers
53
Figure 5.2
The ControlNet Communication Model and the CNA10
Services

Application Layer
control and
I/O data
connect request and

message data
data
trigger
Message
Router
Unconnected
Message
Manager
(UCMM)
Connection Manager
User Provided
Software
CNA10 ASIC
Firmware
ControlNet
Communication
Example Code
ControlNet
Transceiver
Components
ControlNet Media
Components
Transport
Services
Transport Layer
Connection
Tables
Link Layer Driver
Network Layer
Link Layer
Media Access Services
Media Access
Media
and
Physical
Layer
As shown in Figure 5.2, the communication example code runs in a

host-processor and is responsible for supporting all layers below it.
It is application-specific example code and is offered by
Allen-Bradley to assist designers in creating their own product
software. Because every product has slightly different application
requirements and may require a different host-processor, it is not
practical to supply a single software package to fit all needs.
Therefore, Allen-Bradley has developed several examples of how a
specific application could be applied using the CNA10. These
examples can be used as a foundation for a CNA10-based product.
54
ControlNet Enablers
Figure 5.3
Block Diagram View of the CNA10
Communication
ROM
CNA10
60 MHZ
Oscillator
Transceiver
Cable
Protocol
functions
MAC processor
modem
receive/transmit FIFOs
Lpacket screener
Configuration Bits
User
Application
Communication
Processor
Dual Port RAM
Host
Status & Counters
NAP
Protocol Functions
Transceiver
MAC
functions
Cable
NAP
CRC is an acronym
for Cyclic
Redundancy Check.
CID is an acronym
for Connection
IDentifier.
The CNA10 ASIC protocol engine supports the following features:

MAC processor
modem services
transmit and receive FIFOs
Lpacket screeners
cable redundancy
NAP
signal integrity checking (CRC)
The CNA10 modem sends and receives data in the form of MAC
frames. Its protocol controller constantly tracks which node is next
to transmit and manages the receive and transmit process. When a
packet is waiting to be sent, it is held in transmit FIFOs until its turn.
Before a received Lpacket can be processed, it is screened by the
Lpacket screener. The Lpackets CID is read and compared to an
internal, host-programmed list of CIDs. If a match is found, the
screener attaches an index value to the Lpacket and sends it to the
communication processor. Each of the CNA10s 31 available
connections has a screener which can be programmed to search for
any CID.
ControlNet Enablers
Communication Processor
55
The communication processor is a 16-bit micro-processor

responsible for the implementation of communication transport
functions. It quarantines packets from the receive FIFO until their
CRC can be verified. The communication processor also sends and
receives data from the dual-port RAM. To the host, the CNA10
simply appears to be RAM.
Communication
ROM
Communication
Processor
Dual Port RAM
Host
The CNA10 provides one unconnected channel that supports an

Unconnected Message Manager (UCMM) transport as well as 31
connected channels. In general, the UCMM channel is used for
unconnected messaging such as open/close requests, while the
connected transport channels are used for real-time I/O data transfers
and client/server messaging.
"
Dual-port RAM
Dual Port RAM

Interrupt Control
Configuration
Communication
Services
3K
bytes
UCMM receive (Rx)
For more information, refer to the pages listed in the table below.
For information about:
See page:
MAC Frames and Lpackets
41
CTDMA and NUT
21
Connection IDs
43
The dual-port RAM is the point at which the host processor

physically and logically connects to the CNA10. It is 3K-bytes in
size and provides buffers for:
configuration
interrupt control
communication services
UCMM receive and transmit
each of the 31 connections (one or two buffers per connection,
depending on the transport class chosen)
Communication
Processor
UCMM transmit (Tx)

Dual Port RAM
Host
Connection
Channels
56
ControlNet Enablers
Important:
The sum of all areas must not exceed 3K-bytes.

In addition, the boundary between the UCMM and
connection buffers is fixed at the time of configuration.
These features facilitate transport support inside the CNA10.

Table 5.A
Connected and Unconnected Buffer Sizes
CNA10 Software
Components
Buffer
Minimum
Maximum
Default
31 connected channels
3 words per channel
252 words
Not applicable
UCMM Rx
32 words
255 words
255 words
UCMM Tx
32 words
255 words
32 words
CNA10 software components are located both in the ASIC firmware

and in the host processor. These components operate together to
provide services to applications. The following description builds a
general profile of its capabilities by explaining each of its major
software components and processes.
Unconnected Message Manager (UCMM)
Resides in the
host processor
Online means to be
actively participating
on the
communication
network.
Unconnected Message Manager delivers and buffers messages

between nodes that do not have an available and established
connection between them. The messages may be a request to open a
connection or simply non-repetitive, non-time critical data. All
ControlNet nodes are required to have UCMM message transmit and
receive capability. For this purpose, the CNA10 provides transmit
and receive services on an independent channel across a single link.
UCMM messages may be serviced anytime the ASIC is online.
They do not require prior setup or negotiation by the client and
server. The UCMM service is primarily used for:
establishing real-time data transfers
non-connection event information between nodes
Because it is not necessary to establish a connection for UCMM
messages, they may be sent at any time. If a response timeout
occurs, the application is responsible for any retries.
Important:
These messages have no guarantee of delivery. Also, a

communication failure will result in a response timeout.
ControlNet Enablers
57
Message Router (MR)
Resides in the
host processor
The Message Router routes all incoming messages to the appropriate

objects. Valid destinations are any internal object class as well as
any application object-class that has been registered with the MR.
All received UCMM messages are forwarded to the MR for delivery
within the node.
Transports
Resides in the
CNA10
All message transfers use a specific transport class. Unconnected

messages have one class called UCMM transport while the
connected messages have two, transport classes 1 and 3. The table
below indicates which transport classes are supported by the CNA10.
The bulleted items are CNA10 supported transport functions.
allocation/de-allocation
start/stop
write
trigger
Class Number
Class Name
CNA10 Supported ?
1
3
Duplicated detection
Verified
Yes
Yes
Connection Manager (CM)
Resides in the
host processor
The Connection Manager is responsible for establishing and

removing connections supported by the CNA10 ASIC. Also, as the
CM determines the allocation of resources, it must determine if a
particular connection request can be honored by its node.
The availability of connection channels and bandwidth allocation
directly impacts the acceptance or rejection of a connection request.
58
ControlNet Enablers
Time Critical Bandwidth Allocation in the Connection Manager

Upon start up, part of the configuration data received specifies how
much time-critical bandwidth on the network has been allocated to
the node; it is allocated strictly on a first-come, first-serve basis.
Depending on the sophistication of the application, the CM can be
designed for one of three levels of connection request versus
bandwidth reviewing:
low-end: Connections supported by the node are fixed. The CM
can only accept a request that exactly matches one of the
available connections.
mid-range: The CM compares connection requests to a variable
length list of acceptable connections. The product application has
the option to modify the list when desired.
high-end: The CM will attempt to optimize the allocation of
ControlNet bandwidth. It minimizes stale data by generating a
connected-data transmit-schedule with uniform loading over time
at the requested throughput.
Important:
Connections can only be established to either the

product application objects or to the MR object.
ControlNet Configuration Manager
Resides in the
CCM node
A ControlNet Configuration Manager (CCM) is responsible for

holding network and port attributes for all other nodes on a particular
link. Upon power up, each link of a network depends on a
configured CCM to start and initialize their nodes. In addition, it
allows a network to be reconfigured without requiring the presence
of programming software for all affected nodes. A CNA10 could be
developed to function as a CCM node; however, it is expected that
most developers will use an Allen-Bradley supplied product, such as
the PLC-5 processor. In ControlNet Phase 1.0 and Phase 1.5
systems, the CCM must be at node address 1.
ControlNet Enablers
Communication Example
Code
59
The communication example code, shown in Figure 5.2, supports a

set of application objects and interfaces. This set of objects and
interfaces may differ, depending on the type of product being
developed. Communication software examples have been developed
with the appropriate objects and interfaces to support two real-time
I/O classes and one non-time-critical messaging class. Examples of
how products would exchange data with the other classes is shown in
Figure 5.4
Figure 5.4
ControlNet Product Classes
Scanner Class Product
Scanner
Msg
adapter
Msg
Msg
adapter
Messaging Class Product
Adapter Class Product
Messaging Class
Messaging Class products support only unscheduled messages to all
product classes; all other product classes also support unscheduled
message traffic. A Messaging Class product is an initiator or
responder to connections and exchanges unconnected client/server
messages. It is only used in non-time critical applications because
response time in the ControlNet unscheduled service is not
deterministic. Typical Messaging Class products include:
monitoring devices
software-based supervisory products
operator interface devices
programming tools
PCMCIA interface cards
other computer interface cards
calibration tools
510
ControlNet Enablers
Adapter Class
each product class listed

increases in complexity
An Adapter Class product emulates functions provided by traditional

rack-adapter products. This type of node exchanges scheduled
real-time I/O data with a Scanner Class product (example, a PLC
scanner); it does not initiate connections on its own. However, it can
support unconnected messages as a server. This facilitates the
Adapter Class products ability to exchange real-time I/O data with a
PLC processor as well as unscheduled messages to exchange device
calibration, status, and configuration information with a Message
Class, Scanner Class, or other Adapter Class node. Typical Adapter
Class products may include:
rack adapters
drives
weigh scale
operator interface devices
welders
robots
Scanner Class
A Scanner Class product exchanges scheduled real-time I/O data
with Adapter Class and Scanner Class products. This type of node
can respond to connection requests and can also initiate connections
on its own. In addition, the Scanner Class supports unconnected
messages as a client or server. This facilitates emulation of a PLC
processor in all respects. It can exchange data with other products in
its class as well as directly to racks of I/O cards. Typical Scanner
Class products may include:
PLC processors
I/O scanners
drives
motion controllers
robots
CNCs
Chapter

This chapter provides a summary of ControlNet physical media.
Also, it provides related specifications and parameters on a general
level. For more detailed information about ControlNets physical
media, refer to Chapters 7-11. This chapter contains these sections:
Overview of Physical
Media
Section
Page
Overview of Physical Media
61
Network Specifications And Parameters
62
Tap Types
63
Physical Layer Repeaters
63
Redundant Media
64
Alternate Network Connection
64
The primary physical media for the ControlNet network is coaxial

cable. A ControlNet physical network is comprised of this cable and
a combination of connecting, transceiving, and terminating devices.
Secondary is a fiber optic repeater device and cabling which is
available to support long distances, such as building-to-building
installation, as well as intrinsically safe environments.
The following sections are a general description of the primary
physical system, its limitations, and components.
Figure 6.1 illustrates the basic components of ControlNets physical
media.
Figure 6.1
General Components of a ControlNet Cable System
In this example, two segments are linked by a

repeater to form a seven node link.
link
segment
T
= node
= repeater
= tap
segment
T
drop cable
1m (39.6)
N
R
N
T
terminator
connector
N
62
Network Specifications
And Parameters
Figure 6.2 graphs the networks physical parameters. It also

illustrates the relationship between the length of a cable segment and
the number of taps allowable within that distance, indicating when
repeaters are necessary.
A tap connects a
node to the networks
trunk cable.
A segment is trunk-cable
sections connected via taps
with terminators at each
end; a segment does not
include repeaters.
Figure 6.2
ControlNet Cable System Requirements
segment length
m (ft)
1000 (3280) .
Repeater required
maximum allowable segment length =

1000m 16.3m x [number of taps 2]
or
3280ft 53.4ft x [number of taps 2]
750 (2460)
500 (1640)
Repeater not required
250 (820)
Important:
16
32
48
Networks that stay within the limits detailed in

Table 6.A may connect additional nodes at all available
NAPs. (See Alternate Network Connection, on
page 64.)
Table 6.A
ControlNet Network Parameters
Parameter
Limit
Maximum number of nodes per link
99 nodes
Maximum number of repeaters in a series (link)
depends on amount of cable used
Data rate
5.0 MBit/Sec (1.6 m sec/Byte)
Undetected error rate
< 1 error in 20 years
Tap Types
63
The ControlNet network uses a passive electronic tap with four

different configurations. The taps names are derived from the
unique combination of their connecting end configurations.
The following end configurations and their resulting combinations
are shown in Figure 6.3.
Figure 6.3
Tap Configurations
Physical Layer Repeaters
straight T-tap
1786-TPS
straight Y-tap
1786-TPYS
right angle T-tap

1786-TPR
right angle Y-tap

1786-TPYR
Physical layer repeaters extend the length and/or node count of the
network when a system requires more than 48 taps per link or a
longer cable than specifications allow (reference Figure 6.2). Also,
repeaters do not occupy any of the 99 network addresses allowed per
link; they do not require an address. (See Figure 6.2, ControlNet
Cable System Limitations and Requirements.)
segment 1
repeater
If each segment is less than 250m,
each segment could contain up to 47 nodes
(48 connections are allowed on a 250m 2
segment link 1 tap is for the repeater).
segment 2
64
Redundant Media
The ControlNet network provides the option of installing a second

cable between nodes. With redundant media, nodes send identical
signals on two separate segments. The receiving node continuously
compares the signals quality and selects the better cable to receive
the next message. This also provides a backup cable in case one is
improperly installed, not connected, or fails.
A node is the port

of a physical device
connecting to the
network which
requires a network
address in order to
function on the
network.
Important:
A link is a collection
of nodes with unique
addresses (1-99).
Segments connected
by repeaters make
up a link; links
connected by
bridges make up a
network.
Redundant media is not Hot-Backup.
Actual ControlNet products are labeled with these icons

(The shaded icon representing the redundant media.)
Cables on a redundant cable link are defined by the segment number

and the redundant cable letter.
Figure 6.4
Redundant Media
cable A =
cable B =
node
node
Alternate Network
Connection
All ControlNet nodes, except repeaters, are equipped with a Network

Access Port (NAP). This feature provides a tapless, full-speed,
temporary network connection at every node. Each connection uses
a 10-foot modular cable with connectors to access the systems
coaxial media.
ControlNet
A
node
B
LEDs
Important:
NAP
This cable is available as catalog number 1786-CP.
Network
Access
Port
Coax
Media
Connections
Module Face Plate
Chapter

Read this chapter to familiarize yourself with the ControlNet
cable system. It contains these sections:
Section
Page
Understanding The ControlNet Cable System
72
Understanding ControlNet Components
73
72
Overview Of the ControlNet Cable System
Understanding The
ControlNet Cable System
The ControlNet cable system gives you the flexibility to design a

communication network for your particular application. To take full
advantage of this flexibility, you should spend sufficient time
planning how to install your network before assembling any of the
hardware.
Use the following figure and term definitions to understand the
ControlNet cable system.
link
segment
segment
trunk-cable
section
N
bridge
network
link (one segment)
Term1
network
Definition
a collection of connected nodes
the connection paths between any pair of devices
may include repeaters and bridges
Term
repeater
R
Definition
a two-port active physical layer component that
reconstructs and retransmits all traffic it hears on one
segment side to another segment side
link
a collection of nodes with unique addresses

in the range of 1-99
tap
T
the connection between any device and the ControlNet

cable system
segment
trunk-cable sections connected via taps with

terminators at each end and with no repeaters
the bus or central part of a cable system
bridge
a device that allows traffic to pass from one link to

another link
any physical device connecting to the ControlNet cable
system which requires a network address in order to
function on the network a link may contain a maximum
of 99 nodes
trunk cable
node
N
this address must be in the range of 1 99 and be

unique to that link
trunk-cable
section
a length of a cable between any two taps
terminator
a 75 resistor mounted in a BNC plug
Understanding ControlNet
Components
73
The ControlNet cable system is comprised of these components:
nodes
taps
trunk cable
cable connectors
terminators
segments
repeaters
links
bridges
network
Nodes
Nodes are defined as physical devices connecting to the ControlNet
cable system that require a network address in order to function on
the network. You can connect PLC-5/20C and -5/40C
processors, personal computers (via 1784-KTC, -KTCX, or
1770-KFC), and 1771 and 1794 adapter modules.
T
For information on purchasing these components see the Allen-Bradley ControlNet Cable System
Component List (publication AG-2.2).
74
Taps
Taps connect each node on a network to the cable system via an
integral 1m (39.37) drop cable.
T
drop cable
1m (39.6)
There are four taps available with a:

T or Y placement of BNC connectors
T-tap
Y-tap
straight or right angle connector on the drop cable

straight
right angle
See page 82 for detailed information on taps.
Trunk Cable
The trunk cable is the bus, or central part of the ControlNet
cable system. The trunk cable is composed of multiple sections
of cable. The standard cable used to construct trunk-cable sections is
quad shield RG-6 type coax.
There are also several types of special-use cables you can use
depending on the environment in which you are installing your
cable system. See page 84 for information on these cables.
75
Cable Connectors
A cable connector (cat. no. 1786-BNC) attaches trunk-cable sections
to the taps BNC connector.
T
trunk-cable
section
Optional Connectors
Allen-Bradley also offers optional cable connectors for use in your
network configuration. See page 811 for available connectors.
Terminators
A 75-ohm terminator (cat. no. 1786-XT) must be installed on the tap
at each end of a segment.
T
trunk-cable
section
Segments
A segment is a collection of trunk-cable sections, taps and two
terminators.
segment
T
trunk-cable
section
The total allowable length of a segment depends upon the number

of taps in your segment. See page 74 for detailed information.
76
Repeaters
Use a repeater to increase the number of taps, extend the total length
of your segment, or create a star configuration (go off in multiple
directions from one point). The number of repeaters is limited
depending on your network topology.
segment
segment
When you insert a repeater into your cable system, you create a new
segment. The same restrictions on the number of taps and cable
length apply to this new segment.
Links
A link is a collection of nodes forming:
a segment
multiple segments connected together via repeaters
Each node in a link must have a unique address in the range of 1-99.
In this example, two segments are linked by a
repeater to form a seven node link.
link
segment
segment
77
Bridge
A bridge is a device used to connect links.
link
T
R
N
bridge
link (one segment)
Network
A network is the collection of nodes connected together by repeaters
and bridges.
link
segment
segment
trunk-cable
N
section
bridge
network
segment
segment
link
78
Notes:

Use this chapter to determine your network requirements. It contains
these sections:
Section
Page
Determining How Many Taps You Need
82
Connecting Programming Devices
83
Determining What Type Of Cable You Need
84
Determining Trunk-Cable Section Lengths
84
Determining How Many Terminators You Need
85
Determining If You Need Repeaters
86
Determining What Type Of Connectors You Need
811
Using Redundant Media
812
Application Considerations
815
Ordering Components
817
After reading this chapter, consult engineering drawings of your

facility for specific information concerning the best location for
installing your network.
Important:
The ControlNet cable system is a ground-isolated

coaxial network. Proper selection of cable, connectors,
accessories, and installation techniques is necessary to
make sure it is not accidentally grounded.
82
Planning A ControlNet Cable System
Determining How Many

Taps You Need
The number of taps you need depends on the number of devices you
want to connect to the network. You need a tap for each node and
repeater on a segment.
If you plan to add nodes at a later date, you should consider ordering
and installing the cable and connectors for these additional nodes
when you install the initial network. This will minimize disruption
to the network during operation.
Important:
"
A disconnected drop cable can cause noise on the

network. Because of this, we recommend having only
one unconnected drop cable per segment for
maintenance purposes. Be sure to keep the dust cap on
any unconnected drop cable.
If you are planning future installation of additional nodes,

do not install the tap. Instead, install a BNC bullet connector.
(See page 811 for more information.)
Each tap kit contains:
tap (1786-TPS,
-TPR, -TPYS or
TPYR)
BNC connector kits

ControlNet cable labels
dust cap
For noise suppression, ferrite beads

are molded on the drop cable.
screws
universal mounting
bracket
These tap kits are available:

Straight T-tap
Straight Y-tap
Right-angle T-tap
Right-angle Y-tap
1786-TPS
1786-TPYS
1786-TPR
1786-TPYR
Important:
Taps contain passive electronics and must be purchased

from Allen-Bradley for the network to function
properly.
Connecting Programming
Devices
Programming devices may be connected to the ControlNet cable

system through:
the maintenance tap on a segment (for a temporary connection)
a tap on a segment (for a permanent connection)
the ControlNet network access cable (1786-CP)
this connects your programming devices to ControlNet nodes
(processors, communication interfaces, and adapters) through
network access ports (NAPs
) and allows you to gain full
access to the network
Important:
Using a 1784-KTCX communication card on coax media

programming
terminal
The 1786-CP cable can be plugged into any

ControlNet products NAP to provide
programming capability on the ControlNet
network. A programming terminal connected
through this cable is counted as a node and must
have a unique address.
Using a 1784-KTC or -KTCX communication card and NAP
programming
terminal
1784-KTCX
1784-KTC 1786-CP
or -KTCx
node
node
Using a 1770-KFC communication interface on coax media
programming
terminal
83
serial or parallel
connection
Using a 1770-KFC communication interface and NAP

programming
terminal
serial or parallel
connection
1786-CP
1770-KFC
1770-KFC
node
node
ATTENTION: Use the 1786-CP cable when

connecting a programming terminal to the network
through NAPs. Using a commercially available
RJ-style cable could result in possible network failures.
84
Determining What Type Of

Cable You Need
There are several types of RG-6 quad shield cable that may be
appropriate for your installation, depending on the environmental
factors associated with your application and installation site.
You should install all wiring for your ControlNet cable system in
accordance with the regulations contained in the National Electric
Code (or applicable country codes), state codes, and applicable
municipal codes.
For:
Use this cable type:
light industrial applications
Standard-PVC CM-CL2
heavy industrial applications
Lay-on Armoured and Interlocking

Armour
high and low temperature applications, as well as

corrosive areas (harsh chemicals)
Plenum-FEP CMP-CL2P
festooning applications
High Flex
moisture resistant applications; direct burial, with

flooding compound, fungus resistant
Flood Burial
Determining Trunk-Cable
Section Lengths
terminator
See Chapter 12, ControlNet Cable System Component List, for information on
suppliers and part numbers.
A segment is comprised of several sections of trunk cable separated

by taps. The total cable length of a segment is equal to the sum of all
of the trunk-cable sections.
tap
tap
trunk-cable section
tap
terminator
trunk-cable section
20162
Important:
When determining the cable length of trunk-cable

sections, make sure you measure the actual cable path
as it is routed in your network. Consider vertical
dimensions as well as horizontal dimensions. You
should always calculate the three-dimensional routing
path distance when determining cable lengths.
Select the shortest path for routing the cable to minimize the amount
of cable you need. The specific details of planning such a cable
route depends upon the needs of your network.
85
The total allowable length of a segment depends upon the number

of taps in your segment. There is no minimum trunk-cable section
length requirement. The maximum allowable total length of a
segment is 1,000m (3,280ft.) with two taps connected. Each
additional tap decreases the maximum length of the segment by
16.3m (53ft.). The maximum number of taps allowed on a segment
is 48 with a maximum length of 250m (820ft.).
maximum allowable segment length =

1000m (3280ft.) 16.3m (53.4ft.) x [number of taps 2]
segment length
m (ft)
1000 (3280)
750 (2460)
500 (1640)
.
250 (820)
16
32
48
number of taps
Example
If your segment requires 10 taps, the maximum segment length
is:
1000m (3280ft.) 16.3m (53.4ft.) x [10 2]
1000m (3280ft.) 130.4m (427.7ft.))
= 869.6m (2852.3ft.)
The total trunk-cable length or number of taps can be increased by

installing repeaters on the segment. This creates another segment.
Determining How Many

Terminators You Need
You must use 75 terminators (cat. no. 1786-XT) at the end of each
segment for the ControlNet cable system to work.
1786-XT
After you have determined how many segments will be in your

network, multiply this number by two to figure out how many
terminators you will need for your network.
86
You need to install repeaters if your system requires more than

48 taps per segment, or a longer trunk cable than the
specifications allow.
segment length
m (ft)
Determining If You Need

Repeaters
1000 (3280) .
Repeater
required
750 (2460)
500 (1640)
Repeater
not required
250 (820)
2
Important:
16
32
48
number of taps
The maximum number of addressable nodes per link

(not counting repeaters) is 99. Since repeaters do not
require an address, they do not count against the total
of 99.
segment 1
repeater
If each segment is less than 250m,
each segment could contain up to 47 nodes
(48 connections are allowed on a 250m
segment 1 tap for the repeater).
segment 2
The ControlNet repeaters provide:

an internal power supply
For this input power:
Use this repeater:
85 to 250V ac or 110 to 250V dc
1786-RPT
20 to 72V dc
1786-RPTD
a replaceable fuse for over-current protection

two indicators for status and troubleshooting
a fault-rely contact for status indication or switching to a
backup repeater. When wired to external circuitry, this contact
could be used to turn off a light or activate a backup repeater.
When the repeater is:
This contact:
working properly
will be held closed
not working properly (or a loss of power occurs)
will open
87
This diagram shows a possible configuration for powering a backup

repeater in your ControlNet network. In this diagram, the backup repeater
will be activated when the primary repeater is faulted.
power (ac or dc)
primary
repeater
contact
CR1
neutral
to backup
repeater
power (ac or dc)

CR1-1
ATTENTION: Do not power both repeaters at the
same time. Powering both repeaters at the same time

disrupts communication on the network. Use the fault-relay
contact of the primary repeater to control power to the
backup repeater.
Configuring Your Link with Repeaters

When you configure your link using repeaters, you can install them
in one of three ways:
You can install repeaters in:
Using a maximum of:
See page:
series
5 repeaters
88
parallel
48 repeaters
89
a combination of series and

parallel
5 repeaters in series;
48 repeaters in parallel
810
Important:
A repeater can be connected to a segment at any tap

location.
88
Installing Repeaters in Series

When you install repeaters in series, you can install a maximum of
five repeaters (or six segments) to form a link.
In this link:
segments 1 and 4 each have 2 taps and each = 1000m (3280ft.).

segments 2 and 3 each have 3 taps and each = 983.7m (3227ft.).
the total length of this link = 3967.4m (13013.2ft.).
there are 3 repeaters in series (A, B, C).
segment 1
segment 2
repeater A
repeater B
segment 3
segment 4
repeater C
20090a
89
Installing Repeaters in Parallel

When you install repeaters in parallel, you can install a maximum
of 48 repeaters (the maximum number of taps per 250m segment) to
form a link.
If your link is configured using repeaters in parallel, you count one
of the repeater taps for one segment and the other repeater tap for the
parallel segment that the repeater is connecting to the backbone
network.
In example below, Segment 1 counts only one repeater tap (as well
as the taps for the nodes). The other repeater tap is counted toward
the limitations of Segment 4.
In this link:
segment 4 is 983.7m (3226.6ft.).

segments 1, 2 and 3 (if they have an equal number of nodes) can each have up to 33 nodes on them (a link can have 99 connections,
not including repeaters).
segments 1, 2, and 3, with 33 nodes on them, can not exceed 478.4m (1570ft.)
segment 4
segment 1
segment 3
segment 2
20092a
810
Installing Repeaters in a Combination of Series and Parallel

You can install repeaters in a combination of series and parallel
connections following the guidelines listed for each to form a link.
For mixed topologies (series and parallel) the maximum number of
repeaters between any two nodes is five.
"
If your network is configured using repeaters in combination of

series and parallel, you need to count the taps and repeaters in all
segments.
"
There can be only one path between any two nodes on a ControlNet
link. Multiple repeater connections between two segments are
not allowed (i.e., the ControlNet cable system does not support
ring topologies).
In this link, if each segment contains 500m (1644ft.) of cable:
segment 3 can contain up to 29 nodes, since it already contains 3 taps.

segments 1, 2, and 4 can contain up to 31 nodes each, since they already contain 1 tap for a repeater.
segments 5, 6, and 7 can contain up to 30 nodes, since they already contain 2 taps for repeaters.
the maximum number of nodes that can be connected to this link is 99 (not including repeaters).
segments 1, 2, and 3, with 33 nodes on them, can not exceed 478.4m (1570ft.).
segment 3
repeater D
repeater E
repeater F
segment 1
segment 6
segment 2
repeater B
segment 4
repeater C
segment 5
segment 7
repeater A
20133a
Determining What Type Of

Connectors You Need
811
These connectors are available:
Use this BNC connector:
To:
Cat. No.
cable connector
attach trunk-cable sections to a taps BNC connector
1786-BNC
Use this optional BNC connector:
To:
Cat. No.
bullet
(jack-to-jack)
reserve a space in the trunk cable for future installation of a tap or to

splice a trunk cable
1786-BNCJ
barrel
(plug-to-plug)
connect two adjacent taps without a trunk-cable section between

them
1786-BNCP
isolated-bulkhead
(jack-to-jack)
go through grounded panel walls while maintaining the shield

isolation of the trunk-cable.
1786-BNCJI
right angle
(jack-to-plug)
provide a 90 bend in your cable (prevent bending you cable

excessively).
See Chapter 9, Installing a ControlNet Cable System, for the bend
radius specification.
extender
(jack-to-plug)
gain additional length or clearance when required.
See Chapter 12, ControlNet

Cable System Component List,
for the part number.
In this example, the ControlNet cable:

enters and exits the panel enclosure from the side using isolated-bulkhead connectors
contains two adjacent taps connected by a barrel connector
reserves one future tap location with a bullet connector
makes a sharp bend with a right angle connector
panel wall
cable enters and

exits from the side
isolated-bulkhead
connectors
bullet connector
barrel
connector
taps
right angle
connector
19002
812
!
Important:
Using Redundant Media

(optional)
ATTENTION: Do not let any metallic surfaces on the

BNC connectors, plugs, or optional accessories touch
grounded metallic surfaces. This contact could cause
noise on the network.
If you are installing a bullet connector for future tap
installations, count the bullet as one of the tap
allotments on your segment and decrease the maximum
allowable cable length by 16.3m (53.4 ft.).
This helps you avoid reconfiguring your network when
you install the tap.
You can run a second trunk cable between your ControlNet nodes for
redundant media. With redundant media, nodes send signals on two
separate segments. The receiving node compares the quality of the
two signals and accepts the better signal to permit use of the best
signal. This also provides a backup cable should one cable fail.
Trunk cables on a redundant cable link are defined by the segment
number and the redundant trunk-cable letter.
Actual ControlNet products are labeled with these icons
(the shaded icon representing redundant media).
In this figure, the redundant cable trunk cable is trunk cable B
trunk cable A =
trunk cable B =
node
node
Node supporting redundant media.
node
20134
813
Observe these guidelines when planning a redundant media system:
Route the two trunk cables (trunk cable A and trunk cable B)
differently to reduce the chance of both cables being damaged

at the same time.
Each node on a redundant-cable link must support redundant coax
connections and be connected to both trunk cables at all times.
Any nodes connected to only one side of a redundant-cable link
will result in media errors on the unconnected trunk cable.
Install the cable system so that the trunk cables at any physical
device location can be easily identified and labeled with the
appropriate icon or letter. Each redundant ControlNet device is
labeled so you can connect it to the corresponding trunk cable.
Both trunk cables (trunk cable A and trunk cable B) of a
redundant-cable link must have identical configurations.
Each segment must contain the same number of taps, nodes and
repeaters. Connect nodes and repeaters in the same relative
sequence on both trunk cables.
Each side of a redundant-cable link may contain different lengths
of cable. The total difference in length between the two trunk
cables of a redundant-cable link must not exceed 800m (2640ft.).
SEGMENT 1
terminator
trunk cable A
terminator
trunk cable B
repeater
node
node
node
node
repeater
trunk cable B
terminator
trunk cable A
terminator
SEGMENT 2
20135
814
Avoid connecting a single nodes redundant trunk cable

connections on different segments; this will cause erratic
operation.
SEGMENT 1
trunk cable A
terminator
trunk cable B
terminator
node
repeater
node
repeater
trunk cable B
terminator
trunk cable A
SEGMENT 2
node
Important:
20136
A node supporting redundant trunk-cable connections

will function even if trunk cable A is connected to the B
connector on the node and vice-versa. This makes
cable fault indications (on the hardware or in software)
difficult to interpret and makes locating a bad cable
segment very difficult.
Application Considerations
815
The following guidelines coincide with the guidelines for the

installation of electrical equipment to minimize electrical noise
inputs to controllers from external sources in IEEE standard
518-1982. When planning your cable system there are certain
installation considerations depending on your application.
There are three categories of conductors:
Category
Includes:
ac power lines
high-power digital ac I/O lines
high-power digital dc I/O lines
power connections (conductors) from motion drives to motors
analog I/O lines and dc power lines for analog circuits
low-power digital ac/dc I/O lines
low-power digital I/O lines
ControlNet communication cables
low-voltage dc power lines
communication cables to connect between system components
within the same enclosure
General Wring Guidelines

Follow these guidelines for wiring all ControlNet cables:
If it must cross power feed lines, it should do so at right angles.
Route at least 1.5m (5ft.) from high-voltage enclosures, or
sources of RF/microwave radiation.
If the conductor is in a metal wireway or conduit, each section of
that wireway or conduit must be bonded to each adjacent section
so that it has electrical continuity along its entire length, and must
be bonded to the enclosure at the entry point.
For more information on general wiring guidelines, see the
Industrial Automation Wiring and Grounding Guidelines
(publication 1770-4.1).
Wiring External to Enclosures
Cables that run outside protective enclosures are relatively long.
To minimize cross-talk from nearby cables, it is good practice to
maintain maximum separation between the ControlNet cable and
other potential noise conductors. You should route your cable
following these guidelines:
Cable in a contiguous
metallic wireway or conduit?
Route your cable

at least:
From noise sources of this strength:
Yes
e
0.08m (3)
0.15m (6)
0.3m (12)
0.15m (6)
0.3m (12)
0.6m (24)
Category-1 conductors of less than 20A

ac power lines of 20A or more, up to 100 KVA
ac power lines greater than 100 KVA
Category-1 conductors of less than 20A
Noo
816
Wiring Inside Enclosures

Cable sections that run inside protective equipment enclosures are
relatively short. As with wiring external to enclosures, you should
maintain maximum separation between your ControlNet cable and
Category-1 conductors.
When you are running cable inside an enclosure, route conductors
external to all raceways in the same enclosure, or in a raceway
separate from Category-1 conductors.
Route your cable at least
this distance:
From noise sources of this strength:
0.08m (3)
Category 1 conductors of less than 20A
0.15m (6)
0.6m (24)
Surge Suppression
Transient electromagnetic interference (EMI) can be generated
whenever inductive loads such as relays, solenoids, motor starters,
or motors are operated by hard contacts such as pushbutton or
selector switches. These wiring guidelines assume you guard your
system against the effects of transient EMI by using
surge-suppressors to suppress transient EMI at its source.
Inductive loads switched by solid-state output devices alone do not
require surge suppression. However, inductive loads of ac output
modules that are in series or parallel with hard contacts require
surge-suppression to protect the module output circuits as well as to
suppress transient EMI.
Ferrite Beads
Ferrite beads can provide additional suppression of transient EMI.
Fair-Rite Products Corporation manufactures a ferrite bead
(part number 2643626502) which can be slipped over category-2 and
category-3 (RG-6 type trunk cable) conductors. You can secure
them with heat-shrink tubing or tie-wraps. With a ferrite bead
located near the end of a cable transient emi induced onto the cable
can be suppressed by the bead before it enters the equipment
connected to the end of the cable.
Ordering Components
817
Now that you are ready to begin ordering components, use these
guidelines to help you select components.
General Planning
The ControlNet cable system is isolated from earth and must be
protected from inadvertent ground connections.
Segment Planning
all connections to the trunk cable require a tap

taps may be installed at any location on the trunk cable
tap drop-cable length must not be changed
maximum number of taps = 48, with 250m (820ft.) of trunk cable
maximum trunk-cable length = 1000m (3280ft.), with 2 taps
75 terminators are required on both ends
unconnected drop cables are not allowed with one exception;
one tap with an unconnected drop cable may be installed for
maintenance purposes
use BNC bullet connectors at future tap locations
do not mix redundant and non-redundant nodes
avoid high noise environments when routing cables
Link Planning
maximum of 5 repeaters in series
maximum of 99 nodes (excluding repeaters)
repeaters require a tap but are not counted as nodes they are
included in the number of devices allowed per segment (48)

repeaters may be installed at any tap location along a segment
there can only be one path between any two points on a link
the configuration of both sides of a redundant segment must be
the same
the total cable difference between the two sides of a redundant
link can not exceed 800m (2640ft.)
818
Ordering Parts
Item
Tap
straight T-tap
straight Y-tap
right angle T-tap
right angle Y-tap
Repeater 85-250V ac
or 110-250V dc
20-72V dc
Cat. No.
Guidelines
Quantity needed
1786-TPS
1786-TPYS
1786-TPR
1786-TPYR
You need a tap for each connection to the

trunk cable (nodes and repeaters).
Each tap kit contains: two BNC connector
kits, 1 dust cap, 1 universal mounting
bracket, ControlNet cable labels and
2 screws
number of repeaters x 2
+
number of nodes
1786-RPT
Use a repeater to:

increase the number of nodes attached
extend the allowable cable length
Follow guidelines on page 86.
1786-RPTD
terminators
1786-XT
You need a terminator for each end

of each segment.
number of segments x 2
network access cable
1786-CP
Use this cable to temporarily connect

programming devices (through NAPs)
to ControlNet nodes.
number of programming devices
cable connector
1786-BNC
Two cable connectors are shipped with

each tap you need to order additional
cable connectors for each bullet and
isolated-bulkhead connector you will
be using.
number of bullet connectors x 2

+
number of isolated-bulkhead
connectors x 2
+
any spares
optional bullet
cable barrel
connectors
isolated-bulkhead
right angle
extender
1786-BNCJ
1786-BNCP
1786-BNCJI
Use these as specified on page 811.
depends on your network

requirements
trunk cable
For right angle and extender connector part numbers, see the
ControlNet Cable System Component List (publication AG-2.2).
Use Chapter 12, ControlNet Cable System
Component List, to order your required
length of cable.
You will need to double your quantities when ordering components for a redundant cable system.
See page 84 to select your

cable type. Follow guidelines on
page 84 to determine cable
length.
Chapter

Follow the instructions in this chapter to install your ControlNet
cable system. This chapter contains these sections:
Section
Page
Installing The Trunk Cable

Mounting The Taps
Installing A Repeater
Installing Cable Connectors
Connecting Cable Segments
Terminating The Segments
Connecting Devices
91
92
94
99
918
918
919
Important:
Installing The Trunk Cable
Read Chapter 8, Planning A ControlNet Cable

System, before you install your network.
Install your trunk cable, observing your cable suppliers installation

instructions and these guidelines.
Wiring External to Enclosures

When the RG-6 type coax cable is being pulled through multiple
conduit bends, follow these specifications:
For this coax cable:
PVC
The pull strength should

not exceed:
42.75kg (95lbs)
The bend radius should

not exceed:
76.2mm (3.0)
FEP
61.65kg (137lbs)
69.9mm (2.75)
Wiring Inside Enclosures

When the RG-6 type coax cable is not being pulled through conduit,
follow these specifications:
PVC

not exceed:
38.1mm (1.5)
FEP
35.6mm (1.4)
Tap drop-cable
25.4mm (1.0)
92
Installing A ControlNet Cable System
Mounting The Taps
To mount the taps you:
select where you want to mount the taps

mount the taps
Selecting Where to Mount the Taps
There is no spacing requirement between taps; you can install two
adjacent taps if you need to using a barrel connector
(1786-BNCP).
Make sure the mounting location is convenient for your cable
routing.
Make sure the mounting location does not cause any cable
bend-radii to exceed the limits listed on page 91.
Do not mount the tap in a position that routes the drop cable over
any ac power terminals on nearby modules.
ATTENTION: Do not allow any metal portions of

the tap, such as the universal mounting bracket screws
or connectors, to contact any conductive material.
This contact could cause noise on the network.
Mounting the Taps

You can mount your ControlNet taps (Y-tap and T-tap):
to a universal mounting bracket, and then mount the tap and

bracket as an assembly
through the body holes in the tap using:
screws and flat washers

a tie wrap
Important:
"
Once you have mounted your taps, you can discard any
unused universal mounting brackets.
See Chapter 10, Mounting Dimensions, for universal mounting

bracket and tap mounting dimensions.
93
Mounting a Tap using a Universal Mounting Bracket

1. Align the universal mounting bracket with the mounting holes on
the tap.
2. Using the screws provided with the tap, attach the tap to the
universal mounting bracket.
universal
mounting bracket
Y-tap
T-tap
dust cap
dust cap
universal
mounting bracket
(provided with the tap)
20084-M
20080-M
Use only the screws that are packaged with

the tap. They are the proper length and head style.
3. Mount the tap and bracket assembly to:

a DIN mounting rail
or
another mounting surface

Use four screws to attach the
universal mounting bracket to
another mounting surface.
universal mounting bracket

Mount the universal mounting
bracket on specified
Allen-Bradley mounting rails or
DIN Rails #3 style symmetrical
(35 x 7.5mm).
universal
mounting bracket
DIN rail
suitable
fixture
20081-M
Type of rail
A-B Rail
Cat. No.
1492-N1
1492-N22
1492-N44
Type of rail
Din Rail #3
Cat. No.
20082-M
199-DR1
1492-DR5
1492-DR6
1492-DR7
94
Mounting a Tap through the Body Holes

Mount the tap to a suitable fixture using:
tie wrap
screws
or and flat washers
screws and
flat washers
body holes
tie wrap
body holes
You can use a

variety
of screw types.
20083
!
Important:
Installing A Repeater
ATTENTION: Do not over tighten the screws.

Over tightening the screws can damage the tap.
The applied torque should be 0.2-0.4 N-m (1-2 ft-lbs).
The suitable fixture can be conductive and/or grounded

because of the electrical isolation provided by these
body holes.
To install a repeater, you need to:
See page:
read European Union Directive Compliance optional (read if you are

installing the repeater within the European Union or EEA regions)
select where to mount the repeater(s)
mount the repeater
ground the repeater
connect power and relay circuitry (optional)
95
95
96
96
97
95
European Union Directive Compliance

If this product is installed within the European Union or EEA
regions and has the CE mark, the following regulations apply.
EMC Directive
The repeater is tested to meet Council Directive 89/336
Electromagnetic Compatibility (EMC) using a technical construction
file and the following standards, in whole or in part:
EN 50081-2 EMC Generic Emission Standard, Part 2
Industrial Environment
EN 50082-2 EMC Generic Immunity Standard, Part 2
Industrial Environment
The repeater described in this manual is intended for use in an
industrial environment.
Low Voltage Directive
The repeater is also designed to meet Council Directive 73/23 Low
Voltage, by applying the safety requirements of EN 611312
Programmable Controllers, Part 2 Equipment Requirements and
Tests.
For specific information that the above norm requires, see the
appropriate sections in this manual, as well as the following
Allen-Bradley publications:
Industrial Automation Wiring and Grounding Guidelines,

publication 1770-4.1
Guidelines for Handling Lithium Batteries, publication AG-5.4
Automation Systems Catalog, publication B111
Selecting Where to Mount the Repeater(s)

The repeater should be mounted:
so that air can flow in/out of the air holes on the top and bottom
of the repeater for proper ventilation, make sure there is a
minimum of 5.1cm (2) from surrounding equipment
in a NEMA enclosure to provide protection from dust, moisture
or corrosive atmospheres
to a grounded metal plate if possible
96
Mounting the Repeater

Use these mounting dimensions to mount the repeater horizontally or
vertically in the area you selected.
9.1mm
(0.36)
38.1mm
(1.50)
8.6mm
(0.34)
215.9mm
(8.5)
9.3mm
(0.38)
196.6mm
(7.74)
197.6mm
(7.78)
12.7mm
(0.5)
19.3mm
(0.76)
101.6mm
(4.0)
50.8mm
(2.0)
Grounding the Repeater

Use a #14 AWG wire to connect the repeater to the ground bus.
Keep this lead as short as possible.
grounding stud
star washer
nut
ground lug
20150
97
Connecting Power and Relay Circuitry

1. Remove the terminal strip cover.
20150
2. Connect power to the repeater.
1786-RPT
1786-RPTD
L1
(+)
L2/N
()
20150
If you are using high voltage DC to power the 1786-RPT,

L1 is positive (+) and L2/N is negative ().
Using the fault relay terminals?
Go to step
yes
no
3
4
98
3. Connect your relay circuitry to the fault relay terminals.
contact held closed

in normal operation
L1
L2/N
20150
4. Replace the terminal strip cover.
20150
Installing Cable Connectors
99
After you have mounted the taps, you need to attach cable
connectors to the ends of your trunk-cable sections.
To:
See page:
collect your tools
99
strip the cable
910
test for electrical shorts and continuity
914
attach the cable connectors
915
test for electrical shorts and continuity
917
Collecting Your Tools

To install the cable connectors, we recommend you use the tools in
the ControlNet Coax Toolkit (cat. no. 1786CTK).
ControlNet Network Planning and
Installation Manual (1786-6.2.1)
ControlNet Network
Component List (AG-2.2)
wire cutters
cable strip tool with two blade cassettes

(one for PVC and one for FEP)
crimp tool
terminators and
extra connectors
memory blade cartridge
(contains two sets of memory blades)
knife
strip gauge
memory blade
holder
20066
910
Stripping the Cable

When cutting cable sections, make them long enough to route from
one tap to the next with sufficient slack so that the bend radius is not
less than:
76.2mm (3) for wiring external to enclosures
38.1mm (1.5) for wiring inside enclosures
1. Verify that you have the proper memory blade holder installed for
the type of cable you are using (PVC-CL2 or FEP-CL2P). If you
need to change the memory blade holder, see Chapter 11,
Adjusting the Cable Strip Tool.
blade holder
20165
2. Insert the cable into the cable strip tools cutting chamber so that
extra cable, approximately 25.4mm (1), extends beyond the edge
of the tool.
The cutting chamber houses the
center conductor that will be exposed
when the cable is stripped.
25.4mm (1)
extra cable
cable
20073
911
3. Lock the cable into place by moving the chamber-gauge ring

forward until it meets the cable with slight resistance.
cable
section
20073
This gauge moves two rollers toward

the cable and regulates the depth of the
cut.
The gauge will click as it moves from
one stage to the next.
4. Holding the cable in one hand, place the index finger of your
other hand inside the chamber-gauge ring and turn the strip tool
360 around the cable. Make 4 or 5 full rotations until the strip
tool glides easily around the cable.
20074
Continue repeating steps 3 and 4, moving the chamber

gauge ring forward one notch for each time you repeat
the steps, until you reach the last notch.
Each time you move the chamber gauge ring forward a
notch, the strip tool makes a deeper cut into the cable.
Important:
On your last repetition of steps 3 and 4, apply

sufficient pressure on the chamber gauge ring to
make sure the ring has reached the last stage.
912
5. After you have moved the chamber gauge ring to the last position
and turned the strip tool the final time:
A. Move the chamber-gauge ring backward to release the
strip tool, and remove it from the cable.
B. Strip away the appropriate portion of the cable,
without using the strip tool.
Clean the remaining cable parts from

the strip chamber after each use.
20075
This should appropriately strip the cable, exposing these layers of

the cable:
all 4 shield layers
braid/tape/braid/tape
white insulation
or 1st tape
center
conductor
sheath
4.0mm
8.3mm
Important:
3.7mm
20076a
If you do not see the three distinct layers of

cable, snip off the exposed end with the wire
cutters and repeat the entire cable-stripping
process.
If stripping problems persist, the strip tool may need adjustment.

See Chapter 11, Adjusting the Cable Strip Tool. for instructions
on how to adjust the strip tool.
If you are using:
Go to:
FEP cable
step 6
PVC cable
step 7
913
6. If you are using plenum FEP cable, cut off an additional 3.1mm
(approximately 1/8) of the outer sheath with the knife from the
toolkit.
all 4 shield layers
white insulation
or 1st tape
center
conductor
3.1mm
sheath
4.0mm
11.4mm
3.7mm
20076a
7. Make sure the center conductor is 4.0mm. Use the imprint guide
on the back of the ControlNet tap or the strip gauge to verify this.
center
conductor
(4.0mm)
PVC cable
1786RG6
STRIP GAUGE
PVC/CL2
PVC cable only
FEP/CL2P
FEP cable
T-ta
p
center
conductor
(4.0mm)
If the center conductor is too long, cut off the excess
with the wire cutter from the cable kit. If it is too short,
repeat the entire cable-stripping process.
20076a
ATTENTION: Check for any braid stranding that may

not have been cut at the proper length. Even one strand
coming in contact with the center conductor could
short out the cable. If any such strands are found, cut
them to the correct length.
914
Testing for Electrical Shorts and Continuity

1. Using an ohmmeter or continuity tester, test for a short between
the center conductor and the shield.
If the resistance
reading indicates:
there is no short
that a short exists
ohmmeter
Then:
continue to step 2
inspect the ends of the
cable for shorted circuits
if you are unable to locate a
short, replace the
trunk-cable section
20166-I
2. Connect a temporary short between the center conductor and the

shield at one end of the cable.
20166-I
3. At the other end of the cable, use an ohmmeter or continuity

tester to test for electrical continuity.
ohmmeter
If the resistance
reading indicates:
there is no short
that a short exists
Then:
replace the
trunk-cable section
continue to next
section
20166-I
Important:
Replace the trunk-cable section if problems

persist with the cable after completing
these tests.
915
Attaching the Connectors to the Cable

1. Slip the crimp ferrule onto the cable. Push it back to the sheath
area of the cable to keep it out of the way for the moment.
crimp ferrule
stripped cable
20077a
2. Place the center pin over the center conductor.

center
conductor
center pin
Important:
20077b
Make sure that the center pin slips onto the

center conductor completely. The back shoulder
of the center pin should be up against the white
insulation. If it is not, recheck the length of the
center conductor.
3. With the center pin in place, use the crimp tool to crimp the pin
into place.
The smaller hexagonal
crimping notch is for crimping
the center pin onto the center
connector.
20167
4. Slide the ControlNet connector onto the cable.

braid and tape shields
connector base
connector
77002c
916
5. Move the connector in a circular motion (without any inward

pressure) to work the connector base underneath the three outer
shields. Once a gap has opened up between the inner shield tape
and the three outer shields, start applying inward pressure to seat
the connector base under the three outer shields
(braid/tape/braid).
The wire is pliable

and may fray slightly.
20077d
6. Slide the crimp ferrule over the three outer shields and connector
base until it meets the shoulder on the connector.
crimp ferrule
20077e
7. Using the crimp tool, crimp the ferrule. Position the crimp tool
on the ferrule as close as possible to the connector base and
ferrule meeting line. Press the tool tightly around the ferrule until
the crimp tool allows release.
The larger hexagonal
crimping notch is for
crimping the ferrule which
holds the connector to the
cable.
crimp ferrule
20167
Important:
917
Many network problems are due to improperly

installed connectors. You should have
tight-fitting connectors on the ends of all your
cables. Pull the connector to verify that it is
attached. If it is loose or comes off, snip off the
connector and install a new one.
Testing for Electrical Shorts and Continuity

1. Using an ohmmeter or continuity tester, test for a short between
the connector body and pin.
If the resistance
reading indicates
there is no short
that a short exists
ohmmeter
connector body
pin
20166
Then
continue to next section
use your wire cutters to
cut off the connector,
install a
new connector and begin
testing again
2. Connect a temporary short between the pin and connector body at

one end of the cable.
connector body
pin
20166
3. At the other end of the cable, use an ohmmeter or continuity

tester to test for electrical continuity.
If the resistance
reading indicates
there is no short
ohmmeter
connector body
that a short exists
pin
Then
use your wire cutters to cut
off the connector, install a
new connector and begin
testing again
continue to next section
20166
Important:
Replace the trunk-cable section if problems persist with

the cable after completing these tests.
918
Connecting Cable Segments
Connect the cable sections to the taps BNC connectors.
20078
Terminating Segments
The taps on the ends of the segment have only one cable connector
attached to them. This leaves an open, or unterminated, end on the
segment. Signals transmitted along the cable will reflect off these
unterminated ends and interfere with transmission.
To eliminate signal reflections from the ends of the segment,
you must attach a 75 terminator to the first and last taps on the
segment. The terms first and last refer to the physical location
of the node along the trunk cable.
1. Connect one end of the trunk-cable section to one of the taps
BNC connectors.
20078
2. Install a 75 terminator onto the taps other BNC connector.
1786-XT
20079
Repeat steps 1 and 2 at the other end of the

segment.
Connecting Devices
919
After terminating your segments, you connect your devices.

To connect a:
See:
programming terminal through the NAP
page 919
repeater
page 921
ControlNet processor, adapter or programming terminal via a

communication interface
procedure below
1. Remove and save the taps dust cap (located on the straight or
right-angle connector).
2. Connect the taps straight or right-angle connector to your device.
If your node supports:
Connect the taps straight or right-angle connector:
non-redundant media
to the channel A connector on the device (channel B is

not used)
from trunk cable A to channel A on the your device
from trunk cable B to channel B on the your device
redundant media
While both channels are active, Allen-Bradley recommends using channel A for
non-redundant media.
Connecting Programming Terminals Through the NAP

Use the ControlNet network access cable (1786-CP) to connect
a programming terminal to any intelligent device (i.e., workstation,
PLC processor, or adapter) on a ControlNet link through the network
access port (
).
1. Connect one end of the 1786-CP cable to the NAP on the front of
the ControlNet node (1785-L20C, 1785-L40C, 1771-ACN,
1771-ACNR, or 1794-ACN).
2. Connect the other end of the 1786-CP cable to the NAP on the
ControlNet communication interface (1784-KTC, -KTCX or
1770-KTC) installed in (or connected to) your programming
terminal.
920
ATTENTION: Do not use the 1786-CP cable as

shown below. These connections could result in
network failures.
1786-CP
do not use the 1786-CP cable to connect

your programming device to ControlNet
two ways simultaneously
1786-CP
do not use the 1786-CP cable
to connect a scanner or adapter
module to a PLC processor
1786-CP
1786-CP
do not use the 1786-CP cable to
connect two separate ControlNet
segments
20140
921
Connecting a Repeater to a ControlNet Link

1. Remove (and save) the dust cap located on the straight or
right-angle connector of the designated tap on the first segment
(segment 1).
ATTENTION: Do not allow any metal portions

of the tap to contact any conductive material. This
contact can cause noise on the network.
If you disconnect the tap from the repeater, place
the dust cap back on the straight or right-angle
connector to prevent the connector from
accidentally contacting a metallic grounded surface.
segment 1
tap
dust cap
20093-I
2. Remove and discard the dust caps from the repeater BNC jacks.
3. Connect the designated taps straight or right-angle connector to
BNC connector on the repeater.
the the
segment 1
tap
To prevent inadvertent reversal of the tap

connections (resulting in incorrect LED
displays and troubleshooting), check the tap
drop cable for a label indicating the attached
segment before making your connection.
20093-I
922

right-angle connector of the designated tap on the second segment
(segment 2).
segment 2
tap
dust cap
20093-I
5. Connect this taps straight or right-angle connector to the the

segment 1
tap
segment 2
tap
20093-I
Chapter
10

Use these mounting dimensions to mount your taps, universal
mounting brackets, and repeaters. This chapter contains these
sections:
Taps
Section
Page
Taps
101
Universal Mounting Bracket
102
Repeater
102
Make copies of these templates as necessary to help you mark

placement for your taps.
T-tap
Y-tap
30.23mm
(1.19)
35.56mm
(1.40)
15.24mm
(0.60)
33.02mm
1.30
15.24mm
(0.60)
25.4mm
(1.00)
39.37mm
(1.55)
31.37mm
(1.235)
20168
20169
actual size
102
Mounting Dimensions
actual size
58.42mm
(2.30)
49.53mm
(1.95)
15.47mm
(0.609)
30.94mm 19.05mm
(1.218) (0.75)
9.53mm
(0.375)
20170-M
38.1mm
(1.50)
9.1mm
(0.36)
8.6mm
(0.34)
215.9mm
(8.5)
Repeater
50.8mm
(2.0)
9.3mm
(0.38)
196.6mm
(7.74)
197.6mm
(7.78)
12.7mm
(0.5)
19.3mm
(0.76)
101.6mm
(4.0)
Chapter
11

Follow the instructions in this chapter to adjust the cable strip tool,
supplied with the ControlNet Coax Toolkit (1786-CTK).
Adjusting The Cutting

Blades
Section
Page
Adjusting The Cutting Blades
111
Reversing/Replacing The Cutting Blades
112
Changing The Memory Blade Holder
114
Adjust the blade cutting depth by turning the three screws located in
the memory blade holder. Each screw adjusts the corresponding
blade in the blade cassette.
adjusting screws
To:
Turn the screw:
increase the cut depth
clockwise
decrease the cut depth
counterclockwise
20068
Adjust the three screws until the strip tool makes these cuts in
the cable:
2 white insulation
or 1st tape
1 all 4 shield layers
3 center
conductor
sheath
4.0mm
8.3mm
1 The first cut should cut the outer

sheath without cutting the outer
wire braid.
2 The second cut should cut the
sheath, the three outer shields, and

possibly the inner tape shield. The
insulation can be scored slightly, but
should not have a deep cut.
Important:
3.7mm
3 The third cut should cut all layers

of the cable down to the center
conductor. This cut should not
score the center conductor.
20076a
The first and second cut adjustments need to be precise.

Adjustments as small as 1/12 to 1/8 of a turn can make
the difference between a perfect and an imperfect cut.
112
Adjusting The Cable Strip Tool
Reversing/Replacing
The Cutting Blades
To reverse or change the cutting blades:

1. Use a screwdriver to lift the memory blade holder and swing
it back.
20182
2. Slide the memory blade cartridge out of the strip tool.
20183
If you are:
Go to:
reversing the memory blade cartridge to use

the second set of blades
step 3
replacing the memory blade cartridge
step 4
113
3. Flip the memory blade cartridge and slide it back into the
strip tool. Go to step 5.
20184
4. Align the memory blade cartridge (the side with the raised
notches) to the raised area on the inside of the strip tool and slide
the new memory blade cartridge in the blades should be on top
as you slide the cartridge in.
raised notch
raised area
20184
5. Swing the memory blade holder closed.
20069
114
Changing The Memory

Blade Holder
You received two memory blade holders with your cable strip tool;
one is for PVC-CL2 cable, and the other is for plenum FEP-CL2P
cable. You need to install the appropriate memory blade holder for
the type of cable you are stripping (PVC or FEP).
1. Lift the latches on the memory blade holder and swing it back.
20182
2. Snap the memory blade holder off the rod and remove it from the
strip tool.
20070
3. Position the appropriate memory blade holder on the rod and snap
the holder into place.
4. Swing the memory blade holder closed.
20069
Chapter
12

This chapter contains the current ControlNet cable system
components and their suppliers. Contact the suppliers at the
addresses and phone numbers listed for current availability and
additional application information. This chapter contains these
sections:
Section
Page
ControlNet Components
122
Contacting Suppliers
124
122
ControlNet Cable System Component List
ControlNet Components
Item
Supplier
Catalog Number
or Part Number
right-angle T-tap
straight T-tap
right-angle Y-tap
straight Y-tap
repeaters
Allen-Bradley
1786-TPR
1786-TPS
1786-TPYR
1786-TPYS
high-voltage ac & dc
low-voltage dc
RG-6 quad shield cable
Allen-Bradley
1786-RPT
1786-RPTD
flooded-burial
Belden
Comm/Scope
1190A
5740B
high-flex
Allen-Bradley
Belden
Comm/Scope
Belden
PVC/Aluminum
Belden PVC/Steel
Comm/Scope
Belden
Comm/Scope
Belden
Comm/Scope
Belden
Comm/Scope
Allen-Bradley
Belden
Comm/Scope
Allen-Bradley
1786-RG6F
YR-28890
5740F
121189A
Allen-Bradley
Weidmuller, Inc.
Paladin Tools
Weidmuller, Inc.
Paladin Tools
Weidmuller, Inc.
Paladin Tools
Weidmuller, Inc.
Paladin Tools
Weidmuller, Inc.
Paladin Tools
Weidmuller, Inc.
Paladin Tools
1786-CTK
1349AB
coax tap kit
interlocking-armor
corrugated-armor
messengered
plenum-FEP CMP-CL2P
siamese (dual)
standard-PVC CM-CL2
ControlNet network access cable, 3.05 m (10 ft)

tools
ControlNet coax toolkit
crimp tool with die
crimp die
strip tool with blade cassette and
PVC memory holder
blade cassette
cassette memory holder - FEP
cassette memory holder - PVC
131189A
5740A
1191A
5740M
1152A
2227K
9072
5740S
1786-RG6
1189A
5740
1786-CP
2082
1247AB
2247X
2245AB
2245AB2
Allen-Bradley cable is packaged in 304.8 m (1000 ft) rolls; quantity of 1 = 304.8 m (1000 ft).
Allen-Bradley connectors are packaged in lots of 50; quantity of 1 = 50 connectors.
Radialls isolated-bulkhead connector is a square-flange, four-screw mounting style connector.
Item
123
Supplier
Catalog Number
or Part Number
Allen-Bradley
Amphenol
Global
Components
Kings
Radiall
Trompeter
Allen-Bradley
Amphenol
Global
Components
Allen-Bradley
AMP
Amphenol
Global
Components
Kings
Radiall
Trompeter
Amphenol
Allen-Bradley
Amphenol
Global
Components
Kings
Radiall
Trompeter
AMP
Amphenol
Global
Components
Kings
Radiall
Trompeter
Allen-Bradley
AMP
Amphenol
Global
Components
Kings
Radiall
Trompeter
1786-BNCP
31-218-75RFX
09C-032
BNC connectors
barrel (plug to plug)
BNC/RG-6 coax cable connector
bullet (jack to jack)
extender (plug to jack)

isolated-bulkhead
(jack
jac to jack)
jac
right-angle
(plug-to-jack)
plug-to-jac
terminators (BNC-75)
2029-18-9
R142703
ADUPL20-K1UPL20
1786-BNC
31-71000-RFX
09C-033
1786-BNCJ
221551-3
31-219-RFX
09C-036
2029-15-9
R142704
UAD28
21925-1001
1786-BNCJI
31-4803-1101
09C-038
2029-17-9
R142717
UBJ28
222165-2
31-9-RFX
09C-037
2029-25-9
R142770
UADRNMF20
1786-XT
221629-5
46650-75RFX
09C-034
2555-3-34
R404012
UTNA1-1175
Allen-Bradley cable is packaged in 304.8 m (1000 ft) rolls; quantity of 1 = 304.8 m (1000 ft).
Allen-Bradley connectors are packaged in lots of 50; quantity of 1 = 50 connectors.
Radialls isolated-bulkhead connector is a square-flange, four-screw mounting style connector.
124
Contacting Suppliers
Contact the suppliers using the following addresses and

phone numbers.
ALLEN-BRADLEY COMPANY
Canada
Great Britain
AMP of Canada Limited

20 Esna Park Drive
Markham, Ontario
Canada L3R 1E1
Tel: 416 475 6222
Fax: 416 474 5520
AMP of Great Britain Limited

Merrion Ave.
Terminal House
Stanmore
Middlesex HA7 4RS
England
Tel: 011 44 81 954 2356
Fax: 011 44 81 954 6234
To place an order, contact your local

Allen-Bradley sales office.
For nearest sales office, contact:
Allen-Bradley Company, Inc.
1 Allen-Bradley Drive
Mayfield Heights, Ohio 44124
Tel: 216 646 4677
Fax: 216 646 4399
AMP
Argentina
AMP S.A. Argentina C.I.Y.F.
Juncal 2869
(1640) Martinez
Prov. Buenos Aires
Argentina
Tel: 011 54 1 793 7311
Fax: 011 54 1 793 9331
Australia
Melbourne
Australian AMP Pty. Limited
Unit 11/19-23 Kylie Place
Cheltenham
Victoria 3192
Australia
Tel: 011 61 3 532 1311
Fax: 011 61 3 553 4936
Austria
AMP Osterreich GmbH
Pilzgasse 31
A-1210 Wien
Austria
Tel: 011 43 1 277 97 0
Fax: 011 43 1 270 26 61
Belgium
Brussels Branch Office of AMP Holland
Bedrijfspark Keiberg
Excelsiorlaan 5
1930 Zaventem
Belgium
Tel: 011 32 2 719 2511
Fax: 011 32 2 721 3263
Brazil
AMP do Brazil
Rua. Ado Benatti 53
CEP 05037 Sao Paulo
Brazil
Tel: 011 55 11 861 1311
Fax: 011 55 11 861 0397
China
Beijing
AMP Beijing Office
Room 3039, Hotel Beijing
Toronto Jianguo
Men Wai DA JIE
Peoples Republic of China
Tel: none
Fax: 011 86 1 500 2022
Holland
AMP-Holland B.V.
Rietveldenweg 32
5222 AR s-Hertogenbosch
The Netherlands
Tel: 011 31 73 20 0911
Fax: 011 31 73 21 2365
Czech Republic
Hong Kong
Czech s.r.o.
CR-61254 Brno
Sumavska 33
Czech Republic
Tel: 011 42 5 412 12 444
Fax: 011 42 5 412 11 180
AMP Products Pacific Limited

Room 1301, Ocean Centre
5 Canton Road
Tsimshatsui, Kowloon
Hong Kong
Tel: 011 852 735 1628
Fax: 011 852 735 0243
Denmark
AMP Denmark
Gunnar Clausens Vej 36
Postbox 2211
DK-8260 Viby J
Denmark
Tel: 011 45 86 295 055
Fax: 011 45 86 295 133
Hungary
Finland
India
AMP Finland OY
Konalantie 47C
SF-00390, Helsinki
Finland
Tel: 011 358 0 547 2255
Fax: 011 358 0 547 2250
Cochin
AMP Tools (India) PVT LTD
Plot No. 44
Cochin Export Processing Zone
Kakkanad
Cochin 682030
Tel: 011 91 484 422597 or
011 91 484 422598
Fax: 011 91 484 422593
France
AMP de France S.A.
Rue Ampere
29, Chaussee Jules-Cesar
95300 Pontoise
France
Tel: 011 33 1 3420 8888
Fax: 011 33 1 3420 8600
Germany
AMP Deutschland GmbH
Ampere Str. 7-11
63225 Langen
Germany
Tel: 011 49 6103 7090
Fax: 011 49 6103 709223
AMP Hungary Trading Kft.

H-1106 Budapest
Jaszberenyi ut 34/36
Hungary
Tel: 011 36 1 157 4236
Fax: 011 36 1 157 4312
Ireland
AMP Ireland Limited
65 Broomhill Road
Tallaght Industrial Estate
Dublin 24
Ireland
Tel: 011 353 1 51 7333
Fax: 011 353 1 52 7685
AMP (continued)
Italy
AMP Italia S.p.A.
Via Fratelli Cervi 15
10093-Collegno (Torino)
Italy
Tel: 011 39 11 401 2111
Fax: 011 39 11 403 1116
Japan
main office
AMP (Japan) Limited
3-5-8 Hisamoto
Takatsu-Ku
Kawasaki-shi, Kanagawa 213
Japan
Tel: 011 81 44 844 8111
Fax: 011 81 44 812 3207
Korea
AMP Korea Limited
11F, B-Block Samho
Center Bldg. 275-6
Yangjae-Dong, Sucho-Ku
Seoul 137-130 Korea
Tel: 011 82 2 589 0535
Fax: 011 82 2 589 0524
Malaysia
Kuala Lumpur
AMP Products (Malaysia) SDN. BHD.
No. 67, Jalan Telawi Tiga
Off Jalan Maarof
Bangsar Baru
59100 Kuala Lumpur
Malaysia
Tel: 011 60 3 2828128
Fax: 011 60 3 2828951
Mexico
Amp de Mexica, S.A.
Alfredo B. Nobel No. 28
La Loma
54060 Tlalnepantla, Edo. Mex.
Mexico
Tel: 011 525 729 0400
Fax: 011 525 398 7964
New Zealand
New Zealand AMP Ltd.
57 Mahunga Drive
Mangere
Auckland
New Zealand
Tel: 011 64 9 6344580
Fax: 011 64 9 6344586
Norway
Thailand
AMP Norge A/S

Rudssletta 97
P.O. Box 84
N-1351 RUD
Norway
Tel: 011 47 67 135 080
Fax: 011 47 67 136 998
AMP (Thailand) Limited

10F Thansettakij Bldg.
222 Vipavadee-Rangsit Road
Ladyao, Jatujak
Bangkok 10900
Thailand
Tel: 011 662 513 9888 or
011 662 278 5830 34
Fax: 011 662 513 9889
Portugal
AMP Portugal, LDA
Rua Joaquim
Antonio De Aguiar
NR 66 1 DT
1000 Lisboa
Portugal
Tel: 011 351 1 3877016 or
011 351 1 3877057
Fax: 011 351 1 877172
Singapore
AMP Singapore Pte. Ltd.
26 Ang Mo Kio
Industrial Park 2
Singapore 2056
Tel: 011 65 482 0311
Fax: 011 65 482 1012
Spain
AMP Espanola, S.A.
Muntaner, 249-5A
08021 Barcelona
Spain
Tel: 011 34 3 200 8466
Fax: 011 34 3 201 7879 or
011 34 3 414 5606
Sweden
AMP Svenska AB
Datavagen 5
Jakobsberg
Sweden
Tel: 011 46 8 580 833 00
Fax: 011 46 8 580 194 70
Switzerland
AMP (Schweiz) A.G.
Amperestrasse 3
9323 Steinach
Switzerland
Tel: 011 41 7 147 0707
Fax: 011 41 7 147 0347
Taiwan
AMP Taiwan B.V.
Rm. 1404, No. 136 Jen Ai Rd.
Section 3
Taipei, Taiwan
Republic of China
Tel: 011 886 2 325 0391
Fax: 011 886 2 325 0398
125
Turkey
AMP Elektrik-Elektronik
Baglanti Sistemleri Ticaret Ltd. Stl
Buyukdera Cad. Yapi Kerdi Plaza
B Blok 26A
80620 Levent-Istanbul
Turklye
Tel: 011 90 212 281 8181
Fax: 011 90 212 281 8184
United States
Amp Incorporated
P.O. Box 3608
Harrisburg, PA 17105-3608
Tel: 717 564 0100
Fax: 717 986 7605
AMPHENOL
Australia
Amphenol Rep. Office
Suite 9, 214 Bay St.
Brighton, Victoria 3186
Australia
Tel: 61 3 595 0246
Fax: 61 3 596 2538
Austria
Amphenol GmbH
Tautenhynngasse 22
A-1150 Wien (Vienna)
Republik Osterreich
Tel: 43 1 985 1511
Fax: 43 1 982 6101
Telex: 847 132661 AMPHW A
Belgium
Amphenol Behelux B.V.
Liaison Office
Bergensestenweg 1135
Chaussee de Mons 1135
Brussel 1070 Bruxelles
Belgium
Tel: 32 02 523 11 18
Fax: 32 02 523 11 99
126
AMPHENOL (continued)
Canada
Montreal (ACC)
Amphenol Canada Corp.
1870 Des Source #104
Pointe Claire, PO
H9R 5N4 Canada
Tel: 514 630 7242
Fax: 514 630 7697
Toronto
Amphenol Canada Corp.
20 Melford Dr.
Scarborough, Ontario
M1B 2X6 Canada
Tel: 416 291 4401
Fax: 416 292 0647
France
Amphenol Socapex
5, rue du President Kruger
92403 Courbevole Cedex
8P 5 France
Tel: 33 1 490 53922
Fax: 33 1 433 31125
Telex: 842 215709
Germany
Amphenol Tuchel
Electronics GmbH
Aug.-Hausser Str 10
Posttfach 3469
7100 Heilbronn
Germany
Tel: 49 7131 4860
Fax: 49 7131 488323
Telex: 841 728224
Hong Kong
Amphenol East Asia Ltd
Unit 705-6 7/F Block B
37-39 Ma Tau Wal Rd
Hung Hom
Kowloon, Hong Kong
Tel: 852 362 0787
Fax: 852 764 7910
Telex: 780 39289
India
Amphetronix Limited
Plot No. 105
Bhosari Industrial Area
Post Box No. 1
Poona
411 026 India
Tel: 91 212 790363
Fax: 91 212 790681
Telex: 953 146237
Italy
U.K.
Amphenol Italia SpA

Galleria Gandhi 2/27
20017 Mazzo di Rho
Milano, Italia
Tel: 39 2 93503910
Fax: 39 2 93503206
Telex: 843 334623
Amphenol Limited
Thanet Way
Whitstable, Kent
CT5 3JF England
Tel: 44 227 773200
Fax: 44 227 276571
Telex: 851 96157
Japan
United States
Nippon Interconnect Co.

689-1, Aza Nogami, Iseochi,
Ritto-Cho, Shige-Ken, 520-30
Japan
Tel: 81 775 53 8501
Fax: 81 775 53 0047
Telex: 781 5467 065
Amphenol
RF/Microwave Operations
One Kennedy Avenue
Danbury, Connecticut 06810
Tel: 203 743 9272 or
800 625 7100
Fax: 203 796 2032
Telex: 710 456 0281
Netherlands
Amphenol Benelux B.V.
Peppelkade 2a
3992 AK Houten
The Netherlands
Tel: 31 3403 76499
Fax: 31 3403 77899
Telex: 844 40794
New Zealand
Amphenol Rep. Office
Suite 9, 214 Bay St.
Brighton, Victoria 3186
Australia
Tel: 61 3 595 0246
Fax: 61 3 596 2538
Singapore
80 Genting La #09-04
Genting Block
Ruby Industrial Complex
Singapore 1334
Republic of Singapore
Tel: 65 7433022
Fax: 65 7432466
Telex: 786 23499
Sweden
Amphenol Scandinavia AB
Box 2047
Johanneslundevaegen 2
S-194 02 UpplandsVaesby
Sweden
Tel: 46 8 590 77100
Fax: 46 8 590 33800
Telex: 854 17890
Taiwan
180 Pu-Yi Road
Chung U City
32006 Taoyuan Hsien
Taiwan R.O.C.
Tel: 886 3 462 9445
Fax: 886 3 451 4062
BELDEN CORPORATION
Australia
Belden Electronics
South Yarra Corporation Center
Suite 34, 209 Toorak Road
South Yarra, Victoria 3141
Australia
Tel: 03 826 0448
Fax: 03 827 2230
Contact: Bob Mckaige
England
Cooper Energy Services
Chester House
86, Chertsey Road
Woking, Surrey GU21 5BJ
England
Tel: 0483 726 818
Fax: 0483 771 569
Contact: Paul Welch
France
Belden Electronics SARL
33, Quai de Dion Bouton
F-92814 Puteaux Cedex
France
Tel: 1 4081 0370
Fax: 1 4081 0222
Germany
Belden Electronics Gmbh
Fuggerstr 2
4040 Neuss 1
Germany
Tel: 02131 3 16 0
Fax: 02131 3 16 237
Contact: Phil Dunn
BELDEN CORPORATION (continued)

Italy
Belden Electronics
c/o A & B SRL
Via Finocchiara Aprile 114
20124 Milano
Italy
Tel: 02 29 00 09 91
Fax: 02 659 59 13
Cooper Industries / Belden Division
The Plaza, 7500A Beach Road
#14-139/320
Singapore 0719
Tel: 65 298 8311
Fax: 65 296 3807
Sweden
CLOFIS SA
Brusseleesteenweg, 539
B3090 Overilse
Tel: 02 657 18 05
Fax: 02 657 26 20
Telex: 22 693
United States
Comm/Scope Company
Network Cable Division
3642 US Hwy 70 East
P.O. Box 879
Claremont, North Carolina 28610-0879
Tel: 704 459 5000 or
800 982 1708
Fax: 704 459 5099
Telex: 801 166
Belden Corporation
P.O. Box 1980
Richmond, Indiana 47374
Tel: 317 983 5200
or 800 BELDEN 1
Fax: 317 983 5294
COMM/SCOPE COMPANY
Belgium
Brazil
BRASITEC Imp. Com. Ltda.
R. Americo Braslliense 2069
04715 - Sao Paulo
Tel: 011 532 40 44
Fax: 011 521 02 21
Telex: 115 66 91
Canada
Birde Marketing, Inc.
111 Esna Park Drive
Markham, Ontario L3R 1H2
Tel: 905 477 77 22
Fax: 905 477 78 13
Denmark
Knud Kamuk A/S
Bredebovej 31
DK 2800 Lyngby
Tel: 42 883 833
Fax: 42 884 077
Eastern Europe
NETWORK CABLE DIVISION

GENERAL INSTRUMENT CORPORATION
Av. du Scheutbosch 51 B3
B-1080 Brussels
Belgium
Tel: 011 32 2 410 9584
Fax: 011 32 2 410 9584
Contact Henri Van Hulsel
England and Spain
3642 US Hwy 70 East

P.O. Box 879
Contact: Tom Ward
Tel: 407 447 0016
United States
Belgium
LEMOSA GmbH
Wurlitzergasse 10/3
A1160 Wien
Tel: 0043 1 45 37 95
Fax: 0043 1 46 52 438
Telex: 114 049
South America
Belden Electronics
Karlavagen 18
P.O. Box 5671
11486 Stockholm
Sweden
Tel: 08 614 5080
Fax: 08 614 5180
3642 US Hwy 70 East

P.O. Box 879
Contact:
Greg Winn
Tel: 916 939 1288
Fax: 916 939 1287
Austria
Alameda Casa Bronca 438

Apt. #72, Ceerqueira Cezar
Sao Paulo
SP 01408-000 Brazil
Tel: 011 55 11 289 0860
Fax: 011 55 11 287 3078
Contact: Ricardo LaGuardia
Willow
19, Haycroft Close
Bishops Cleve
Cheltenham Gloustershire GL 52 4SR
England
Tel: 011 44 242 673465
Fax: 011 44 242 573466
Contact: Mike Jones
Singapore
Asia Pacific Region
Brazil
127
GLOBAL COMPONENTS
Global Components Corporations
3729 Paoli Pike
Floydsknobs, Indiana 47119
Tel: 821 923 1000
Fax: 812 923 1001
KINGS ELECTRONICS
COMPANY, INC.
Kings Electronic Company, Inc.
40 Marbledale Road
Tuckahoe, New York 10707
Tel: 914 793 5000
Fax: 914 793 5092
LEMO
Australia
John Barry Group Pty. Ltd
1 MacLaghlan Avenue
Artarmon, Sydney, NBW 2064
Tel: 02 439 69 55
Fax: 02 439 23 76
Telex: 25 188
Redel Elektronika Kft

Helsinki ut 51.
H - 1201 Budapest XX.
Tel: 36 1 280 15 25
Fax: 36 1 280 16 03
Finland
Field Oy
Niittylantle S
SF 00620 Helsinki
Tel: 0 777 571
Fax: 0 798 853
France
Lemo France Sarl
Allee des Erables, Bat. D
ZAC Paris Nord ll
F 93420 Villepinte
Tel: 1 48 63 70 36
Fax: 1 48 63 70 37
Telex: 232 374
128
LEMO (continued)
Germany
Lemosa GmbH
Stahlgruberring 7
D 81829 Munchen
Tel: 089 42 30 65
Fax: 089 4 20 21 92
Telex: 5 216 610
Great Britain
Lemo (U.K.) Ltd
12, North Street
GB Worthing
West Suxxex, BN11 1DU
Tel: 0903 234 543
Fax: 0903 206 231
Holland
Geveke Electronics B.V.
Business Unit Componenten
Donauweg 10
1043 AJ Amsterdam
Tel: 020 5861 540
Fax: 020 5861 985
Hungary
Redel Elektronika Kft
Helsinki ut 51.
H 1201 Budapest XX.
Tel: 38 1 280 15 25
Fax: 38 1 280 16 03
Hong Kong, P.R. of China

Cosa Liebermann Ltd
Machinery Division
16-22 Floor, Tower 2
China Hong Kong City
33, Canton Road
Tsim Sha Taul, Kowloon
Hong Kong
Tel: 738 98 88
Fax: 736 21 17
India
Technical Trade Links
Deodhar Centre
Gyani Compound
424, Maroi Maroshi Road
Andherl East
Bombay 400 059
Tel: 22 832 24 12
Fax: 22 837 67 19
Telex: 11792 61
Indonesia
P.T. Gemabangun Pronaperkasa
Kompleks Mangga Dua Plaza
Blok G No 20
Jl. Mangga Dua Raya
Jakarta 10730
Indonesia
Tel: 62 21 612 18 47/48/49
Fax: 62 21 612 00 94
Israel
Republic of South Africa
Giveon Agencies Ltd

Silver house, 7 Abba Hitel Silver st.
4th Floor, Room 14
Ramat Gan 52522
Tel: 03 5755 102
Fax: 03 5755 104
Weil Measurement & Control Co.

P.O. Box 5
Wendywood
Sandton 2144
Tel: 011 444 11 28
Fax: 011 444 16 89
Italy
Singapore, Malaysia,
Thailand, Philippines
Lemo Italia arl

Viale Lunigiana 25
I 20125 Milano
Tel: 02 667 11032/46
Fax: 02 667 11066
Lemo Italia srl
Via R. Ghigllanovich 21
I 00143 Roma
Tel: 06 505 11990/99
Fax: 06 505 11993
Japan
Lemo Japan Ltd
Kada-Yushima Bldg.
Yushima 3-14-8
Bunko-Ku, Tokyo
113 Japan
Tel: 03 5688 8931
Fax: 03 5688 8930
New Zealand
Connector Systems Ltd
210 Khyber Pass Road
Auckland
Tel: 9 377 4945
Fax: 9 309 1882
Telex: 21 543
Norway
Henaco A/S
Trondhelmsvelen 438
P.O. Box 126 Kaldbakken
N 0902 Oslo 9
Tel: 22 16 21 10
Fax: 22 25 77 80
Portugal
Lusocresa
Rua de Villa Fontes, 33
Oilvala Sul
P 1800 Lisboa
Tel: 01 851 74 32
Fax: 01 851 38 11
Republic of Korea
V.K. Corporation
P.O. Box 393 Yoido
Seol
Tel: 02 784 7081/4
Fax: 02 785 1800
Telex: 28 887
Kestronics (S) PTE Ltd

1090 Lower Delta Road 07-01/07
Tiong Bahru Industrial Estate
Singapore 0316
Tel: 278 62 11
Fax: 65 274 18 96
Spain
Cresa SA
Ronda Can Fatjo, 13
Parque Tsonotogico del Valles
08290 - Cerdanyola - Barcelona
Tel: 93 580 90 00
Fax: 93 580 44 33
Sweden
AB D.J. Stork
P.O. Box 1037
S 17221 Sundbyberg 1
Tel: 08 289 215
Fax: 08 627 58 77
Telex: 11 679
Switzerland
Lemo Verkauf A.G.
Grundstrasse 22
CH 6343 Rotkreuz
Tel: 042 644 940
Fax: 042 644 943
Taiwan
Everharmony Enterpr. Inc.
P.O. Box 96-47
Tapei, R.O.C.
Tel: 02 70 70 069
Fax: 02 70 24 723
Telex: 23 914
United States
LEMO USA Inc.
Electronic Connectors
P.O. Box 11488
335 Tesconi Circle
Santa Rosa, California 95406
Tel: 707 578 8811 or
800 444 LEMO
Fax: 707 578 8069
RADIALL
Asia
RADIALL Electronics (ASIA) Ltd
12/F Bing Fu Commercial Building
450-454 Portand Street
Kowloon - Hong Kong
Tel: 852 393 37 22
Fax: 852 393 21 22
Telex: 57072 BISHAHX
Benelux - Scandinavia
United States
RADIALL Inc.
150 Long Beach Boulevard
Stratford, Connecticut 06497
Tel: 203 386 1030
Fax: 203 375 3808
Telex: 311796 RADIALL USA
TROMPETER
ELECTRONICS, INC.
RADIALL (Nederland) B.V.

Postbus 64
3870 CB Hoevelaken - Nederland
Tel: 03495 34009
Fax: 03495 34512
Trompeter Electronics, Inc.

31186 La Baya Drive
Westlake Village, California 91362-4047
Tel: 818 707 2020
Fax: 818 706 1040
Telex: 910 494 1210
RADIALL (Sweden) A.B.

Sjoangsvagen 2
19172 Sollentuna - Sweden
Tel: 08 754 73 15
Fax: 08 754 49 16
WEIDMULLER, INC. /
PALADIN TOOLS
RADIALL (Finland)
Postbox 43
SF-00751 Helsinki - Finland
Tel: 358 0 339 409
Fax: 358 0 339 450
129
Weidmuller Inc./Paladin Tools

3543 Old Conejo Road Suite 101
Newbury Park, California 91320
Tel: 805 499 0318
Fax: 800 272 5247
Brazil
RADIALL do Brasil componentes
eletronicos Lda
Av. Beira Mar, 262 - 6 Andar
CEP-20021 Rio De Janeiro
Tel: 55 21 282 13 25
Fax: 55 21 220 36 38
Telex: 2121968 PEPR BR
France
RADIALL
101, Rue Philibert Hoffmann
Zone Industrielle Ouest
93116 Rosny-sous-bois Cedex
Tel: 33 1 49 35 35 35
Fax: 33 1 48 54 63 63
Telex: RADIA 235220
Italy
RADIALL Elettronica S.R.L
Via Concordia 5
I-20090 Assago Milano
Regional offices: Roma
Tel: 2 4 88 25 94
Fax: 2 4 88 43 018
Telex: 350037 EURELI
U.K.
TRANSRADIO Ltd.
10, Perivale Industrial Park
Horsenden Lane South, Perivale
Middlesex UB6 7RL
Tel: 819 978 880
Fax: 819 970 116
Telex: 923004
1210
Notes:
Chapter
13

Use this chapter as a guide when you install a ControlNet repeater
(cat. nos. 1786-RPT, -RPTD). This chapter contains these sections:
Section
About The Repeater
Page
132
Preparing For Installation
133
European Union Directive Compliance
133
Mounting The Repeater
135
Grounding The Repeater
136
Connecting Power And Relay Circuitry (optional)
137
Connecting The Repeater To Your ControlNet Segments
139
Front-panel Controls
1310
Troubleshooting
1311
Agency Compliance
1312
Specifications
1312
132
Installing The ControlNet Coax Repeater
About The Repeater
The repeater is a device used to increase the number of nodes, extend

the total length of your segment, or create a star or tree configuration
(go off in multiple directions from one point). The number of
repeaters you can use depends on your network topology.
Use a repeater in your ControlNet cable system to connect segments
together to form links.
segment 1
repeater
segment 2
"
For more information (including redundant cable systems), refer to

Chapters 712.
The repeater provides:
an internal power supply
For this input power:
85 to 250V ac or 110 to 250V dc
Use this repeater:

1786-RPT
20 to 72V dc
1786-RPTD
For more specifications, see page 1312.
a fuse (replaceable) for over-current protection

two indicators for status and troubleshooting
a fault-rely contact for status indication or switching to a
backup repeater. When wired to external circuitry, this contact
could be used to turn off a light or activate a backup repeater.
When the repeater is:
This contact:
working properly
will be held closed
not working properly (or a loss of power occurs)
will open
133
This diagram shows a possible configuration for powering a backup repeater

in your ControlNet network. In this diagram, the backup repeater will be
activated when the primary repeater is faulted.
power (ac or dc)
primary
repeater
contact
CR1
neutral
to backup
repeater
power (ac or dc)

CR1-1
ATTENTION: Do not power both repeaters at the
same time. Powering both repeaters at the same time

disrupts communication on the network. Use the fault-relay
contact of the primary repeater to control power to the
backup repeater.
Preparing For Installation
Before installing a repeater, you should have determined where the

repeater will be installed. See Chapters 712, if you have not
determined repeater placement.
European Union Directive

Compliance
The series B version of this product is marked with the
logo,
indicating that this version complies with the European Union

Directives noted below.
If this product is installed within the European Union or EEA
regions and has the CE mark, the following regulations apply.
EMC Directive
The repeater is tested to meet Council Directive 89/336
Electromagnetic Compatibility (EMC) using a technical construction
file and the following standards, in whole or in part:
EN 50081-2 EMC Generic Emission Standard,
Part 2 Industrial Environment
EN 50082-2 EMC Generic Immunity Standard,
Part 2 Industrial Environment
The repeater described in this chapter is intended for use in an
industrial environment.
134
Low Voltage Directive

The repeater is also designed to meet Council Directive 73/23 Low
Voltage, by applying the safety requirements of EN 611312
Programmable Controllers, Part 2 Equipment Requirements and
Tests.
For specific information that the above norm requires, see the
appropriate sections in this manual, as well as the following
Allen-Bradley publications:
Industrial Automation Wiring and Grounding Guidelines,
publication 1770-4.1
Guidelines for Handling Lithium Batteries, publication AG-5.4
Automation Systems Catalog, publication B111
Mounting The Repeater
135
Use the mounting dimensions provided to mount the repeater

horizontally or vertically in the area you selected.
Important: The repeater should be mounted:
so that air can flow in/out of the air holes on the top and bottom
of the repeater for proper ventilation, make sure there is a
minimum of 5.1cm (2) from surrounding equipment
in a NEMA enclosure to provide protection from dust, moisture,
or corrosive atmospheres
to a grounded metal plate if possible
38.1mm
(1.50)
9.1mm
(0.36)
8.6mm
(0.34)
19.3mm
(0.76)
9.3mm
(0.38)
215.9mm
(8.5)
196.6mm
(7.74)
197.6mm
(7.78)
12.7mm
(0.5)
50.8mm
(2.0)
101.6mm
(4.0)
136
Grounding The Repeater
Use a #14 AWG wire to connect the repeater to the ground bus.
keep this lead as

short as possible
grounding stud
star washer
nut
ground lug
20150
For additional grounding information, see the Industrial Automation

Wiring and Grounding Guidelines, publication 1770-4.1.
Connecting Power And

Relay Circuitry
137
1. Remove the terminal strip cover.
20150
2. Connect power to the repeater.
1786-RPT
1786-RPTD
L1
L2/N
(+)
()
20150
Use this grounding stud for ac power sources.
If you are using high voltage dc to power the 1786-RPT,

L1 is positive (+) and L2/N is negative ().
Using the fault relay terminals?
yes
Go to step:
3
no
For more information, see page 132.
138
3. Connect your relay circuitry to the fault relay terminals.
contact held closed

in normal operation
L1
L2/N
20150
4. Replace the terminal strip cover.
20150
Connecting The Repeater

To Your ControlNet
Segments
139

right-angle connector of the designated tap on the first segment
(segment 1).
ATTENTION: Do not allow any metal portions of
the tap to contact any conductive material. This
contact can cause noise on the network.
If you disconnect the tap from the repeater, place
the dust cap back on the straight or right-angle
connector to prevent the connector from
accidentally contacting a metallic grounded surface.
segment 1
tap
dust cap
20093-I
2. Remove and discard the dust caps from the repeaters BNC jacks.
3. Connect this taps straight or right-angle connector to the
BNC
connector on the repeater.

segment 1
To prevent inadvertent reversal of the tap
connections (resulting in incorrect indicator
displays and troubleshooting), check the tap
drop cable for a label indicating the attached
segment before making your connection.
tap
20093-I

right-angle connector of the designated tap on the second segment
(segment 2).
segment 2
tap
dust cap
20093-I
1310
5. Connect this taps straight or right-angle connector to the

segment 1
segment 2
tap
tap
20093-I
Front-panel Controls
1
2
3
20150
During operation use the:
1
2
3
To:
status indicators
determine status of the repeater.
reset switch
to reset the repeater after a fault condition.
replaceable fuse
protect the repeater from over-current conditions.
Troubleshooting
1311
Use the following tables to troubleshoot your repeater. The tables

use these terms:
steady indicator is on continuously in the defined state.
alternating the two indicators alternate between the two defined
states at the same time (applies to both indicators viewed
together). The two indicators are always in opposite states, out of
phase.
flashing the indicator alternates between the two defined states
(applies to each indicator viewed independent of the other). If
both indicators are flashing, they must flash together, in phase.
Status Indicators Under Normal Conditions

If both are:
alternately red/green
steady green
This indicates:
the repeater is being powered-up or reset. The LEDs alternately
flash red and green for about 5 seconds
normal operating mode
Status Indicators Under Fault Conditions

If both are:
off
This indicates that:

unit is not powered
Check the power line for correct voltage
Check the fuse and replace if blown
red
there is a repeater fault. To clear this state, press the reset switch.
If this does not clear the fault, replace the repeater or troubleshoot
the network
If either is:
flashing green/off
The respective segment (1 or 2) is:

experiencing temporary network errors
This situation will normally correct itself. If the situation persists,
troubleshoot your nodes and cable system. When troubleshooting
your cable system, make sure:
all BNC connector pins are properly seated
all taps are A-B taps
all terminators are 75 and are installed at both ends of all
segments
the coax cable has not been inadvertently grounded
flashing red/off
experiencing a high level of network errors. This may indicate a

broken cable, broken tap or missing segment terminator
Important: The indicators will flash red-off on a system that has no
network activity. This would be normal for a system
that has no ControlNet nodes installed or enabled
1312
Agency Compliance
The repeater has been tested and found to comply with the limits for
a Class A digital device, pursuant to part 15 of the FCC Rules.
These limits are designed to provide reasonable protection against
harmful interference in a commercial environment.
The repeater generates, uses, and can radiate radio frequency energy.
To avoid harmful interference to radio communications, observe all
installation instructions provided in this document. Operation of the
repeater in a residential area is likely to cause harmful interference;
if interference occurs, you correct the interference at your own
expense.
Important:
Specifications
Changes or modifications not expressly approved by

Allen-Bradley could void your authority to use the
repeater.
1786-RPT, -RPTD
Power
Requirements
1786-RPT
1786-RPTD
Description:
85-250V ac, 47-63Hz, 60mA maximum
110-250V dc, 25mA maximum
20-72V dc, 100mA maximum
Fault Relay Requirements
132V ac, 150mA maximum or

186V dc, 150mA maximum
Barrier Strip Conductors
#14 AWG to #22 AWG
Replacement Fuse
1/4A, 250V 3AG

2A, 250V (slow-blow)
1786-RPT
1786-RPTD
Environmental Operating Temperature

Conditions Storage Temperature
Relative Humidity
0 to 60C (32 to 140F)

-40 to 85C (-40 to 185F)
5 to 95%, noncondensing
Dimensions
see page 135
Weight
0.87kg (1.9lbs)
0.82kg (1.8lbs)
1786-RPT
1786-RPTD
Agency Certification
(when product or packaging is marked)
Class 1 Div 2 Hazardous
marked for all applicable direc
Chapter
14

Use the ControlNet Network Access cable (cat. no. 1786-CP) to
connect a programming device to any intelligent device (i.e.,
workstation, PLC processor, scanner or adapter) on ControlNet
through the network access port (
).
1786-CP
programing device
end device
trunkline A
20139
Connections
3.05m
(10)
shield
shield
GND REF
GND REF
+24V DC
+24V DC
7
PTRx_H
6
PTRx_L
5
PTTx_L
4 PTTx_H
3
+24V DC
2
GND REF
1
PTTx_H
PTTx_L
PTRx_L
1
2
3
4
PTRx_H 5
6
+24V DC
7
GND REF
8
Thi cable i not a traight-through cable.
142
Installing the ControlNet Network Access Cable
ATTENTION: Do not use the1786-CP cable to

provide more than one connection to your ControlNet
cable system; this connection could result in possible
network failures.
1786-CP
Do not use the 1786-CP cable to connect
your programming device to ControlNet
two ways simultaneously.
1786-CP
Do not use the 1786-CP cable
to connect a scanner or adapter
module to a PLC processor.
1786-CP
Do not use the 1786-CP cable to
connect two separate ControlNet
segments.
20140
For additional information on making connections to the ControlNet

network, see Chapters 712.
Chapter
15

Use this chapter as a guide when installing a ControlNet coax tap
(cat. nos. 1786-TPR, -TPS, -TPYR, -TPYS). This chapter contains
these sections:
Section
Page
Verifying Package Contents
151
Selecting Where To Mount The Tap
152
Mounting The Tap
152
Mounting Dimensions
155
Specifications
156
Important:
Verifying Package
Contents
For information on planning and installing your

ControlNet cable system, see Chapters 712.
Make sure you have these items before you discard any packing
material.
tap (1786-TPR, -TPS,

-TPYR or -TPYS)
BNC connector kits
dust cap
screws
universal mounting bracket
If an item is missing or incorrect, contact your
Allen-Bradley integrator or sales office.
152
Installing The ControlNet Coax Tap
Selecting Where To Mount

The Tap
There is no spacing requirement between taps; you can install two

adjacent taps if you need to using a barrel connector (cat. no.
1786-BNCP).
Make sure the mounting location is convenient for your cable
routing.
Make sure the mounting location does not cause any cable
bend-radii to exceed these limits:
wiring external to enclosures RG-6 type coax cable is being
pulled through multiple conduit bends:
PVC
The pull strength

should not exceed:
42.75kg (95lbs)

not exceed:
76.2mm (3.0)
FEP
61.65kg (137lbs)
69.9mm (2.75)
wiring inside enclosures RG-6 type coax cable is not being

pulled through conduit:
PVC
The bend radius should not exceed:

38.1mm (1.5)
FEP
35.6mm (1.4)
Tap drop-cable
25.4mm (1.0)
Do not mount the tap in a position that routes the dropline cable
over any ac power terminals on nearby modules.
!
Mounting The Tap
ATTENTION: Do not allow any metal portions of the

tap, such as the universal mounting bracket screws or
connectors, to contact any conductive material.
You can mount your ControlNet tap (T-tap or Y-tap):

to a universal mounting bracket, and then mount the tap and
bracket as an assembly
through the body holes in the tap using:
a tie wrap
Important:
Once you have mounted your taps, you can discard any
unused universal mounting brackets.
See page 155 for universal mounting bracket and tap mounting
dimensions.
153
Mounting a Tap using a Universal Mounting Bracket

1. Align the universal mounting bracket with the mounting holes on
the tap.
2. Using the screws provided with the tap, attach the tap to the
universal mounting bracket.
universal
mounting bracket
Y-tap
T-tap
dust cap
dust cap
3. Mount the tap and bracket assembly to:

a DIN mounting rail
or
another mounting surface
universal mounting
bracket
use four screws to attach the universal

mounting bracket to another mounting surface
mount the universal mounting

bracket on specified
Allen-Bradley mounting rails or
DIN Rails #3 style symmetrical
(3.5 x 7.5mm)
universal
mounting bracket
DIN rail
20081
Mounting Bracket Cat. No.

A-B Rail
1492-N1
suitable
fixture
Mounting Bracket Cat. No.

Din Rail #3
199-DR1
1492-N22
1492-DR5
1492-N44
1492-DR6
20082
1492-DR7
154
Mounting a Tap through the Body Holes

Mount the tap to a suitable fixture using:
tie wrap
or

screws and
flat washers
body holes
body holes
tie wrap
you can use a variety

of screw types
ATTENTION: Do not overtighten the screws.

Over tightening the screws can damage the tap.
The applied torque should be 0.2-0.4 N-m (1-2 ft-lbs).
20083
Important:
The suitable fixture can be conductive and/or grounded

because of the electrical isolation provided by these
body holes.
Mounting Dimensions
155
Taps
T-tap
Y-tap
30.23mm
(1.19)
35.56mm
(1.40)
15.24mm
(0.60)
33.02mm
1.30
15.24mm
(0.60)
25.4mm
(1.00)
39.37mm
(1.55)
31.37mm
(1.235)
20168
20169

58.42mm
(2.30)
49.53mm
(1.95)
19.05mm
(0.75)
30.94mm 19.05mm
(1.218) (0.75)
11.43mm
(0.45)
20170
156
Specifications
Operating Temperature
0 to 60C (32 to 140F)
Storage Temperature
-40 to 85C (-40 to 185F)
Relative Humidity
5 to 95% noncondensing
Chapter
16

This chapter is an implementation standard for the ControlNet Coax
Physical Layer. It contains information important to designing the
physical connection to the ControlNet network. All devices that
connect to the ControlNet network must be compatible. Use of this
standard will provide:
Repeatable duplication of the Physical Layer circuitry
Design reuse which cuts development time
Design control
Circuit descriptions are included on page 164. Since different
products or applications will have different mechanical restrictions,
artwork is not included in this chapter, but layout guidelines and
recommendations are. This chapter contains these sections:
Section
Page
The Physical Layer As A Component
162
Requirements
162
Design
164
ControlNet Physical Layer Specifications
1622
Network Access Port Cable Schematic
1624
162
ControlNet Coax Physical Layer
The Physical Layer As A

Component
The term Physical Layer as used in this chapter refers to the portion
of the Physical Layer outside of the ControlNet ASIC and includes
the coax transceiver and network access port (NAP) transceiver.
The shaded portion of Figure 16.1 shows the location of the
transceivers in the OSI stack. The ControlNet ASIC contains part of
the ControlNet Physical Layer including clock recovery, redundancy
arbitration, framing, and Manchester encoding/decoding.
Figure 16.1
OSI Stack
Application
Presentation
Session
Transport
Network
Link
Physical
Media
The primary components of the ControlNet Physical Layer are:

Redundant (or dual channel) coax transceiver hybrid
Single channel coax transceiver hybrid
Isolated network access port transceiver
Nonisolated network access port transceiver
Requirements
System
The Physical Layer is required to support connection to coax media
with network segments of up to 500 meters and allow connection of
up to 32 devices. Connection to redundant coaxial media will be
supported via standard BNC connectors. The characteristic
impedance of the coax cable is 75 Ohms. The Physical Layer is also
required to support local connection of a programming device which
will be using ControlNet protocol and data rates.
163
Functional
To support redundant coax media, two independent coax transceivers
are required which will transmit and receive the Manchester encoded
5 Mbps baseband data. The driver portion of each transceiver
obtains Tx+ and Tx signals from the ASIC, representing physical
one and zero signals, and transmits a singleended, DC isolated
signal on the cable. The complement of this function is performed in
the receiver which provides Rx and carrier detect (CD) signals to the
ASIC.
Local connection to a desktop, laptop, or handheld programming
device is supported through the NAP transceiver. The NAP
transceiver obtains a single transmit line from the ASIC, transmits to,
and receives from, another device at the other end of the NAP cable,
and provides a single receive line back to the ASIC. Note that since
these are single lines, no representation of carrier on/off is present.
These signals are either a zero or a one at all times.
Electrical Performance
For detailed electrical specifications refer to Specifications on
page 1622.
Mechanical/Implementation
Figure 16.2 represents a standard ControlNet front panel.
Figure 16.2
ControlNet Front Panel
A
B
Bicolor LEDs
NAP Connector
Coax Connector A
Coax Connector B
Although the LEDs are not part of the Physical Layer, they are
shown in the figure because they will be on the front panel and,
therefore, need to be included in the electromechanical design.
164
Design
Design Overview
A functional block diagram depicting the ControlNet Physical Layer
components is shown in Figure 16.3. (A schematic of a typical
application is shown in Chapter 45, Example Hardware
Implementation.) The two coax transceivers shown are functionally
independent, but, the actual circuitry has parts common to both.
The NAP transceiver represents both the isolated and nonisolated
implementations. The isolated NAP must be used on programming
devices. The nonisolated NAP would be used on programmed
devices.
Figure 16.3
Physical Layer Block Diagram
RxData
Rcv
RxCarrier
Isolation
Coax
Channel A
TxOut
Xmit
TxOutBar
A Channel
EnabA
Media
Connection
ASIC Interface
RxData
Rcv
RxCarrier
Isolation
TxOut
Coax
Channel B
Xmit
TxOutBar
B Channel
EnabB
Opto
/RxNAP
Isolation
(option)
Rcv
NAP
Opto
/TxNAP
Isolation
(option)
Xmit
EnabNAP
NAP Channel
165
Coax Driver
The following pages describe the Coax Driver:
Section
Page
Simplified Model
below
Interfaces
166
Circuit Description
166
Simplified Model
In the Physical Layer Block Diagram, the blocks labeled Xmit and
isolation combine to represent the coax driver. Figure 16.4 shows
a simplified functional diagram of the coax driver.
Figure 16.4
Simplified Coax Driver
Tx+ = 1
(physical one)
5V
Tx = 1
(physical zero)
The switches shown indicate four states for the powered driver.
When both are open, or off, no signal is presented to the cable.
A physical one is presented to the cable when Tx+ is closed, or on,
and Tx is open, or off. A physical zero is presented to the cable
when Tx+is open and Tx is closed. The state of both switches
closed should never be used.
166
Interfaces
Two signals come from the ControlNet ASIC for controlling
transmission on each channel. These signals are called TxDataOutX
and TxDataBarX, where the X is either A or B and denotes the
channel. These two data signals, when connected to Tx+ and Tx,
define the physical symbols on the wire. There is also an enable line
for the coax driver.
Table 16.A defines the relationship between the coax transceiver
control lines and the data on the wire.
Table 16.A
Transmit Control Line Definitions
TxOut
TxOutBar
Enab
Physical Symbol
Signal on Media
none
none
none
none
+ Voltage
Voltage
not allowed
Not allowed
This state could result in damage to the driver circuitry.
Circuit Description
The coax driver is made up of a CMOS predriver pair, transistor
driver pair, and the transformer. The series Schottky diodes and over
voltage diodes will be discussed later in this section.
The predriver pair is 1/2 of a 74ACT08. This device allows the
combination of the data and enable signals and provides the base
drive required by the drive transistors.
The transistor driver uses a pair of MMBT2369 transistors. These
are high speed switches selected for their performance.
The series base resistors define the required base drive and the shunt
base resistors reduce turn off time. The base capacitors provide slew
rate limiting which improves radiated emissions slightly.
The transformer couples the transmit signal to the media. Each side
of the driver pair controls one side of the center tapped transformer,
such that the driver operates in a push pull configuration. The
voltage presented to each side of the driver is 4.2 typical (at
Vcc=5V) and 4.7 maximum (at Vcc=5.5V). This corresponds to a
peak driver output current (into 37.5 Ohms) of about 110 mA typical
and about 125 mA maximum. The total peak supply current then
including the base drive is about 140 mA.
167
Coax Receiver
The following pages describe the Coax Receiver:
Section
Page
Simplified Model
below
Interfaces
168
Circuit Description
168
Simplified Model
Shown below is a simple block diagram of the receiver with example
waveforms to describe its operation. Two high-speed differential
line receivers are used to detect data and to generate carrier detect.
Since the data signals are equal magnitude and opposite polarity, the
receive data threshold is set for zero volts. The CD threshold is set
slightly higher (about 140 mV) to provide between packet noise
immunity.
Figure 16.5
Simplified Receiver
Rx +
Rx
Rx
CD
V th
V th
Rx
CD
168
Interfaces
Two signals are provided to the ASIC from the Physical Layer; data
and carrier detect. These are connected to the ASIC RxDataX and
RxCarrierX pins respectively where X is the channel. Table 16.B
shows the relationship between the signal voltage on the wire and the
two receiver outputs for nominal thresholds.
Table 16.B
Receiver Output Definitions
Input Voltage at BNC
Rx Data
Rx Carrier
Vin < 140
140 mV< Vin < 45 mV
undefined
45 mV< Vin < 140 mV
undefined
undefined
140 mV< Vin <510mV
undefined
510mV< Vin
(all voltages are PP )
Circuit Description
The receiver circuitry is conceptually simple. The complexity arises
in controlling the detection thresholds. Below is a schematic reduced
to include just the important components of the Rx data detector.
Figure 16.6
Rx Data Detector
5V
coax connector
Rx Carrier
+
differential comparator
isolation
transformer
Rx Data
169
The device selected for the detector is a 26LS32A (quad receiver).

The key specs then for this device are:
High input impedance: 15K Ohms typical, 12K Ohms minimum
Low worst case threshold voltages:+/ 100 mV over a common
mode range of 0 to 5.5 V
SMT packaging
0 to 85o C temperature range
Single 5V supply
+/ 10% supply tolerance
Fast enough to handle the Manchester encoded 5Mbps data rate
The series resistors on the input to the 26LS32A are different in
value to counteract the threshold offset caused by the 26LS32As fail
safe resistors.
Carrier detection uses another of the receivers in the 26LS32A.
It performs a single-ended comparison of the input signal to a DC
threshold, as shown in the simplified schematic in Figure 16.7.
Figure 16.7
Rx Carrier Detection
5V
Rx Carrier
+
The CD signal looks just like the data signal at high signals. At low
signal levels it looks similar, except that the CD one pulse widths
are more narrow than those of the data. When no signal is present
the CD output is low, unlike the data which is undefined and could
be changing state with noise.
1610
Media Coupling
This section discusses how the driver and receiver are connected to
the cable and what measures are taken to protect the transceiver from
conditions on the media, and, to protect the media from conditions
on the transceiver. This section includes information on:
transformer coupling
over voltage diodes
Schottky diodes
cable loading
Transformer
Transformer Coupling was selected to provide ground isolation.
This prevents low frequency signal paths from developing through
the communication equipment. A number of alternatives were
considered for the transformer design. Following are parameters
which were deemed important to the design:
Small size
Low cost
High terminal impedance
Wide band width
Low loss
Reliability
Over Voltage Diodes
To prevent fast, high voltage transients from exceeding component
ratings, zener diodes are included to limit the upper and lower
voltage excursions. Small signal diodes are placed in series with the
zeners to reduce the capacitive loading from the zeners and to allow
each zener to protect both sides of the differential lines.
1611
Schottky Diodes
Without Schottky diodes, when the transceiver power is turned off, a
low impedance is presented to the transformer, and therefore, to the
cable. This low impedance is from the series combination of the
drive transistor basecollector junction, the base resistor to ground,
and the cumulative load from 5 V to ground. The solution is to place
a diode in this path opposite in polarity to the driver basecollector
junction.
Also, if the negative voltage zener clamp was replaced with just a
small signal diode clamp to ground, this small signal diode would
also load the transformer. One solution to this problem is to put the
diode in the center tap, using just one part to take care of both sides
of the driver. This solution will not work in this case because the
receiver is on the same winding, producing a lower resistance. This
resistance turns on the driver basecollector junction, producing a
low dynamic impedance. The impedance it presents to the
transformer parametrically drops with increasing signal level.
The alternative solution is diodes in series with each transistor
collector. Low forward voltage Schottky diodes were used to keep
transmit losses to a minimum.
Cable Loading
One of the most important jobs for the transceiver is to load the cable
as little as possible. This fact is pervasive throughout this design
description. A number of references to loading have been made,
including:
low capacitance on the driver outputs
high impedance on the transformer
small signal diodes in series with the zener diodes to reduce
capacitance
diodes in series with the driver outputs to prevent loading when
power is off
high input impedance on the receiver
1612
There is a direct relationship between network size and transceiver

load. Rather than specify all of these parameters, a single measure of
performance has become a standard for loading. Tap through loss is
a direct determining factor for system dynamic range.
The measurement set up is shown in Figure 16.8. Any design should
have a loss less than 0.2 dB under nominal powered conditions with
tolerances no worse than documented in the referenced report.
Figure 16.8
Tap loss measurement
Network
Analyzer
1
2
50/75 Ohm
Pads
1 meter
Tap
Xcvr
RG62
Network Access Port (NAP)

Included in this description of the NAP are these sections:
Section
Page
User Requirements
below
Technical Requirements
1616
NAP Support On The ASIC
1618
Circuit Description
1618
Ground Isolation Requirement
1619
ATPT Design
1619
NAP Cable Requirements
1619
Specifications
1620
User Requirements
This section contains requirements which were used as the basis for
the network access port design. Described are the expected uses and
applications of network access ports for the ControlNet network.
It is necessary to access network devices for programming purposes
through the use of a programming terminal (PT). PTs can be
desktop, laptop portable, or handheld units like those currently
offered by Allen-Bradley. The term HHPT is used in this chapter to
describe any handheld PT. The term ATPT is used to describe any
computer-based PT, including laptop and desktop units. The AT
reference also includes any non-AT platform which might be used,
such as EISA, PCI, or PC card.
1613
The HHPT functions are a subset of those available on a ATPT, and

are intended for use by shop-floor personnel, such as electricians or
technicians. The ATPT is used for more complicated functions, such
as uploads, downloads, network management functions, or
operations requiring display of multiple rungs of ladder logic.
One use of the PT is during system installation or network
commissioning when the initial setting of operational parameters
occurs. Settings can be made which have in the past been switch
selectable, including operating mode, address, or logical
configuration. After installation, the PT can be used for diagnostics,
monitoring, and changes on the network, processes or programming.
Two methods of attachment are required for PTs. Requirements exist
for a permanent redundant coax connection or tapped connection
of the ATPT to the network and for a temporary, or local,
connection (via the NAP), of the ATPT or HHPT, to a controller or
I/O device, or node.
The local connection, as shown in Figure 16.9, must allow
programming of the locally attached node, or local programming.
In addition, the local connection must allow monitoring and control
of programs in other nodes, or remote programming, while still
allowing the user to be physically close to the controlled process.
The alternative to this local connection is to distribute unused taps
throughout the network. This was deemed to be a costly and
inefficient use of the network. The tapped connection is required
for situations where there is no controller or I/O device present at the
ATPT. An example of this might be a network managers office.
Figure 16.10 shows both the local and tapped connection for the
ATPT.
1614
Figure 16.9
Local Programming
Programming
Direction
Node
ATPT
Programming
Direction
Node
HHPT
Figure 16.10
Remote Programming using ATPT
Programming
Direction
Node
ATPT
Programming
Direction
Node
Node
ATPT
1615
Some HHPT designs will be self-powered; others will require power

from the local node. The ATPT will be self-powered. The ATPT
using a tapped connection may have a HHPT plugged into its NAP .
The ATPT, in this case, will appear as a local node to the HHPT and
needs to provide power, if required, to the HHPT. Figure 16.11
shows this connection of the HHPT to the ATPT.
Figure 16.11
Remote Programming using HHPT
Programming
Direction
Node
Node
HHPT
Programming
Direction
ATPT
Node
HHPT
Table 16.C shows the relationship between the three types of devices
and the requirements of each.
Table 16.C
Device Definitions
Description of Requirement
Gets programmed
Node
ATPT
Does programming
Supports local connection (NAP)
Supports tapped connection (coax port)
HHPT
1616
The NAP connection to the network should maintain the ControlNet

common look and feel requirement. The permanent tapped
connection and temporary local NAP connection should look
identical to any other ControlNet network connection. This rule
applies to both ControlNet nodes and network access port
equipment. An exception to this rule would be made for the
hand-held network access port which would not be required to
support a coax connection to the ControlNet network; it would only
support a local NAP connection.
The circuitry required in each node to support a NAP connection
should be minimized to keep the node cost as low as possible.
Where possible, cost should be transferred from the ControlNet node
to the PT equipment. Since the number of ControlNet nodes in a
typical system should exceed the number of programming devices,
this requirement should minimize the total system cost to the
customer.
Technical Requirements
To satisfy the user requirements discussed in User Requirements, a
number of design requirements are imposed upon the network
device.
The ATPT should have a standard connection to the network on
redundant coaxial media through conventional taps. The ATPT
would have to meet all media specifications, including drop
length, loading, and all other pertinent electrical, mechanical, and
environmental specifications. The HHPT is not expected to
support a coax connection.
In addition, the ATPT and the HHPT should have a connection to
the network through a local port on any node. This connection is
to be separate and independent of the nodes normal connection to
the network, for fiber as well as coax media. Data from the
network must reach the PT from either channel in a redundant
system.
The local connection needs to reach a NAP through a 10 foot
cable.
The local connection is not to cause any abnormal network
activity under the following conditions:
connection or disconnection at the network device
connection or disconnection at the NAP
power on or off on the NAP
1617
Abnormal means that these conditions should not cause any

communication errors on the network, except those created by
disconnection during transmission from the NAP.
The local connection should not compromise network
performance. In particular, it must not reduce the distance and
number of nodes on the network in order to allow local NAP
connections.
The local programming connection is part of the common look
and feel of the network and should be used on all network
devices.
Information coming from the node must be provided to both the
standard coax transceivers and the NAP transceiver.
The following items are exclusions for the NAP connection:
Only a PT can be connected to a node through the NAP.
A PT cannot be connected to another PT, and a node cannot be
connected to another node. The exception to this rule is the
ATPT which has a redundant coax connection. If the ATPT is
connected to the network via a tapped connection, it should be
capable of supporting a HHPT connected to its NAP. This
configuration is shown at the bottom of Figure 16.11.
The local NAP connection cannot be used at the same time as the
standard tapped coax connection on the ATPT. The standard coax
transceiver will be disabled when the ATPT is locally connected
to a node via the NAP as indicated in Figure 16.12.
Figure 16.12
Multiple Connections on the ATPT
Node
ATPT
1618
NAP Support on the ASIC

The following is a list of advantages obtained by embedding the
NAP communications circuitry in the ASIC chip:
The use of the arbiter in the ASIC provides the necessary
redundancy support. Without arbitration at the node, both
channels would have to be routed to the NAP. This saves a driver
at the node, a receiver at the PT, and a pair of wires between.
The addition of clock recovery on the NAP in the ASIC
eliminates the added jitter from the channel. Without clock
recovery the added jitter will impact the maximum network size.
The ASIC port provides network-media independence.
The ASIC will act as a three port repeater. Each of the ports, the
host, the network, and the NAP, send information to the other two.
The ASIC chip provides a single pin for PT Tx data and a single pin
for PT Rx data. The PT Tx pin on the ASIC is always driven.
It does not incorporate a Tx Off state, and the ASIC does not
provide a PT Tx Off or Tx Enable pin. This requires the PT
communications channel to have separate wires for Tx data and Rx
data. Therefore, RS-485 type devices cannot be used as the PT link
without considerable external circuitry to disable and enable the Tx
drivers.
Circuit Description
The design of the node NAP circuitry external to the ASIC,
as shown in the schematic in Chapter 47, Example Hardware
Implementation, is relatively simple. A single driver and receiver
are required. The receiver will have an offset added to produce a
zero data state if the differential input is zero. This condition will
exist if:
the port is left open
if the differential lines are shorted together
if power is turned off at the PT
if the NAP driver is disabled
The polarity of the receive signal will be high for a data zero.
Differential RS422 transmitters and receivers will be used for noise
rejection.
Back-biased diodes are provided on the NAP driver lines to prevent
damage due to ESD discharges. ESD testing has indicated that the
drivers may be damaged if these diodes are not provided. For fiber
media, the NAP circuitry would be the same. The coax transceivers
would simply be replaced by fiber transceivers.
1619
Ground Isolation Requirement

For a PT device which derives its power from a source other than a
node, the ground reference potential on the node may be different
than that of the programming device. This could cause ground
currents to flow on the PT cable which could disrupt
communications and cause equipment damage.
ATPT Design
The design of the ATPT transceiver is the same as the design of for a
node, except that ground isolation is required. This is because the
ATPT may be used as a programming device.
NAP Cable Requirements
The NAP cable requires 8 conductors (2 TxData, 2 RxData, 2 power,
2 ground) and an overall shield. The shield is required to prevent
noise ingress and EMI radiation. Refer to the schematic on page
1624 for the exact pinout for the NAP cable.
Since the NAP connector and pin out is the same on both a node and
a PT, the cable must be built in a way which allows the correct
TxData to RxData connection. This can be accomplished be
reversing the connection on one end of the NAP cable. This
reversal will connect node pin 1 to NAP pin 8, node pin 2 to PT pin
7 and so on. In this way, the Tx_H line on the node will be
connected to the Rx_H line on the NAP, the Tx_L line on the node
will be connected to the Rx_L on the PT and so on. This special
cable will allow a PT to be connected to a node as PT equipment or
have a PT connected to it if it supports a coax cable connection.
1620
Specifications
Mechanical
Electrical
The connector which is used on both the PT and node equipment is

a shielded 8pin RJ45 type connector.
The NAP interface pin definition is listed in the table below. (You
can refer to pages 456 and 457 for schematics.) This pin
definition applies to both node and NAP equipment:
Table 16.D
Signals on Network Access Port
Connector
Pin Number
1
2
3
4
5
6
7
8
Signal Name
GND REF
24 VDC
PT TX_H
PT TX_L
PT RX_L
PT RX_H
24 VDC
GND REF
Specifications for the ASIC interfaces are defined in the ASIC specification. The
specifications for the NAP interface is summarized below. These specifications apply to
both the NAP and node equipment (except as noted) and are defined at the NAP interface
connector:
Cable
Transmitter End
Receiver End
Paired line characteristics = 100 ohms

DC Resistance = 0.0373 ohms/foot
Wire gauge = 26 (7 strands #34)
Conductors = 8
Maximum Cable Length = 10 feet
Termination Impedance = none required
Single Ended Output Level High = 2.5V min. (see DS8921 spec.)
Single Ended Output Level Low = 0.5V max. (see DS8921 spec.)
Total Transmit Jitter = +/ 5 % of a physymbol
Termination Impedance = 100 ohms +/ 10 %
Min Receive Level = 2.5 volts (pp differential)
Maximum Receiver Jitter = +/ 15 % of a physymbol
1621
Layout Guidelines
Following are several suggestions for layout which may help
performance for radiated emissions, susceptibility, and ESD.
(Refer to Chapter 45, Example Hardware Implementation, for
schematics.)
Use a chassis ground plane on both sides of the board along the
edge with the connectors.
Minimize interruptions to the plane. Make sure it extends beyond
the cable side of the transformer with a conductor between the
primary and secondary.
Keep the BNC connector, the transformer, and the shield R and C
close together so that one small opening in the plane can
accommodate all three as in Figure 16.13.
Figure 16.13
PCB Layout
1
PT connector
transformers
chassis
GND
R
C
R
C
mounting
screw to chassis
BNC connectors
TOP VIEW
Keep the chassis ground plane at least 2 mm away from signal

ground or 5V planes.
Connect the chassis conductor to chassis at one point as close to
the BNC connectors as possible.
Place the shield capacitors as close to the connector pin as
possible and, if possible, orient the cap toward the point at which
the chassis conductor is connected to the front panel.
Keep runners to the capacitor short and eliminate them if
possible.
1622
ControlNet Hybrid Transceiver

A thick film hybrid which implements redundant or single-channel
coax driver and receiver circuitry has been developed. It contains all
the circuitry required to implement a redundant or single-channel
coax transceiver minus the transformer, NAP circuits and cable
grounding network. Additional information on the transceiver hybrid
is contained on the ControlNet hybrid transceiver data sheet.
(See Chapter 40.)
ControlNet Physical Layer

Specifications
The following tables list specifications for the ControlNet physical

layer.
Table 16.E
General Characteristics
General Characteristics
Design Specification
Bit Rate
5.0 Mb/sec +/CA
Phy Symbol Rate
10 Mb/sec +/ CA
Phy Symbol Time
100nsec +/ CA
SMAC Crystal Frequency
60.0MHz
Crystal Accuracy(CA):
+/120ppm
Make Tolerance
+/50ppm
Temp. Stability
+/50ppm
Aging
+/10ppm
Osc. Stability
+/10ppm
Modulation
Baseband
Data Encoding
Manchester Biphase L
Delimiters
Run Length 2 Code Violations
Data Offset
DC Balanced
Total
Digital Sum Variation

(DSV) = +2/1
Table 16.F
Media Interface General Characteristics
Media Interface / General Characteristics
Coupling
Transformer Coupled
Communication Connector
BNC
Short Circuit
< 1 ohm for 1 sec
Gnd Isolated
1623
Table 16.G
Media Interface Transmit Characteristics
Media Interface / Transmit
Characteristics
Comments
Output Level
8.2 volts pp
into 37.5 ohm load
Output Tolerance
+/ 1.3 volts
into 37.5 ohm load
Symbol Level Variation
< +/ 450mV
peak(+) | peak() |
Output Signal Distortion
+/ 10%
overvoltage, droop, ring
Total Transmit Jitter
< 5 nsec pp
Silence Level
5 mV
Tx Turn Off
400 nsec
Output Slew Limit
< 1 V / nsec
Rise and Fall Time
< 60 nsec
10 to 90% of pp
The output level is measured at the estimated midpoint between any peaks or troughs in the top
a eform
and bottom of the waveform
Levels are a function of the actual measured output voltage
Table 16.H
Media Interface Receiver Characteristics
Media Interface / Receiver
Characteristics
min. receive level
510 mV pp
receiver hysteresis
50 mV typ
Carrier Detect Threshold
510 mV pp max
45 mV pp min
Rx Pattern Jitter
30 nsec pp max
Input overvoltage protection
+/ 12 volt
Inside of eye
Measured on media
Table 16.I
Transceiver Interface
Transceiver Interface
TxDataOut, TxDataBar
Active High (TTL)
Drive
4 mA
Tx Duty Cycle
50 +/ 2%
Rx Pattern Jitter
40 nsec pp max.
RxData
Active High (TTL)
RxCarrier
Active High (TTL)
Measured at RxData pin
1624
Network Access Port

Cable Schematic
The figure below shows the ControlNet newtork access port cable.
The NAP cable connectors are installed so that the signal lines are
reversed to allow the correct connection. This allows the equipment
to use the same pinout independent of function.
ControlNet node
8 Pin RJ45 connector
8
7
6
5
4
3
2
1
SHIELD
GND REF
+24VDC
PTRx_H
PTRx_L
PTTx_L
PTTx_H
+24VDC
GND REF
8
7
6
5
4
3
2
ControlNet
Node
8 Pin RJ45 connector

Programming Terminal or
ControlNet End Node
8
7
6
5
4
3
2
1
SHIELD
GND REF
+24VDC
PTRx_H
PTRx_L
PTTx_L
PTTx_H
+24VDC
GND REF
8
7
6
5
4
3
2
1
Programming Terminal or
ControlNet End Node
Chapter
17
ControlNet Physical And

Section
Selecting And Using LEDs
Page
Selecting And Using LEDs
171
Switches
176
Product Labeling
177
General Publication Guidelines
177
ControlNet Terminology
179
LEDs help maintenance personnel to quickly identify a faulted unit.

This is accomplished through the consistent placement and
presentation of indicators on ControlNet products.
General Use of LEDs

Maintenance personnel should not need technical documentation to
interpret the meaning of visible indicators. Their use and meaning
must be intuitively obvious and consistent with all other
ControlNet-compliant products.
This section refers to LEDs that are visible to maintenance
personnel. Visible means that:
LEDs can be viewed without removing covers or parts from the
equipment.
LEDs can be seen in normal lighting.
Any labels and icons must be visible whether or not the LED is
illuminated.
LED Requirements
The ControlNet network requires a product to support two categories
of status LEDs and must adhere to the specifications described in this
chapter. The two categories are:
Module Status
ControlNet Status
ControlNet developers are free to have additional LEDs on their
products, if they so desire.
172
ControlNet Physical And Publication Standards
Important:
If there is a conflict between turning an LED on red

versus green, the LED should be turned on red.
Module Status LED

This bi-color (green/red) LED provides device status. It indicates
whether or not the device has power and is operating properly.
Table 17.A and Figure 17.1 define the Module Status LED states.
Table 17.A
Module Status LED
For this state:
LED is:
To indicate:
No Power
Off
There is no power applied to the

device.
Device Operational
Green
The device is operating in a normal

condition.
Device in Standby
(The Device Needs
Commissioning)
Flashing Green
The device needs commissioning due

to configuration missing, incomplete,
or incorrect.
Minor Fault
Flashing Red
Recoverable Fault
Unrecoverable Fault
Red
The device has an unrecoverable fault;

may need replacing.
Device Self Testing
Flashing Green
The device is in Self Test.
For information on LED flash rates refer to page 176.
Any LED colors or states not defined in Table 17.A are reserved and
must not be used.
For information about Module Status LED indications during
power-up, refer to page 175.
173
Figure 17.1
States of the Module Status LED
Power Off
LED Off
Power Applied
Reset From Any State
Fail
Device Self Test

Recovery executed
Pass,
Commissioning
Needed
Pass, No
Commissioning
Needed
Device in Standby State

Device Needs Commissioning
Configuration missing,
incomplete, or incorrect
Commissioned Properly
Device Operational
Needs Commissioning
Green On
Non-recoverable Error
Flashing Green
Unrecoverable Fault
Fail, Non-recoverable Error
Red On
From Any State
Recoverable Fault
Flashing Red
ControlNet Status LEDs

Refer to Chapter 44, CNA10 ControlNet ASIC Data Sheet,
for information about the ControlNet Status LEDs.
174
The table below describes the channel A and channel B indications:

steady indicator is on continuously in the defined state.
alternating the two indicators alternate between the two defined
states at the same time (applies to both indicators viewed
together). The two indicators are always in opposite states, out of
phase.
flashing the indicator alternates between the two defined states
(applies to each indicator viewed independent of the other).
If both indicators are flashing, they must flash together, in phase.
and
off
steady red
alternating
red/green
alternating red/off
Cause
no power
faulted unit
self-test
Action
none or power up
cycle power or reset unit
If fault persists, contact A-B
representative or distributor.
none
incorrect node
configuration
check network address and other

ControlNet configuration
parameters
off
Cause
channel disabled
Action
program network for redundant
media, if required
steady green
normal operation
none
flashing
fla
hing green
green/off
off
temporary errors
none; unit will self-correct
node is not
configured to go
on line
make sure the Configuration

Manager node is present and
working
media fault
check media for broken cables,

loose connectors, missing
terminators, etc.
no other nodes
present on
network
add other nodes to the network
incorrect network
configuration
cycle power or reset unit

If fault persists, contact A-B
representative or distributor.
or
flashing red/off
flashing red/green
The Configuration Manager node is the node responsible for distributing ControlNet
configuration data to all nodes on the network.
175
LEDs at Power Up
During power up, the hardware should turn the LEDs on to a fault
state (red). If the LED does not have a fault state, then it should be
Off. However, field I/O points should indicate a true state.
Important:
All LEDs should remain on (energized) for at least 1

second.
After completion of power up, the firmware should return the LEDs
to a normal operational state.
I/O Status LED (optional)

This bi-color (green/red) LED provides information concerning the
states of inputs and outputs. The terms inputs and outputs are
being applied loosely here.
The intent of the I/O Status LED is to inform the user whether his
device has outputs under control and whether any outputs or inputs
are active (outputs active, inputs producing, etc.) or faulted.
The LED is intended to reflect the mode/state of the inputs and
outputs, not necessarily the on/off condition of the I/O points
themselves.
Table 17.B is intended to provide guidelines governing the use of the
I/O Status LED.
The I/O Status LED should follow the flash rates defined below.
Table 17.B
I/O Status LED
For this Output
state:
LED is:
To indicate:
Outputs Inactive
Inputs Inactive
Off
All outputs are inactive.

All inputs are inactive.
Outputs Active
Green
One or more outputs are active and under

control, and no outputs are faulted.
One or more inputs are active and under
control, and no inputs are faulted.
Outputs Idle
Flashing Green
One or more outputs are idle and no

outputs are active nor faulted.
Outputs Faulted
Flashing Red
One or more outputs arefaulted, maybe

in the fault state.
One or more inputs arefaulted, maybe in
the fault state.
Red
One or more outputs are forced off (may

be an Unrecoverable Fault).
One or more inputs has an unrecoverable
fault.
Inputs Active
Inputs Faulted
Outputs Forced Off
Input Unrecoverable
Fault
For information on LED flash rates refer to page 176.
176
LED Flash Rate

The flash rate of the LED is approximately 1 flash per second.
The LED should be on for approximately 0.5 second and off for
approximately 0.5 second. This flash rate specification only applies
to LEDs specified in this chapter.
Important:
Switches
Do not use more than one flash rate on an LED to

indicate various other states.
This section covers switches that users can change:

when integrating products
during normal product use
All switches should behave the same for the same function.
For example; all address switches for network devices should behave
the same.
Standardizing Switch Behavior

To standardize switch behavior. All switches must be live:
at all times, or
only at power turn on (PTO)
Also, they:
can be over ruled through software, or
are independent of software
These standardization issues apply only to switches on an operational
product. This means that the switch must be accessible without
removing the product from the system.
Switches Read at Power Turn On

Address switches should be read only at power turn on (PTO).
If they are changed after power turn on, a minor fault is detected and
reported as part of a background activity. Another device must
periodically check the error status. During this error status check
this device would detect the change in the address setting and report
the error before the next power cycle. The health LED then indicates
a non critical fault (flashing red). Since the switch is only read at
PTO the next power cycle may leave a part of the system
non-operational without warning. A non critical error assumes that
normal processing will continue without interruption.
177
Software Overrides
Switch software overrides are necessary for some products. In this
case the switch may be used for a factory default.
An operator must quickly determine if a switch setting is valid. If an
override condition exists, the switch must have an indication of
override (LED or other indication/legend).
Product Labeling
ControlNet devices should be labeled as follows:
Devices supporting non-redundant media

both status indicators
one labeled with icon and letter A
one unlabeled
Devices supporting redundant media

both status indicators
one labeled with shaded icon and letter B
A
A
one BNC connector,

labeled with icon and letter A
two BNC connectors:

one labeled with shaded icon and letter B
B
italicized words = optional labeling
Also, when referring to the Network Access Port (NAP)), use this
symbol:
.
General Publication
Guidelines
Observe these guidelines:
Do
trademark ControlNet the first time its used in text (no TM in
title) in the publication (add ControlNet to trademark section of
your document)
use the terminology defined substitutions will only confuse
users and translators
make sure you order installation tasks in the order they should be
performed (RIO tasks first, followed by DH+ and ControlNet
tasks)
178
Do not
discuss cable system requirements, refer to Chapters 7-11
use ControlNet as a noun as a trademark it is an adjective that
should be followed by a noun (i.e., ControlNet network,
ControlNet messaging, ControlNet link)
abbreviate the word ControlNet (CNet, CN, etc.)
refer to channel A and channel B connections as main/primary
and redundant; both channels are equal and offer the user the best
signal
refer to a redundant network
ControlNet Terminology
Use this term:
179
To describe:
Configuration Manager node
node responsible for distributing ControlNet configuration

data to all nodes on the network (this replaces keeper)
ControlNet network
a communication architecture that allows the exchange
of messages between Allen-Bradley Company, Inc.
products and certified third-party products.
connection
an opened communication path between two nodes on a
ControlNet network
ControlNet status indicators
channel A and channel B indicators on your node
indicating status on the ControlNet link (this replaces
LED and comm A and comm B or channel 1A and
channel 1B).
DF1 protocol
a peer-to-peer link-layer protocol that combines features
of ANSI X3.28-1976 specification subcategories D1 (data
transparency) and F1 (two-way simultaneous
transmission with embedded responses).
discrete I/O data transfer
type of data transfer in which single units of I/O have
discrete relationships with values in the processors data
table; uses the processors input- and output-image
tables (I and O files); configured on a per-node basis in
the ControlNet I/O map table
drop cable
a cable that connects a node to the trunk cable (this is an
integral part of 1786 taps).
frame
single data transfer on a ControlNet link
I/O map table
table that you configure using the programming software
to map data from an I/O chassis and other devices on
the ControlNet network to particular data-table file
addresses
link
collection of nodes with unique addresses (in the range
of 1-99). Segments connected by repeaters make up a
link; links connected by bridges make up a network (this
replaces subnet).
map-table entry
one entry in the I/O map table that you configure using
the programming software to map data from one I/O
chassis (or other device on a ControlNet link) to
particular data-table file addresses
maximum scheduled node
node with highest network address that can use
scheduled time on a ControlNet link
maximum unscheduled node node with highest network address that can use
unscheduled time on a ControlNet link
network access port (NAP)
port that provides a temporary network connection
through an RJ-45 connector (this replaces PTC).network
a series of nodes connected by some type of
communication medium. The connection paths between
any pair of nodes can include repeaters, routers, bridges
and gateways.
network address
a nodes address on the network (this replaces MAC ID
and node address).
node
port of a physical device connecting to the network which
requires a network address in order to function on the
network a link may contain a maximum of 107 nodes
(this replaces device & end device).
network update interval (NUI) single occurrence of the network update time (NUT).
network update time (NUT)
repetitive time interval in which data can be sent on the
ControlNet network (this replaces PIT and NUR).- Write out this term the first time it is used.
1710
Use this term:
To describe:
non-discrete I/O data transfer
type of data transfer in which blocks of data transferred

to or from I/O modules use integer input and output
data-table files that you specify; cannot use the
processors input- and output-image tables (I and O
files); scheduled transfers are configured in the
ControlNet I/O map table, unscheduled transfers make
use of ControlNet I/O (CIO) transfer instructions.
parallel port
an input/output port for a device that transmits multiple
data and control bits over wires connected in parallel.
PCCC
Programmable Controller Communication Commands,
an application-level command set used to communicate
across a network.
redundant media
dual cable system that allows you to receive the best
signal over a network.
repeater
two-port active physical-layer device that reconstructs
and retransmits all traffic it hears on one segment to
another segment.
remote I/O link
a serial link for carrying I/O data between a PLC or SLC
processor/scanner and remote I/O adapters.
RS-232-C port
a serial port that complies with accepted industry
standard for serial binary communication circuits in a
point-to-point link.
scheduled transfers
deterministic and repeatable transfers that are
continuous and asynchronous to the ladder-logic
program scan
segment
trunk-cable sections connected via taps with terminators
at each end; a segment does not include repeaters.
serial port
a port that transmits/receives data and control bits
sequentially over a single transmission line (see
RS-232-C port).
tap
a component that connects products to the ControlNet
trunk cable. A tap is required for each node and for both
sides of each repeater.
terminator
a 75-ohm resistor (mounted in a BNC plug) placed on the
ends of segments to prevent reflections from occurring at
the ends of cables.
trunk cable
bus or central part of a cable system.
trunk-cable section
length of trunk cable between any two taps.
unscheduled transfers
non-deterministic data transfers through ladder-initiated
communication or programming devices
- Write out this term the first time it is used.
Chapter
18

This chapter covers the management, definition, syntactic
representation and transmission encoding rules of data. This chapter
contains these sections:
Section
Page
Related Documents
182
Definitions
182
Compliance
183
Data Type Specification
184
Data Type Values
184
Operations
187
IEC 1131-3 Compliance
188
Abstract Syntax Specification
1814
Data Type Specification/Dictionaries
1818
Transfer Syntax: Compact Encoding
1821
Encoding Rules and Examples
1822
Array Encoding
1827
Structure Encoding
1829
This chapter specifies the ranges of values and defined operations for
the data types to be used in standards and compliant functional units.
These include the data types and associated operations specified in
IEC 1131-3 (Programmable Controller Languages), as well as
standard extensions. Means are also defined for the specification of
additional data types and associated operations as necessary for
standards and compliant functional units.
IEC 1131-3 specifies additional documentation and compliance
requirements beyond those defined in this chapter, which apply only
to data types. Read and understand IEC 1131-3, when applying this
chapter.
182
ControlNet Data Management
Related Documents
The following documents contain information related to this chapter.

These documents may have later editions available. Use the most
recent editions of these documents:
IEC DIS 1131-3, Programmable controllers, Part 3 Programming languages
IEC TC65/WG6(WD)1, Function Blocks - Working Draft
Outline, March 1992
IEEE 754-1985, Standard for Binary Floating-Point Arithmetic
ISO/AFNOR, Dictionary of Computer Science, 1989, ISBN
2-12-4869111-6
ISO 3307-1975, Information interchange - Representations of
time of the day
ISO/IEC DIS 10646-1.2 (1992), Information technology Universal Multiple-Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane
IEC 559 Binary Floating-Point Arithmetic for Microprocessor
Systems, 1989
ISO 646-1973(E), 7-bit coded character set for information
processing interchange
ISO 8824-1990, Information processing systems - Open Systems
Interconnection- Specification of Abstract Syntax Notation One
(ASN.1)
ISO 8825-1990 Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1)
Definitions
The definitions given in IEC 1131-3 (PLC Languages) apply to this

chapter. Key terms from the ISO/AFNOR Dictionary of Computer
Science which apply in this chapter are listed below. See the
Dictionary of Computer Science for additional terms not defined
here:
data type: A set of values together with a set of permitted
operations.
functional unit: An entity of hardware and/or software capable
of accomplishing a specified purpose.
The definitions given in the following documents apply to this
chapter:
ISO 8824 and 8825 (ASN.1)
IEC 1131-3 (PLC Languages)
Compliance
183
All components of the system must comply with this chapter on all
data management issues. This ensures interoperability between
system components.
Standards
Any standard which defines data types in addition to those defined in
this chapter must use the extension mechanisms defined in this
chapter.
Functional Units
To comply with the provisions of this chapter, the specification of a
compliant functional unit must contain the following information:
a list of the data types defined in clause 2 of this chapter which

are supported by the functional unit;
definitions of additional data types supported by the functional
unit, using the syntax and semantics specified in subclauses B.1.3
and B.1.5.2 of IEC 1131-3;
a list of the mechanisms specified in subclauses 2.3.3 and 2.5.2.2
of IEC 1131-3 for user-defined data types which are supported by
the functional unit.
This documentation should follow the format given in this chapter.
Abstract Syntax
To comply with the provisions of this chapter, the specification of a
compliant functional unit contains the following information:
A list of the data types defined in Abstract Syntax
Specification, beginning on page 1814, which are supported by
the functional unit;
Definitions of additional data types supported by the functional
unit, in the format specified in Abstract Syntax Specification,
beginning on page 1814;
A statement of which (if any) of the mechanisms specified in
Abstract Syntax Specification, beginning on page 1814, for
user-defined data types are supported by the functional unit;
184
Data Type Specification
This section describes the data type specification syntax, data type
value ranges and operations that can be performed on the defined
data types. Included in this section are:
Data Type Specifications
Abstract Syntax Specification
ControlNet Transfer Syntax/Application Layer Encoding Rules
The specification of a data type comprises:
the range of values that variables of the type may take on, and
the operations performed on these variables
This chapter specifies elementary and derived data types
corresponding to IEC 1131-3. Also, because the function blocks
defined in IEC 1131-3 have both an associated data structure and a
set of defined standard operations, these elements are also specified
as data types in this chapter.
Data Type Values
Data is made up of elementary (primitive) data types. These

elementary data types are used to construct derived (constructed)
data types.
Elementary data types

Refer to Table 18.A for the elementary data types and the values
(range) of variables of each type. This table specifies the values of
certain parameters which are identified as
implementation-dependent in Table 10.1 of subclause 2.3.1 in IEC
1131-3.
185
Table 18.A
Elementary Data Types
Keyword
Range
Description
Minimum
Maximum
BOOL
Boolean
NOTE 1
SINT
Short Integer
-128
127
INT
Integer
-32768
32767
DINT
Double Integer
-231
231-1
LINT
Long Integer
-263
263-1
USINT
Unsigned Short Integer
255
UINT
Unsigned Integer
65536
UDINT
Unsigned Double Integer
232-1
ULINT
REAL
Unsigned Long Integer

Floating point
0
NOTE 2
264-1
LREAL
Long float
NOTE 3
ITIME
Duration (short)
NOTE 13
TIME
Duration
NOTE 4
FTIME
Duration (high resolution)
NOTE 5,6
LTIME
Duration (long)
NOTE 6,7
DATE
Date only
NOTE 8
TIME_OF_DAY or TOD
Time of day
NOTE 9
DATE_AND_TIME or DT
Date and time of day
NOTE 10
STRING1
STRING2
8-bit character string

16-bit character string
NOTE 11
NOTE 6,11
STRINGN
BYTE
WORD
DWORD
LWORD
N-bit character string

8-bit string
16-bit string
32-bit string
64-bit string
NOTE 6,11
NOTE 12
NOTE 12
NOTE 12
NOTE 12
The possible values of variables of type BOOL 0 and 1, corresponding to the keywords FALSE and TRUE, respectively
The range of values for variables of type REAL are defined in IEEE 754 for the basic single floating-point format.
3 The range of values for variables of type LREAL are defined in IEEE 754 for the basic double floating-point format.
4 The range of values for variables of type TIME is the same as for variables of type DINT, representing the time
duration in milliseconds, i.e., a range of T#-24d20h31m23s648ms to T#24d20h31m23s647ms.
5 The range of values for variables of type FTIME is the same as for variables of type DINT, representing the time
duration in microseconds, i.e., a range of T#-35m47s483.648ms to T#35m47s483.647ms.
6 This is a standard extension to IEC 1131-3.
7 The range of values for variables of type LTIME is the same as for variables of type LINT, representing the time
duration in microseconds, i.e., a range of T#-106751991d4h0m54s775.808ms to T#-106751991d4h0m54s775.807ms.
8 The range of values for variables of type DATE is from D#1984-01-01, as specified in subclause 7.6.1 of ISO 9506/2
(MMS), to D#2163-06-06 (a total range of 65536 days).
9 The range of values for variables of type TIME_OF_DAY is from TOD#00:00:00.000 to TOD#23:59:59.999 to a
resolution of 1 millisecond.
10 The range of values for variables of type DATE_AND_TIME is from DT#1984-01-01-00:00:00.000 to DT#2163-06-06-23:59:59.999.
11 String data types are defined below.
12 Values of bit string data types is in the range 2#b b ...b b b , where N is the number of bits in the bit string,
N-1 N-2 2 1 0
bN-1 is the most significant bit, and b0 is the least significant bit. The value of the j-th bit bj is represented as 0 or 1,
corresponding to the Boolean value FALSE or TRUE, respectively.
13 The range of values for variables of type ITIME is the same as for variables of type INT, representing the time
duration in milliseconds, i.e., a range of T#-32s768ms to T#32s767ms.
2
186
Derived Data Types

The derived data types specified are:
directly derived
enumerated
subrange
structured
array
These data types are defined in subclauses 1.3 and 2.3.3 of IEC
1131-3. The means of specifying these data types and their default
initial values is defined in subclauses 2.3.3.1 and 2.3.3.2 of IEC
1131-3. The use of variables of these data types is defined in
subclause 2.3.3.3 of IEC 1131-3.
Character String Data Types
The declaration of a variable of type STRING1 or STRING2 is
equivalent to declaring a structured data type for the variable which
allocates a UINT variable containing the current size of the string in
characters and an array of declared character size elements.
STRING1 declares 8-bit octet elements. STRING2 declares 16-bit
octet elements.
Structured Bit String Types
Structured bit string types are an extension of the derived data type
mechanisms specified in subclause 2.2.3 of IEC 1131-3. These data
types are based on the IEC standard bit string types(ANY_BIT =
BYTE, WORD, DWORD or LWORD). Individual bits or bit range
fields of variables of these derived types can be addressed
symbolically, using the symbolic names defined in the data type
declaration. Refer to the following figure for examples of structured
bit string type declarations.
Figure 18.1
Examples of structured bit string type declarations
TYPE MOTOR_STATUS: BYTE
(running[0], ovld[1], hi_temp[2], lo_temp[3]) ;
END_TYPE
TYPE MOTOR_CMD: BYTE
(run[0], start[1], stop[2], clutch[3], speed[4-7]) ;
END_TYPE
Bit numbering is defined in Note 12 of Table 18.A
Bits which are not assigned names cannot be accessed in variables of the defined type.
187
Function Blocks
The means of specifying the data structures and operations of
function blocks are defined in subclause 2.5.2.2 of IEC 1131-3.
IEC 1131-3 Compliance, which begins on page 188 of this
document, lists the language features necessary to support this style
of specification.
Operations
The operations on data types are:

the elementary operations defined in IEC 1131-3
operations specified by the extension mechanisms defined in IEC
1131-3
Elementary Operations
The elementary operations on data types are:
Read/write access to single-element variables and to individual
elements of multi-element variables, as specified in subclauses
2.4.1 of IEC 1131-3.
IEC standard functions specified in subclause 2.5.1.5 of IEC
1131-3
The Structured Text (ST) operators defined in subclauses 3.3.1
(expression evaluation) and 3.3.2.1 (assignment) of IEC 1131-3
Operations on Function Blocks

Standard operations on function blocks are:
Read/write access to function block instance variables as
specified in subclause 2.5.2.1 of IEC 1131-3.
Function block execution control as specified in subclauses
3.3.2.2 and 4.1.3 of IEC 1131-3.
Important:
The direct association of TASKs to function blocks

(features 3b and 4b of IEC 1131-3, Table 50) is not
required by this chapter. However, additional function
block execution control mechanisms may be required in
the future by ongoing work in IEC TC65/WG6.
IEC Extended Operations

Any operations on elementary or derived data types in addition to
those specified in this chapter are specified as IEC 1131-3 compliant
functions or function blocks.
188
IEC 11313 Compliance
Subclause 1.5.1 of IEC 1131-3 defines the requirements for

programmable controller systems complying to the language
standard. This provides the data type-related information to be
included in the documentation of functional units which support the
data types defined in this chapter. Subsets or extensions of this
documentation are provided as appropriate to the specific compliant
functional unit.
This section provides information about data types and associated
operations defined in this chapter. For full compliance with IEC
1131-3, documentation of the additional language elements
supported by the functional unit must be provided as prescribed in
subclause 1.5.1 of IEC 1131-3.
Included in this section are:
Compliance Statement
Implementation-Dependent Parameters
Error Conditions
Language Extensions
Formal Syntax
189
Compliance Statement
This system complies with the requirements of IEC 1131-3 for the
following language features:
common elements
structured text (ST) language elements
Table 18.B
Common elements
Table/ Feature
Feature description
10/1
BOOL data type
10/2
SINT data type
10/3
INT data type
10/4
DINT data type
10/5
LINT data type
10/6
USINT data type
10/7
UINT data type
10/8
UDINT data type
10/9
ULINT data type
10/10
REAL data type
10/11
LREAL data type
10/12
TIME data type
10/13
DATE data type
10/14
TIME_OF_DAY or TOD data type
10/15
DATE_AND_TIME or DT data type
10/16
STRING data type
10/17
BYTE data type
10/18
WORD data type
10/19
DWORD data type
10/20
LWORD data type
12/1
Directly derived data types
12/2
Enumerated data types
12/3
Subrange data types
12/4
Array data types
12/5
Structured data types
13
Standard default initial values
Subclause
2.5.1.3
User-declared functions
(no table entry)
22/1
Type conversions
22/2
TRUNC function
22/3
BCD_TO_** functions
22/4
*_TO_BCD functions
23/1-11
Standard functions of one numeric variable:

ABS, SQRT, LN, LOG, EXP, SIN, COS, TAN, ASIN, ACOS, ATAN
24/
12n-18n
Standard named arithmetic functions:

ADD, MUL, SUB, DIV, MOD, EXPT, MOVE
1810
Table/ Feature
Feature description
24/
12s-15s,
17s,18s
Standard symbolic arithmetic functions:

+, *,-, /,
**, :=
25/1-4
Standard bit string functions: SHL, SHR, ROR, ROL
26/
5s-8s
Standard named bitwise Boolean functions:

AND, OR, XOR, NOT
26/
5s-7s
Standard symbolic bitwise Boolean functions:

&, >=1, =2k+1
27/1-4
Standard selection functions: SEL, MAX, MIN, LIMIT, MUX
28/5n-10n
Standard named comparison functions: GT, GE, EQ, LE, LT, NE
28/5s-10s
Standard symbolic comparison functions: >, >=, =, <=, <, <>
29/
1-9
Standard character string functions: LEN, LEFT, RIGHT, MID,

CONCAT, INSERT, DELETE, REPLACE, FIND
30/
1-14
Standard functions of time data types:

ADD, SUB, MUL, DIV, CONCAT,
DATE_AND_TIME_TO_TIME_OF_DAY,
TIME_OF_DAY_TO_DATE_AND_TIME
Table 30 of IEC 1131-3 limits the data types to which these operations
apply.
31/1-4
Standard functions of enumerated data types: SEL, MUX, EQ, NE
32
Standard access mechanisms to function block I/O parameters
33/8a,8b,9a,9b
User-defined function blocks per subclause 2.5.2.2,

with graphical or textual rising or falling edge input options
34/1-3
Standard bistable function blocks: SR, RS, SEMA
35/1,2
Standard edge detection function blocks: R_EDGE, F_EDGE
36/1-3
Standard counter function blocks: CTU, CTD, CTUD
37/1,2a,
3a, 4
Standard timer function blocks: TP, TON, TOF, RTC
55/
1-17
Standard operators: (), function evaluation, **,-, NOT,

*, /, MOD, +,-, <, >, <=, >=, =, <>, &, AND, XOR, OR
Table 18.C
Structured Text language elements
Table/Feature
Feature description
55/
1-17
Standard operators: (), function evaluation, **,-, NOT,

*, /, MOD, +,-, <, >, <=, >=, =, <>, &, AND, XOR, OR
56/2
Function block invocation and output usage
1811
Table 18.D
Type conversion operations
(Refer to the notes following this table.)
Operation
Result
Error conditions
ANY_BIT_TO_ANY_BIT
(NOTE 4)
None
ANY_BIT_TO_ANY_INT
OUTmin + Sbk2k (NOTE 5)
Result > OUTmax
ANY_BIT_TO_BOOL
FALSE if IN = 0
None
TRUE otherwise
ANY_BIT_TO_STRING
(NOTE 6)
None
ANY_DATE_TO_STRING
(NOTE 7)
None
ANY_INT_TO_BOOL
FALSE if IN = 0
None
TRUE otherwise
ANY_NUM_TO_ANY_
INT
IN (NOTE 8)
(IN > OUTmax) or

(IN < OUTmin)
ANY_NUM_TO_ANY_
REAL
IN
(NOTE 9)
ANY_NUM_TO_DATE
(NOTE 10)
ANY_NUM_TO_STRING
(NOTE 11)
ANY_NUM_TO_TIME
(NOTE 12)
ANY_NUM_TO_TOD
(NOTE 13)
ANY_REAL_TO_BOOL
FALSE if IN = 0.0
None
TRUE otherwise
BOOL_TO_ANY_BIT
0 if IN = FALSE
BOOL_TO_ANY_INT
1 if IN = TRUE
BOOL_TO_ANY_REAL
0.0 if IN = FALSE
None
None
1.0 if IN = TRUE
BOOL_TO_STRING
FALSE if IN = FALSE
None
TRUE if IN = TRUE
DATE_TO_ANY_NUM
(NOTE 14)
Result > OUTmax
TIME_TO_ANY_NUM
(NOTE 16)
Result > OUTmax
TOD_TO_ANY_NUM
(NOTE 17)
Result > OUTmax
STRING_TO_ANY
Converted data
(NOTE 15)
1812
Notes:
1
Use of the generic data types ANY_NUM, ANY_REAL, ANY_INT and ANY_BIT defined in subclause 2.3.2
of IEC 1131-3 is intended to imply a family of conversions. For instance, the conversion
BOOL_TO_ANY_REAL is intended to imply BOOL_TO_REAL and BOOL_TO_LREAL.
2
IN refers to the value of the input variable of the type conversion function.
OUTmin and OUTmax refer to the minimum and maximum values of the output data type of the conversion
function, as defined in Table 1
4
In conversions of bit string types, if the number of bits in the input variable IN is less than the number of
the bits in the output variable OUT, the bits of the input is copied to the corresponding least significant bits of
the result and the remainder of the result is zero-filled. If the number of bits of IN is greater than the number
of bits of OUT, the least significant bits of IN is copied to the corresponding bits of the result. For instance,
BYTE_TO_WORD(16#FF) = 16#00FF
and
WORD_TO_BYTE(16#0FF0) = 16#F0
5
Bit numbering in this expression is as specified in Note 12 of Table 1.
The result of conversion of a bit string variable to type STRING consists of a string containing the base 16
literal representation of the variable value, as defined in subclause 2.2.1 of IEC 1131-3, in characters taken
from the ISO 646 character set.
7
The result of conversion of a date and/or time of day variable to type STRING consists of a string
containing the literal representation of the variable value, as defined in subclause 2.2.1 of IEC 1131-3, in
characters taken from the ISO 646 character set.
8 Conversion of REAL and LREAL to integer types is accomplished by rounding as specified in subclause
5.4 of IEEE 754.

9
Rounding errors may occur if the number of significant bits in the input variable is larger than the number
of significant bits in the output floating-point representation. Also, range errors of the type noted for
ANY_NUM_TO_ANY_INT may occur in LREAL_TO_REAL.
10
Conversion of a variable of a numeric type to DATE has the same result as conversion of the variable to
UINT, with the result being interpreted as the number of days since 1984-01-01.
11
Conversion of a variable of a numeric type to type STRING consists of a string containing the literal
representation of the variable value, as defined in subclause 2.2.1 of IEC 1131-3, in characters taken from
the ISO 646 character set.
12
Conversion of a variable of a numeric type to TIME has the same result as conversion of the variable to
DINT, with the result being interpreted as a duration in milliseconds.
13
Conversion of a variable of a numeric type to TOD has the same result as conversion of the variable to
UDINT, with the result being interpreted as a time since midnight in milliseconds.
14 Conversion of a variable of type DATE to a numerical type is the same as the conversion of a variable of
type UINT to the corresponding numerical type, with the result being the numerical equivalent of the days
since 1984-01-01.
15 It is an error if the STRING data to be converted is not in the format for external representation of the
output data type as specified in subclause 2.2 of IEC 1131-3, or if the result of the conversion is outside the
range {OUTmin..OUTmax}.
16 Conversion of a variable of type TIME to a numerical type is the same as the conversion of a variable of
type DINT to the corresponding numerical type, with the result being the numerical equivalent of the
corresponding time interval expressed in milliseconds.
17 Conversion of a variable of type TOD (TIME_OF_DAY) to a numerical type is the same as the
conversion of a variable of type UDINT to the corresponding numerical type, with the result being the
numerical equivalent of the time since midnight expressed in milliseconds.
18 Type conversions on variables of types STRING2, ITIME, FTIME and LTIME are being considered.
1813
Implementation-dependent Parameters
Table 18.E. lists the Values of implementation-dependent
parameters from Table D.1 of IEC 1131-3. that are defined in this
chapter. Values of other implementation-dependent parameters are
defined in other standards or in the specifications of individual
functional units as appropriate.
Table 18.E
Values of implementation-dependent parameters
Clause of
IEC 1131-3
Parameter
Value
2.2.3.1
Range of values of duration
Same as LINT in microseconds
2.3.1
Range of values for variables of type

TIME
Same as DINT in milliseconds
Precision of representation of seconds

in types TIME_OF_DAY and
DATE_AND_TIME
1 millisecond
2.3.3.1
Maximum number of enumerated

values
256
2.3.3.2
Default maximum length of STRING

variables
256
Maximum allowed length of STRING

variables
65536
Maximum number of subscripts
Maximum range of subscript values
0..255
Maximum number of levels of

structures
2.5.1.5
Maximum inputs of extensible functions
2.5.1.5.1
Effects of type conversions on accuracy As defined in Table 2
2.5.1.5.2
Accuracy of functions of one variable
As defined in IEEE 754
2.5.2.3.3
PVmin, PVmax of counters
0, 65535
2.4.1.2
1814
Language Extensions
The table below lists the extensions to IEC 1131-3 defined in this
chapter. When these extensions are used in a particular compliant
functional unit, the subclause references in this table are replaced by
references to the descriptions of the corresponding extensions in the
functional units documentation.
Table 18.F
Standard extensions to IEC 1131-3
Abstract Syntax
Specification
Subclause
Description
2.1.1
ITIME data type

FTIME data type
LTIME data type
2.1.4
Structured bit string types
2.2
Operations on STRING2 variables
2.2.4.1
Numbered bit string access
2.2.4.2
Structured bit string access
The lower layers of open system architectures are concerned with the
transport of user data among distributed functional units. In these
layers, the user data is regarded as a sequence of octets. However,
application layer entities may manipulate the values of complex data
types. To achieve independence between the application layer and
lower layers, data types are specified in an abstract syntax notation.
Supplementing the abstract syntax with one or more algorithms
(called encoding rules) determines the values of the lower layer
octets which carry the application layer values. The combination of
the abstract syntax with a single set of transfer rules produces a
specific transfer syntax.
Important:
Users of this chapter should read and understand ISO

8824/8825 and IEC 1131-3. Refer to these documents
when reading and applying this chapter.
The data type definitions provided in this chapter are written in

Abstract Syntax Notation One (ASN.1), as defined in ISO 8824.
These type definitions are part of the ASN.1 module ControlNet
Data Types. The beginning ASN.1 statement indicating that these
definitions are in this module is:
ControlNetDataTypes DEFINITIONS ::= BEGIN
The closing ASN.1 statement is the keyword:

END
The abstract definitions that follow comprise the set of Data Types.
You can also extend or derive new data types based on existing
defined types, and include those in a type dictionary.
1815
Data Specification
The notation [typeId] for directly derived, enumerated, subrange and
structured bit string data means that the tag is to be taken from the
type field in the corresponding VariableDictionaryEntry.
1816
ControlNetData ::= CHOICE{ElementaryData, DerivedData}

ElementaryData::= CHOICE{
BOOL,
FixedLengthInteger,
FixedLengthReal,
AnyTime,
AnyDate,
AnyString,
FixedLengthBitString}
DerivedData::= CHOICE {
DirectlyDerivedData,
EnumeratedData,
SubrangeData,
StructuredBitStringData,
ARRAY,
STRUCT,
FunctionBlockData}
DirectlyDerivedData ::=
EnumeratedData ::=
SubrangeData ::=
[typeId] ControlNetData
[typeId] USINT
[typeId] FixedLengthInteger
StructuredBitStringData ::= [typeId] FixedLengthBitString

FixedLengthInteger ::= CHOICE {SignedInteger, UnsignedInteger}
SignedInteger ::= CHOICE {SINT, INT, DINT, LINT}
UnsignedInteger ::= CHOICE {USINT, UINT, UDINT, ULINT}
FixedLengthReal ::= CHOICE {REAL, LREAL}
AnyTime ::= CHOICE {ITIME,TIME, FTIME, LTIME}
AnyDate ::= CHOICE {DATE, TIME_OF_DAY, DATE_AND_TIME}
AnyString ::= CHOICE {STRING1, STRING2}
FixedLengthBitString::= CHOICE {BYTE, WORD, DWORD, LWORD}
BOOL
::= [PRIVATE 1] IMPLICIT BOOLEAN
SINT
::= [PRIVATE 2] IMPLICIT OCTET STRING-- 1 octet
INT
::= [PRIVATE 3] IMPLICIT OCTET STRING-- 2 octets
DINT
LINT
USINT ::= [PRIVATE 6] IMPLICIT OCTET STRING-- 1 octet

UINT
UDINT ::= [PRIVATE 8] IMPLICIT OCTET STRING-- 4 octets

ULINT ::= [PRIVATE 9] IMPLICIT OCTET STRING-- 8 octets
REAL
LREAL ::= [PRIVATE 11] IMPLICIT OCTET STRING-- 8 octets

STIME
DATE
::= [PRIVATE 12] IMPLICIT DINT

::= [PRIVATE 13] IMPLICIT UINT
TIME_OF_DAY
::= [PRIVATE 14] IMPLICIT UDINT
DATE_AND_TIME ::= [PRIVATE 15] IMPLICIT ULINT
STRING1 ::= [PRIVATE 16]

charcount
1817
IMPLICIT SEQUENCE {
UINT,
string1contents
OCTET STRING}
-- IECSTRING, one octet / character
BYTE
::= [PRIVATE 17] IMPLICIT OCTET STRING-- 1 octet
WORD
DWORD ::= [PRIVATE 19] IMPLICIT OCTET STRING-- 4 octets

LWORD ::= [PRIVATE 20]
IMPLICIT OCTET STRING-- 8 octets
STRING2 ::= [PRIVATE 21]
IMPLICIT SEQUENCE {
charcount UINT,
string2contents
OCTET STRING} --
2 octets/ character
FTIME ::= [PRIVATE 22] IMPLICIT DINT

LTIME ::= [PRIVATE 23] IMPLICIT LINT
ITIME ::= [PRIVATE 24] IMPLICIT INT
ARRAY ::= SEQUENCE OF ControlNetData
-- All of same base type
STRUCT ::= SEQUENCE OF ControlNetData -- May be different types

FunctionBlockData ::= SET{
inputs
outputs
[0] IMPLICIT STRUCT OPTIONAL,

controlInputs
controlOutputs
[3] IMPLICIT STRUCT OPTIONAL}
1818
Data Type
Specification/Dictionaries
An object is a variable specification which uses the primitive data

types defined in Abstract Syntax Specification, beginning on page
1814, and ASN.1 to build an object description. You can define
new types, built upon commonly used definitions and based on the
primitive types.
The following definition provides a basic structure for extending or
deriving new data types based on existing defined types. As new
types are added to the dictionary, these types may be referenced by a
variable specification which references the type dictionary entry.
The variable specification becomes an instance of the type dictionary
entry and is then included as a variable dictionary entry. Once the
variable specification is known, the values for the variable may be
communicated without including explicit type information with each
value.
Dictionary ::= CHOICE {VariableDictionary, TypeDictionary}

VariableDictionary ::= SEQUENCE OF VariableDictionaryEntry
VariableDictionaryEntry ::= SEQUENCE{
name
AnyString,
id
FixedLengthInteger,
type
TypeID,
ranges SEQUENCE OF Subrange,-- for arrays
accessPrivilege BOOL {READ_ONLY(0), READ_WRITE(1)}
TypeID ::= OCTET STRING-- ASN.1 encoded tag value of the
-- DataTypeSpecification module
Subrange ::= SEQUENCE {
minValue FixedLengthInteger,
maxValue FixedLengthInteger}
TypeDictionary ::= SEQUENCE OF TypeDictionaryEntry
TypeDictionaryEntry ::= SEQUENCE {
name AnyString,
type TypeID,
spec DataTypeSpecification}
1819
DataTypeSpecification ::= CHOICE {

alt
[PRIVATE 0] IMPLICIT AlternateTypeSpec,
bool [PRIVATE 1] IMPLICIT NULL, -- BOOL
sint [PRIVATE 2] IMPLICIT NULL, SINT
[PRIVATE 3] IMPLICIT NULL, INT
int
dint [PRIVATE 4] IMPLICIT NULL, DINT
lint [PRIVATE 5] IMPLICIT NULL, LINT
usint [PRIVATE 6] IMPLICIT NULL, USINT
uint [PRIVATE 7] IMPLICIT NULL, UINT
udint [PRIVATE 8] IMPLICIT NULL, UDINT
ulint [PRIVATE 9] IMPLICIT NULL, ULINT
real [PRIVATE 10] IMPLICIT NULL, REAL
lreal [PRIVATE 11] IMPLICIT NULL, LREAL
stime [PRIVATE 12] IMPLICIT NULL, STIME
date [PRIVATE 13] IMPLICIT NULL, DATE
tod
[PRIVATE 14] IMPLICIT NULL, TIME_OF_DAY
dat
[PRIVATE 15] IMPLICIT NULL, DATE_AND_TIME
str1 [PRIVATE 16] IMPLICIT NULL, STRING1
byte [PRIVATE 17] IMPLICIT NULL, BYTE
word [PRIVATE 18] IMPLICIT NULL, WORD
dword [PRIVATE 19] IMPLICIT NULL, DWORD
lword [PRIVATE 20] IMPLICIT NULL, LWORD
str2 [PRIVATE 21] IMPLICIT NULL, STRING2
ftime [PRIVATE 22] IMPLICIT NULL, FTIME
ltime [PRIVATE 23] IMPLICIT NULL, LTIME
itime [PRIVATE 24] IMPLICIT NULL, ITIME
constructedDataCHOICE {
abbrvStruc [0] IMPLICIT
AbbreviatedStrucTypeSpec,
abbrvArr
[1] IMPLICIT AbbreviatedArrayTypeSpec,
frmlStruc [2] IMPLICIT FormalStrucTypeSpec,
frmlArr
[3] IMPLICIT
FormalArrayTypeSpec,
expBitStr [4] IMPLICIT
ExpandedFixedLenBitStringTypeSpec,
[5] IMPLICIT ExpandedString1TypeSpec,
expStr1
[6] IMPLICIT ExpandedString2TypeSpec}
expStr2
}
AbbreviatedStrucTypeSpec ::= UINT
AbbreviatedArrayTypeSpec ::= DataTypeSpecification

FormalStrucTypeSpec ::= SEQUENCE OF DataTypeSpecification
FormalArrayTypeSpec ::= SEQUENCE {
lowBound
[0] IMPLICIT FixedLengthInteger, Array Lower Bound
highBound [1] IMPLICIT FixedLengthInteger, Array Upper Bound
dataType
DataTypeSpecification }
ExpandedFixedLenBitStringTypeSpec ::= SEQUENCE {
bitStrType DataTypeSpecification
BYTE, WORD, DWORD, or
LWORD
bitFields
[7] IMPLICIT BitFieldDef }
BitFieldDef ::= SEQUENCE OF {
bitDef [2] IMPLICIT OCTET STRING }
Length is always 2 octets.
First octet contains
starting
Bit Position.
Trailing
octet
contains the number of
bits.
ExpandedString1TypeSpec ::= UINT- String Length In Octets
ExpandedString2TypeSpec ::= UINT- String Length In Octets
1820
AlternateTypeSpec ::= CHOICE {

directlyDerivedTypeSpec[0] IMPLICIT TypeID,
subrangeTypeSpec
[1] IMPLICIT SubrangeTypeSpec ,
enumeratedTypeSpec
[2] IMPLICIT EnumeratedTypeSpec,
[3] IMPLICIT FBTypeSpec}
fbTypeSpec
SubrangeTypeSpec ::= SEQUENCE{
baseType TypeID,
minValue FixedLengthInteger,
maxValue FixedLengthInteger}
NOTE: minValue and maxValue
must be within the range
of baseType values
EnumeratedTypeSpec ::= SEQUENCE OF AnyString

BitNameDefintion ::= SEQUENCE {
bitName AnyString,
bitNumber USINT}
FBTypeSpec ::= SET{
inputs
[0]
outputs
[1]
controlInputs [2]
controlOutputs [3]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
FbtElementSpec OPTIONAL,
FbtElementTypeSpec OPTIONAL,
FbtElementTypeSpec OPTIONAL,
FbtElementTypeSpec OPTIONAL}
FbtElementTypeSpec ::= SEQUENCE OF ElementSpec

ElementSpec ::= SEQUENCE {
name
AnyString,
typespec ElementTypeSpec}
ElementTypeSpec ::= CHOICE {
[0] IMPLICIT TypeID,
[1] IMPLICIT SubrangeTypeSpec,
[2] IMPLICIT EnumeratedTypeSpec,
[3] IMPLICIT FormalArrayTypeSpec,
[4] IMPLICIT ExpandedString1TypeSpec,
[5] IMPLICIT ExpandedString2TypeSpec}
Transfer Syntax: Compact

Encoding
1821
This section describes the means by which the data types defined in
Abstract Syntax Specification, beginning on page 1814, are
encoded/transferred across the communication system. The abstract
syntax definition along with a particular set of encoding rules results
in a transfer syntax. For application user data, a single set of
encoding rules is defined (Compact Encoding), resulting in the
Compact transfer syntax.
Compact Encoding rules start with the encoding rules defined in
ASN.1 8825. Compact Encoding then applies optimization rules,
starting with the outer most Service Data Unit (SDU) and
progressing to each successive encapsulated SDU. Compact
Encoding defines a more efficient encoding mechanism by reducing
the amount of information (overhead) transferred between devices.
The difference between a Compact encoded value and an ASN.1
encoded value is the removal of the fields describing the type and
length of the information. In other words, the TAG and LENGTH
components of an ASN.1-encoded value are not transmitted on the
communication system. In addition, the Compact Encoding rules
indicate that octet ordering rules are the reverse of those seen in
ASN.1.
The following general rules apply to an ASN.1 encoded value for
generating a Compact encoded value. Refer to Compact Encoding
Constraints.
Remove the Identifier Octets. Remove the TAG octets
specified by ASN.1.
Remove the Length Octets. Remove the LENGTH octets
specified by ASN.1.
Reverse the byte ordering for multiple content octets.
Compact Encoding Constraints

Important:
The representation of a variable value using Compact

Encoding is only possible with the following
restrictions:
In a multi-peer communication relationship, the entities involved

in the pre-established connection have prior knowledge of the
variable type, and do not need to transmit the type description
with the value of the variable. This knowledge is available by
accessing the description of the variable and the variable type.
The variable type is fixed length and has no conditional or
optional fields.
The encoding of a given variable is represented with a constant
number of octets derived from the type specification of this
variable.
1822
Encoding Rules and

Examples
This section lists rules specific to the various data types implemented
in the system and shows examples of the Compact Encoding.
BOOL Encoding
The boolean encoding is performed on a single OCTET.
If the value is:
Then:
FALSE
bit 1 of the octet is 0 (00H)
TRUE
bit 1 of the octet is 1 (01H)
The example illustrated below shows the encoding of a BOOL

whose value is FALSE.
Table 18.G
Example Compact Encoding of a BOOL Value
Octet Number
1st
BOOL
00
SignedInteger Encoding
This section gives you examples of the Compact Encoding of SINT,
INT, DINT and LINT data values. A generic illustration of the
encoding of SignedInteger values is given below:
Octet Number
1st
2nd
3rd
4th
SINT
0LSB
INT
0LSB
1LSB
DINT
0LSB
1LSB
2LSB
3LSB
LINT
0LSB
1LSB
2LSB
3LSB
5th
6th
7th
8th
4LSB
5LSB
6LSB
7LSB
The following example illustrates the encoding of a variable of type

DINT whose value is 12345678hex.
Table 18.H
Example Compact Encoding of a SignedInteger Value
Octet Number
1st
2nd
3rd
4th
DINT
78
56
34
12
1823
UnsignedInteger Encoding
This section gives you examples of the Compact Encoding of
USINT, UINT, UDINT and ULINT data values. A generic
illustration of the encoding of UnsignedInteger values is given
below:
Octet Number
1st
2nd
3rd
4th
USINT
0LSB
UINT
0LSB
1LSB
UDINT
0LSB
1LSB
2LSB
3LSB
ULINT
0LSB
1LSB
2LSB
3LSB
5th
6th
7th
8th
4LSB
5LSB
6LSB
7LSB
The example below illustrates the encoding of a variable of type

UDINT whose value is AABBCCDDhex.
Table 18.I
Example Compact Encoding of an UnsignedInteger Value
Octet Number
1st
2nd
3rd
4th
UDINT
DD
CC
BB
AA
FixedLengthReal Encoding
This section gives you examples of the Compact Encoding of REAL
and LREAL data values. Refer to the table below for a generic
illustration of the encoding of FixedLengthReal values:
Octet Number
1st
2nd
3rd
4th
REAL
0LSB
1LSB
2LSB
3LSB
LREAL
0LSB
1LSB
2LSB
3LSB
5th
6th
7th
9th
4LSB
5LSB
6LSB
7LSB
The presentation formats defined by the ANSI/IEEE/754 standard

are:
four byte floating point value
eight byte floating point value
Figure 18.2
Format of Four Byte Floating Point Value
8
sign
REAL:
Sign:
1 bit
Exponent: 8 bits
Mantissa: 23 bits
71
exponent
71
fraction
3LSB
2LSB
81
fraction
81
fraction
1LSB
0LSB
1824
Figure 18.3
Format of Eight Byte Floating Point Value
8
71
sign
exponent
exponent
7LSB
LREAL:
Sign:
1 bit
Exponent: 11 bits
Mantissa: 52 bits
41
85
fraction
6LSB
81
fraction
81
fraction
5LSB
4LSB
81
fraction
81
fraction
3LSB
81
fraction
2LSB
81
fraction
1LSB
0LSB
In all cases the sign is encoded by using bit 8 of the most significant
byte. It is followed by the the exponent starting from bit 7 of the
most significant byte. The mantissa starts from bit 7 of the 2LSB
for simple precision and from bit 4 of the 6LSB for double precision.
The encoding of the mantissa value and the exponent value is
described in the ANSI/IEEE/754 standard.
The example below illustrates the encoding of a variable (Float1)
whose type is REAL and whose value is Float1: = 10.0.
(The assignment of the value is using the IEC 1131-3 notation.
The ASN.1 value is {41200000H} in IEEE format (1.25*23 ,
exponent is 130 (bias 127), fraction is 25)).
Table 18.J
Example Compact Encoding of a REAL Value
Octet Number
0LSB
1LSB
2LSB
3LSB
REAL
00
00
20
41
The example below illustrates the encoding of a variable (Float2)

whose type is LREAL and whose value is Float2: = -100.0. (
{C059000000000000H} in IEEE format (1.5625*26, exponent is
1029 (bias 1023), fraction is .5625)).
Table 18.K
Example Compact Encoding of a LREAL Value
Octet Contents
0LSB
1LSB
2LSB
3LSB
4LSB
5LSB
6LSB
7LSB
LREAL
00
00
00
00
00
00
59
C0
1825
AnyTime Encoding
This section gives you examples of the Compact Encoding of TIME,
DATE, TIME_OF_DAY, DATE_AND_TIME, FTIME, LTIME and
ITIME data values. Refer to the table below for a generic illustration
of the encoding of FixedLengthReal values.
Octet Number
1st
2nd
3rd
4th
5th
6th
7th
8th
TIME
0LSB
1LSB
2LSB
3LSB
DATE
0LSB
1LSB
TIME_OF_DAY
0LSB
1LSB
2LSB
3LSB
DATE_AND_TIME
0LSB
1LSB
2LSB
3LSB
4LSB
5LSB
6LSB
7LSB
FTIME
0LSB
1LSB
2LSB
3LSB
4LSB
5LSB
6LSB
7LSB
LTIME
0LSB
1LSB
2LSB
3LSB
4LSB
5LSB
6LSB
7LSB
FTIME Encoding
FTIME is a 64-bit value that represents a microsecond tick count
from any arbitrary time. Use FTIME Encoding as the data type of the
Coordinated System Time value. The example below illustrates the
encoding of a CST value of 00000000204533ABhex.
Table 18.L
Example Compact Encoding of a FTIME Value
Octet Contents
0LSB 1LSB 2LSB 3LSB 4LSB 5LSB 6LSB 7LSB
FTIME
AB
33
45
20
00
00
00
00
LTIME Encoding
LTIME is a 64-bit value that represents a microsecond tick count

relative to 0000 hr January 1, 1981. Use LTIME Encoding as the
data type of the Wall Clock Time (WCT) value. The example below
illustrates the encoding of a WCT value of 1100:30.00 hr March 10,
1994 (416142.03 x 109 microseconds or 00017A7A9DDFCF80hex
microseconds).
Table 18.M
Example Compact Encoding of a LTIME Value
Octet Contents
0LSB
1LSB
2LSB
3LSB
4LSB
5LSB
6LSB
7LSB
LTIME
80
AF
59
44
3E
7A
01
00
1826
AnyString Encoding
This section gives you examples of the Compact Encoding of
STRING1 and STRING2 data values.
Important:
The preferred string type for user supplied string data is

STRING2 because of international character string
requirements.
Following is a generic illustration of the encoding of a STRING1

value:
Contents
(charcount)
STRING1
Contents
(string1contents)
0LSB
1LSB
0LSB
1 byte character
Following is a generic illustration of the encoding of a STRING2

value:
Contents
(charcount)
Contents
(string1contents)
STRING2
0LSB
1LSB
0LSB
1LSB
2 byte character
The example below illustrates the encoding of a string variable

whose contents equal Mill. Encoding examples of all string types
are presented. Character coding is specified in ISO 10646. The
hexidecimal equivalent is: {4D696C6CH} for 8 bit encoding.
Table 18.N
Example Compact Encoding of A String1 Value
Contents
(charcount)
Contents
(string1contents)
04
4D
STRING1
00
69
6C
6C
Table 18.O
Example Compact Encoding of String2 contents
Contents
Contents
(charcount) (string2contents)
STRING2
04
00
4D
00
69
00
6C
00
6C
00
Array Encoding
1827
The array encoding uses the encoding rules for the Data types for
each element and concatenates the elements which compose the
array. The encoded values of the array elements are encoded in the
same order as they are declared in the corresponding ASN.1 type or
variable specification. These elements may be of any Data type.
Array definitions follow FIP and FieldBus standards.
The ASN.1-style definition of a single-dimensional array in a
network is:
ARRAY ::= SEQUENCE OF
{
array_dimension_low_bound,
array_dimension_high_bound,
ControlNetData
}
Assume the following array definition:

ARRAY1 ::= SEQUENCE OF {
array_dimension_low_bound := 0,
array_dimension_high_bound := 1, UINT
}
Plugging the UINT values {1,2} into this array definition yields the
following encoding:
Table 18.P
Example Compact Encoding of a Single Dimensional
ARRAY
Octet Number
1st
2nd
3rd
4th
ARRAY
01
00
02
00
The ASN.1-style definition of a two-dimensional array in a network

is:
ARRAY ::= SEQUENCE OF { array_dimension_low_bound,
SEQUENCE OF {
ControlNetData
}
}
1828
The ASN.1-style definition of a three-dimensional array in a network

is:
ARRAY ::= SEQUENCE OF {
SEQUENCE OF {
SEQUENCE OF {
ControlNetData
}
}
}
A multi-dimensional array is seen on the wire as a

single-dimensional array. The order of the array elements is
maintained via the packing/unpacking sequence followed by the end
nodes. The sequence followed is to access the Nth dimension of the
array for all values of the other dimensions.
This is achieved by:
accessing the array with all dimensions set to their initial index
values
incrementing the Nth dimension through all of its index values
incrementing the (N-1)th dimension when the end of the index
range for the Nth dimension is reached and the Nth dimension is
set to its initial index value
This process is repeated until all of the arrays dimensions have
reached the end of their index ranges. This results in the array being
packed into the message buffer as a single-dimensional array. The
same procedure is followed to unpack the single-dimensional array
into a multi-dimensional array.
The two-dimensional array shown results in the data stream below
when it is packed into a single-dimensional array following the
compact encoding rules:
ARRAY1 [0..1 , 0..2] of UINT := {
{ 1, 2, 3 },
{ 4, 5, 6 }
}
Table 18.Q
Example Compact Encoding of a Multi-Dimensional ARRAY
Octet Number
1st
2nd
3rd
4th
5th
6th
7th
8th
9th
ARRAY
01
00
02
00
03
00
04
00
05
10th 11th 12th

00
06
00
Structure Encoding
1829
The structure encoding uses the encoding rules for the data types for
each element and concatenates the elements which compose the
structure.
The encoded values of the structure elements are encoded in the
same order as they are declared in the corresponding ASN.1 type or
variable specification. These elements may be of any data type.
STRUCT ::= SEQUENCE OF ControlNetData -- May be different
types
Since Data may be comprised of either ElementaryData or
DerivedData, a new type or variable specification may be required
before transmitting the values for the STRUCT.
Assume the following structure definition:
newStruct ::= SEQUENCE { BOOL,UINT,DINT}
Plugging the values {TRUE,1234H,56789ABCH} into the

structure results in the following encoding:
Table 18.R
Example Compact Encoding of a STRUCTURE
Octet Number
newStruct
1st
01
2nd
34
3rd
12
4th
BC
5th
9A
6th
78
7th
56
1830
Examples of How More Complex Data Formats are Encoded

The examples below show how more complex data formats are
packed. Example 1 shows the packing of an array of structures.
Example 2 shows how a structure with an array element is packed.
Example 1: Encoding an Array of Structures
STRUCT1 ::= SEQUENCE OF
{
UINT
ele1;
USINT ele2;
USINT ele3;
USINT ele4;
UINT ele5
}
ARRAY1 [ 0..1 , 0..2 ] of STRUCT1 := {

{
{
{
{
{
{
{ 1, 2, 3, 4, 5 },
6, 7, 8, 9, 10 },
11, 12, 13, 14, 15 } },
{ 15, 14, 13, 12, 11 },
10, 9, 8, 7, 6 },
5, 4, 3, 2, 1 } } }
results in the following data stream:

[01][00][02][03][04][05][00] [06][00][07][08][09][0A][00]
[0B][00][0C][0D][0E][0F][00] [0F][00][0E][0D][0C][0B][00]
[0A][00][09][08][07][06][00] [05][00][04][03][02][01][00]
Example 2: Encoding a Structure with an Array Element

STRUCT2 ::= SEQUENCE OF
STRUCT2 :=
{
UINT ele1;
ARRAY [ 0..2 ] of USINT array2;
UINT ele5;
}
{
1, { 2, 3, 4 }, 5
}
results in the following data stream:

[01][00] [02][03][04] [05][00]
Chapter
19

This chapter gives you an overview of an object specification.
You can find detailed object specifications (definitions) in
Appendix A. This chapter contains these sections:
Section
Page
Where Objects Fit In The ControlNet Network
191
Terms Used In This Overview
191
Understanding An Object Specification
192
Class-specific Services
198
Where Objects Fit In The

ControlNet Network
ControlNet objects are used to model the features/behavior of a

product.
Terms Used In This

Overview
The terms defined here are used in this chapter or in Appendix A.

abstraction - The principal that any operation that achieves a
well-defined effect can be treated by its users as a single entity,
even though the operation may actually be achieved by some
sequence of lower-level operations.
attribute - Information about variable portions of an object.
Attributes may not affect the behavior of an object. For example:
the ASCII name of an object; and the repetition rate of a cyclic
object.
behavior - Specifies how an object acts. Actions are the result of
different events the object is aware of, such as receiving service
requests, detecting internal faults or timers elapsing.
class - A generalization of the object. A template for defining
variables and methods. All objects in a class are identical in form
and behavior but contain different data in their variables.
class specific service - An action performed by an object when
requested by a message. A class specific service is not on the list
of common services.
common service - An action performed by an object when
requested by a message. A common service is useful in many
objects and is listed only once on the list of common services.
192
connection point - Specifies the behavior of a connection when a
Understanding An Object
Specification
connection it is opened.
instance - A specific and real (physical) occurrence of the object.
For example: California is an instance of the class state.
message - A signal to an object requesting the receiving object to
carry out one of its services. A message consists of two parts:
the service it is to carry out and any parameters the service
requires. A reply message delivers the results of the service to
the original requestor.
object - A collection of data, services and behavior which model
a concept.
service - Operation or function that an object performs when
requested. The request and response is delivered via a message.
Each specification contained in Appendix A is defined based on the

contents of an object. An object consists of the following. Refer to
the figure below.
a set of closely related attributes (data)
a set of services (common or object specific)
a set of behaviors
a set of connections
Figure 19.1
Defining an Object Specification
Services
Services
Request
Behaviors
Response
Attributes
(Data)
Connections
Request
Response
The following table shows you each part of an object specification

and what this information means. The sections following the table
give you more detail.
This part:
Gives you:
Description
a description of the object being specified
Formal Specification
Attributes
the data associated with this object
Common Services Supported
a list of the common services defined for this object
193
This part:
Gives you:
Class Specific Services Supported
the full specifications of any services unique to this

object
Application Connections
application connections supported by this object
Behavior
the relationship between attribute values and

services
Description
Every object specification begins with a brief functional definition of
the object being defined. For example, the description of the
Device/Identity Object reads: This object is used to provide
identification and general information about the module.
Class Code
This part of the definition is a value unique to an object. Use the
class code to identify the class of object when accessing objects in
modules.
Attributes
The attribute part of an object specification is divided into two
sections:
Class attributes
Instance attributes
Class Attributes
A class attribute is an attribute that is shared by all objects within the
same class. Class attributes are defined using the following terms:
Attribute
ID
Need in
device
Access
Rule
Name
Data Type
Description of
Attribute
Semantics of
Values
194
1. Attribute ID is an integer identification value assigned to an

attribute.
2. Need in Device specifies whether or not the attribute is necessary
in the object class implementation. An attribute may be optional
or required.
Important:
If a Class Attribute is optional, then you must

define a default value or a special case
processing method for the Client to process the
error message that occurs when accessing those
objects that choose not to implement the class
attribute.
3. The Access Rule specifies how a requestor can access an

attribute. The definitions for access rules are:
Settable (Set) - The attribute is accessed by one of the
Set_Attribute services. If the behavior of your device does not
require a Set_Attribute service, then you are not required to
implement the attribute as settable.
Important:
Settable attributes are also accessed by

Get_Attribute services.
Gettable (Get) - The attribute is accessed by one of the

Get_Attribute services. It is not settable.
4. Name - refers to the attribute.
5. Data Type is used in the Get_ Attribute and Set_Attribute
services. You must follow the specified data type for all products
using the attribute being defined.
6. Description of Attribute provides general information about the
attribute.
7. Semantics of Values specifies the meaning of the value of the
attribute.
Important:
Seven Class Attributes are reserved for class object

definition. They are:
Revision
Max Instance
Number of Instances
Optional Attribute list
Optional Service list
Maximum Number Class Attributes
Maximum Number Instance Attributes
Because these attributes are reserved, attribute ID numbers 1 through
7 are always reserved. Therefore, if you want to add a class attribute
to an object definition, you must start with attribute id 8.
195
The seven reserved Class Attributes have the following definitions:

Attribute
ID
Need in
Implementation
Access
Rule
Name
Data Type
Description of Attribute
Semantics of Values
Optional*
Get
Revision
UINT
Revision of this object

Note: All class definitions are
required to include this class
attribute.
The current value assigned to

this attribute is one (1). If
updates that require an
increase in this value are
made, then the value of this
attribute increases by 1.
Optional
Get
Max Instance
UDINT
Maximum instance number of

an object currently created in
this class level of the device.
The largest instance number of

a created object at this class
hierarchy level.
Optional
Get
Number of
Instances
UDINT
Number of object instances

currently created at this class
level of the device.
The number of object

instances at this class
hierarchy level.
Optional
Get
Optional
attribute list
STRUCT of
List of optional instance

attributes used in an object
class implementation.
A list of attribute numbers

specifying the optional
attributes implemented in the
device for this class.
number
attributes
UINT
Number of attributes in the

optional attribute list.
The number of attribute

numbers in the list.
optional
attributes
ARRAY of
UINT
List of optional attribute

numbers.
The optional attribute

numbers.
Optional
service list
STRUCT of
List of optional services used

in an object class
implementation.
A list of service codes

services implemented in the
number
services
UINT
Number of services in the

optional service list.
The number of service codes

in the list.
optional
services
ARRAY of
UINT
List of optional service codes.
The optional service codes.
Optional
Get
Optional
Get
Maximum ID
Number Class
Attributes
UINT
The attribute ID number of the

last class attribute of the class
definition implemented in the
device.
Optional
Get
Maximum ID
Number
Instance
Attributes
UINT

last instance attribute of the
class definition implemented in
the device.
*If the value is 1, then this attribute is OPTIONAL in implementation. If the value is greater than 1, then this attribute is REQUIRED.
196
Instance Attributes
An Instance Attribute is an attribute that is unique to an object
instance and not shared by the object class.
Instance Attributes in Appendix A are defined in the same terms as
Class Attributes. There are no reserved Instance Attributes.
Attribute
ID
Need in
device
Access
Rule
Name
Data Type
Description of
Attribute
Semantics of
Values
Common Services
A common service is a service that is useful in many objects and is
listed only once on the list of common services. Each Common
Service has a fixed set of parameters.
The Common Service component of an object definition includes:
Service
Code
Need in
Implementation
Service Name
Description of Service
1. Service Code is the value assigned to each service.

2. Need in implementation specifies whether or not the service is
needed in the implementation of this object at the Class level.
needed in the implementation of this object at the Instance level.
One of the following appears in these columns:
Optional; or
Required; or
Not applicable (n/a)
Important:
If a service is specified optional and is implemented in a

device, you must include its service code in the
Optional Service List class attribute.
197
Services trigger the Behavior of an object based on the values of

the attributes accessed by the service. Common Services are
directed to either the Class or the Instance level of an object.
This may produce different behavior at each level.
Class Level: behavior triggered by services sent to the Object

Class.
Instance Level: behavior triggered by services sent to the
Object Instance.
Common Services sent to:
Are called:
the Class Level of an object
Common Class Level Services
the Instance Level of an object
Common Instance Level Services
4. Service Name refers to the service

5. Description of Service provides a brief definition of the service.
Get_Attributes_All Response
When the Get_Attributes_All common service is included in the list
of supported common services, the Get_Attributes_All Response
must be included in the object definition. This component specifies
the sequence or order of the data returned in the Object/service
specific reply data portion of the response.
The Get_Attributes_All response component of the object class
definition includes:
Name
Data Type
1. Name refers to the attribute.

2. Data Type specifies the data type of the attribute returned in the
response.
3. Description of Attribute gives general information about the
attribute returned in the response.
At the Class level, the order of the attributes returned in the
Object/service specific reply data portion of the
Get_Attributes_All response is lowest attribute to highest attribute of
all implemented attributes with:
required attributes first (lowest to highest); and
optional attributes last (lowest to highest)
If the Get_Attributes_All service is implemented at the Instance
level, then you must specify the order of attributes returned.
198
Set_Attributes_All Request
When the Set_Attributes_All common service is included in the list
of supported common services, then the Set_Attributes_All
Response must be included in the object definition. This component
specifies the sequence or order of the data returned in the
Object/service specific reply data portion of the response.
The Set_Attributes_All request component of the object class
definition includes:
Name
Data Type
1. Name refers to the attribute.

2. Data Type specifies the data type of the attribute returned in the
response.
3. Description of Attribute gives general information about the
attribute returned.
At the Class level, the order of the attributes passed in the
Object/service specific request data portion of the
Set_Attributes_All request is lowest attribute to highest attribute of
all implemented settable attributes with:
If the Set_Attributes_All service is implemented at the Instance
level, the order of attributes passed in the request is the same as that
for the class.
Class-specific Extensions to Common Services

Class-specific extensions to common services define additional
parameters or behavior which is unique to the class.
This section provides a list of the unique services supported by this

class of object and the associated service codes.
Whereas common services are used in many objects, object-specific
services are unique to each object class.
199
The object-specific oervices component of the object class definition

includes:
Service
Code
Need in
Implementation
Service Name
1. Service Code is the hexadecimal value assigned to each

ControlNet service.
needed in the implementation of this object at the Class and/or
Instance level. One of the following appears in these columns:
Optional
Required
Not applicable (n/a)
Important: If a service is specified optional and is implemented in a
device, its service code must be included in the
optional service list class attribute.
Services trigger the behavior of an object based on the values of the
attributes accessed by the service. Object-specific services are
directed to either the class or the instance level of an object, which
may produce different behavior at each level.
Class Level: behavior triggered by services sent to the Object
Class.
Instance Level: behavior triggered by services sent to the Object
Instance.
Common Services sent to:
Are called:
the Class Level of an object
Object-specific Class Level Services
the Instance Level of an object
Object-specific Instance Level Services
3. Service Name refers to the service.

4. Description of Service provides a brief definition of the service.
Service Parameters
Whereas each common service has fixed parameters and class
specific extensions, each object-specific service has unique
parameters. The section defines those parameters for each
object-specific service.
Name
Type
Description of
Request Parameters
Service Name
1. Name refers to the service request parameter.
1910
2. Type specifies the data type of the service request parameter.

3. Description of Request Parameters describes the purpose of the
request parameter.
4. Semantics of Values specifies the meaning of the values of the
service request parameter, such as the value is counts of
microseconds.
Service Response Data
The second table is the description of the service response data and
includes:
Name
Type
Description of
Response Data
Semantics of Values
1. Name refers to the service response data.

2. Type specifies the data type of the service response data.
3. Description of Response Data describes the purpose of the
response data.
4. Semantics of Values specifies the meaning of the values of the
service response data.
This object definition component also includes a description of the
use and purpose of the service. If the service triggers a complex
behavior, you must specify it.
Behavior
Behavior of an object may be triggered by an objects services and is
based on the values of the attributes accessed by the service.
Together, the services and attribute values initiate state changes in
the object. The behavior definition determines how an object
responds when it receives notification of an event that changes its
state.
Behavior must be defined in terms of the:
state an object is in when it receives notification of a
state-changing event
event the object receives
action performed when the event is received
State
A state is an objects current active mode of operation (for example,
Running, Idle).
1911
To define behavior in these terms, use a State Event Matrix and a

State Transition Diagram when applicable. A State Event Matrix is a
table that lists all possible events and services that initiate a state
change, and indicates an objects response to the event or service
based on the state of the object when it receives notification of that
event.
For example, the table below shows three states. Other objects may
or may not have other states.
Non-existent: the object is not yet created. You must implement
the create service to transition the object to existent.
Idle: the object accepts services (for example, Start, Stop,
Get_Attribute_Single) but does not produce.
Running: the object is performing its function.
State
Event
vent
Nonexistent
Idle
Running
Create
Transition to Idle
Error: Object
already exists.
Error: Object
already exists.
Delete
Error: Object does

not exist. (General
Error Code 0x16)
Transition to
NonExistent
Error: Object State

Conflict (General
Error Code 0x0C)
Start
Error: Object does

not exist. (General
Error Code 0x16)
Transition to
Running
Error: Object State

Conflict (General
Error Code 0x0C)
Stop
Error: Object does

not exist. (General
Error Code 0x16)
Error: Object State

Conflict (General
Error Code 0x0C)
Transition to Idle
Get_Attribute_Single
Error: Object does

not exist. (General
Error Code 0x16)
Validate/service the
request. Return
response
request. Return
response
Set_Attribute_Single
Error: Object does

not exist. (General
Error Code 0x16)
request. Return
response
Error: Object State

Conflict (General
Error Code 0x0C)
1912
Event
An event is an external stimulus that could cause a state transition.
A State Transition Diagram graphically illustrates the state of an
object and includes services, and other events and attributes that
cause it to transition to another state.
NonExistent
Create
Delete
Idle
Get_Attribute_Single/
Set_Attribute_Single/
Start
Stop
Running
Produce/Consume data, Get_Attributes_Single
When applicable, some object behavior definitions include an

Attribute Access Table, which lists all object attributes and how to
access them in a given state.
State
Attribute
Attri ute
Nonexistent
Idle
Running
Number_of_Members
Not available
Read Only
Read Only
Member_List
Not available
Read Only
Read Only
Data
Not available
Read/Write
Read Only
Owner
Not available
Read Only
Read Only
Chapter
20

To build a network connection, a path must be established from the
originating application to the target application. The path can be
chosen by the user or by a software programming tool contained in a
workstation.
In either case, the system topology must first be mapped. The user
can enter the system layout, or a tool that interrogates the system to
determine its layout can be used. Once the topology is mapped, the
tool will provide the connection path between any two devices in the
system in the form of a system address.
Section
Page
Connection Path
202
Connection ID
202
Selecting Connection IDs
203
Specifying The Path
205
Logical Address
208
Connection Path Specified By Path Segments
209
Path Segment Type
2010
Path Connection Through Bridges
2014
202
ControlNet Addressing
Connection Path
(Conn_path)
The connection path comprises both the route from the originating
device to the target device and the logical address (which specifies
the target application within the target device). The relationship
between these components is illustrated in Figure 20.1.
Figure 20.1
Components of the Connection Path
Originating
Device
Target
Device
Data
Structure
0 to N Intermediate Nodes
Intermediate
Node
Originating
Application
Data
Structure
Intermediate
Node
Target
Application
Path
Logical Address
The connection path identifies the route from the originating device
to the target device and then specifies the target application within
the target device.
Connection ID (Conn_ID)
At the network connection layer, the connection manager binds

producers, consumers, and intermediate nodes to connection IDs
(CIDs). The network connection process configures a producer to
produce data using a specific CID; intermediate nodes to forward the
data via various CIDs; and a corresponding consumer to consume the
data using the same CID as the producer (if a single-link connection)
or the last intermediate node. Once the virtual circuit or connection is
established, the routing information is set up in each intermediate
node, and the path for all packets over the circuit is fixed.
Figure 20.2
Fields of a Connection ID
MAC
Connection Number
Selecting Connection IDs
203
Connection IDs must be unique per link. To enable selecting unique

connection IDs without any interaction between devices on the link,
the connection ID is comprised of two parts: a link address, which
must be unique per link, and a device-unique number. The device
selecting the CID, which is the producer for multicast connections
and the consumer for point-to-point, always uses its own MAC
address as the link address part of the CID.
For ControlNet, the upper byte of the general CID is the MAC
address and the lower two bytes are a device-unique number; the
combination of the two yields a CID that is unique for the link.
A point-to-point network connection connects a single producer to a
single consumer, and can never be shared with another device. As a
result, the consumer determines the CID.
Since a multicast connects multiple consumers to a single producer,
the producer must determine the connection ID.
The algorithm for selecting CIDs on ControlNet is:
If the connection is:
And this device is the:
Then:
point-to-point
consumer
multicast
producer
generate a unique CID using the

node MAC
nodes
A addre
address and a de
device
ice
unique number
204
Allocating CIDs
Multicast Producer
For the multicast producer, two solutions are possible: fixing the CID
per structure and the second, rotating through a series of CIDs.
Fixing the CIDs
Each of the multicast CIDs is allocated to a fixed structure within the
device. In this way, multiple clients requesting a connection to the
same structure within the device will always get the same CID
independent of the order in which the connections are made. For
example, if an I/O module has two possible data structures to which
originators can connect, each structure is assigned a permanent CID.
And this same CID is returned any time a connection is made to the
structure.
Rotating CIDs
The second method is used by more complex devices, such as
controllers or bridges. In this method, a block of CIDs is allocated
which is at least twice as large as the number of concurrent
connections supported by the device. As connections are requested,
the CIDs are allocated in order from the block. If a connection is
closed, the freed CID is not reused until the device has rotated
through all the other CIDs. This will extend the time before a CID is
reused and will further eliminate the possibility of confusion of
CIDs.
Rotating CIDs
1
2
Unused CIDs
3
4
5
Used CIDs
Next CID assigned
The choice of which method to implement is up to the designer of

the module.
205
Point-to-Point Consumer
For the point-to-point consumer case, the rotating CID method is
used. As connections are requested, the CIDs are allocated in order.
If a connection is closed, the freed ID is not reused until the device
has rotated through all the other CIDs. This will extend the time
before a CID is reused and will further eliminate the possibility of
confusion of CIDs.
Specifying The Path
The connection path specifies both the target end node application
and the route to it.
The path information is specified using a system address. When the
path information is contained in a set of directions to be followed by
the connection, the format of the system address is the port number
and the station address on that link.
In the figure below, for example, each hop in the system is specified
by a port and station combination. The path starts at the originator
and contains a link and port for each node in the path. The
connection path is different depending on the direction for the same
route. The black and gray paths connect to the same end points, but
since they have different starting points they have different relative
paths.
Figure 20.3
System Addresses for Path Information
This device is the originator

of the connection indicated
by the solid line, and the
target of the one indicated
by the dashed line.
A
1
NOTES:
Port A or B
Station 1 to 12
Relative Path (solid): A5 B3 A7 B9 A2
Relative Path (dashed): A12 B6 A4 B2 A1
This device is the target of the

connection indicated by the
solid line, and the originator of
the one indicated by the
dashed line.
A
2
12
206
Multi-port Devices
Devices in the system can have multiple ports, as shown in Figure
20.4.
Figure 20.4
Typical ControlNet Device with Multiple Ports
backplane
Typical Device
ControlNet
ControlNet
ControlNet
A typical chassis-based communications module, or device, has at

least two ports: one for the communications network and one for the
backplane. The system address, therefore, contains the port letter
followed by the address on the selected link. For the figure above,
port B would be followed by the ControlNet node or MAC address.
The system address represents one portion of the connection path.
Each device needs to understand only the port identifiers for its own
device and the link address for the selected link. This manner of
addressing permits systems to be built which contain different types
of networks, in which each network has its own address format. An
example of a larger system incorporating different types of networks
is shown in the figure below.
207
Figure 20.5
ControlNet System Addressing in a Large Network
Incorporating Different Types of Networks
backplane
backplane
A
3
backplane
A
4
A
5
ControlNet
ControlNet
A.5.B.3.A.2
A.2.B.1.A.3.B.3.A.2
FIP
A
2
A
3
A
4
A
5
3
A.1.B.23456.A.2
A
1
A
2
A
3
A
4
23456
NOTE:
The above examples show the format of a ControlNet system address, which is
Port.link_addr.Port.link_addr.Port.link_addr ...
208
Logical Address - Internal

Object Identifier (IOI)
The logical address specifies a particular application and the

transport, producers, and consumers involved in reaching it. Each
module or device in the system can have more than one application,
and each application can have more than one transport.
Figure 20.6
Typical ControlNet Module
C
T
Output
Assembly
Instance
Connection
Manager
Input
Assembly
Instance
Device
C
P
C
T
Messaging
Network
Connection
Message
Router
C
T
Application
Some applications are associated with data produced or consumed by

the module, and some applications are associated with the messaging
function. The logical address uses the class to select the type of
application or class, and the instance to select a particular instance of
the application. Some applications or objects can have multiple
associated data structures. Each of these can be specified by a
connection point. It is possible within a single connection to specify
multiple connection points. This is typically used for I/O modules
where two connection points are used to specify the input and output
structures.
Connection Path Specified

By Path Segments
209
A connection path can contain multiple segments, with each segment

describing one link in the path. In the figure below, for example,
segments 1, 2, and 3 are path segments that specify the path from
device A to the device IN, while segment 4 is a class segment that
specifies the application within the device.
Figure 20.7
Segments in a Connection Path
Segment 1
1
C
N
Input
Application
Segment 2
MAC 15
1
C
N
IN
Segment 4
Diagnostic
Data
Structure
Segment 3
2010
Connection Path Size (Conn_Path_Size)

The connection path size is the length of the connection path in
16-bit words. The length of the connection path varies during the
connection process, since each node in the connection path removes
the current path segment and forwards only the remaining path
segments to the next node. The format of the connection path size is
shown below:
[ss]
USINT
where ss is the size in words
The connection path contains multiple segments which can either

indicate the path to the next node or what to connect to in the target
device. Segments must be words or multiple of words. If a segment
is an odd number of bytes, a pad byte is required at the end of the
segment to keep the segments word aligned.
The possible segment types are:
Path segment
Logical segment
Connection ID segment
Symbolic segment
Data segment
Path Segment Type

(Path_Seg_Type)
Each segment of the path contains a path segment type to indicate

how the segment is to be interpreted by the associated connection
manager. The segment type is contained in the first byte of the
segment, which is also used to indicate the port number for path
segments.
Figure 20.8
Representation of ControlNet Segment Types
Segment Type
Depends on Segment Type
Path Segment
Logical Segment
Reserved
Symbolic Segment
Data Segment
Reserved
2011
Segments in the Connection Path

The path can contain multiple segments. Each segment indicates
either the path for the connection to the next node, or the target
application within the device.
Figure 20.9
Segments of a ControlNet System Address
Path Segment
The path segment indicates the port and link address for the next hop
in the path. The first byte contains the segment type and the port
number. The maximum number of ports available on a device is 32.
The size of the link address will vary with the type of link and the
type of port. Figure 20.10 shows examples of possible path
segments.
Figure 20.10
Path Segment Type
Segment Type
Port Number
Optional
Link Address
Reserved Byte
used with link addresses u 8 bits
Size Depends on Port Type
Table 20.A
Path Letter and Path Number Designations
Path Letter
Path Number
Notes
Backplane port
First communications port
Second communications port
...
425
Other ports
26
27 32
Reserved (undefined)
2012
Table 20.B
Examples of Path Segments
Path Segment
Notes
[01][02]
Port (A) 1 Link Address 2 (slot 2 in the chassis)
[03][06]
Port (C) 3 Link Address 6 (ControlNet MAC address 6)
[02][rb][123456] 1
Port (B) 2 Link Address 123456 (SP50 address)
rb is reserved byte
Logical Segment
The logical segment selects a particular class, instance, or structure
element within a device. The first byte indicates the type and format
of the logical segment.
Figure 20.11
Logical Segment Type
Segment Type
Logical Type
Logical Format
Optional
Logical Value Depends on Format
Reserved Byte
used with logical addresses u 8 bits
0 0 1
Class
Instance
Structure Element
Connection Point
Attribute
0
0
0
0
1
0
0
1
1
0
0
1
0
1
0
Electronic Key
1 0 1
0
0
1
1
0
1
0
1
0 0
8-bit logical address

Reserved
Size of key in words
The class and instance are numeric values which the device can map
to internal data structures, as shown below:
Table 20.C
Examples of Class and Instance Values Mapped to Internal
Data Structures
Segment
Logical
Format
Notes
[21][rb][0500]
Class
16bit
class 5
[21][rb][0100]
Class
16bit
class 2
[24][rb][2000]
Instance
16bit
Instance 20
[20][01]
Class
8bit
class 1
[30][01]
Attribute
8bit
Attribute 1 of an object
[2C][05]
Conn. Pt.
8bit
Connection point 5
2013
The logical segment is used to indicate that the target device has
been reached. Additional segments beyond the logical segment are
used by the target device to select the desired transport for a data
structure or function. To specify the complete logical address for an
automation controller, for example, the logical address would contain
logical segments for the global data table and additional logical
segments to specify the data structure within the global data table.
These segments may be logical or path segments, and will be
interpreted by the connection manager in the automation controller.
Data Segment
The data segment contains parameters for the target application. The
size of the data segment is specified in number of words and depends
on the application. The data segment can be any number of words up
to 255. A path can contain more than one data segment if required.
Figure 20.12
Representation of the Data Segment Type
Segment Type
1
Variable-Length Data
Unused
Size of data in words
The size of the data segment is specified in words, as shown below:

Connection
Path Size
Connection Path
Notes
[80][07] [0100] [0200] [0300] [0400] [0500] [0600]

[0700]
7 words of data in a
data segment
[21][pad] [0500] [24][pad] [2000] [80][04] [0100]

[0200] [0300] [0400]
Class 5, Instance
20 with 4 words of
data
The data can be configuration information for the object, additional

parameters necessary for the connection, or any other information.
The data segment is not interpreted by any other device in the path,
so only the originating and target applications have to agree on its
contents. The recommended format for the data segment is that of a
ControlNet networkconnected message as described in section 8 of
this document.
2014
Path Connection Through

Bridges
When a path connection crosses from one link to another, it must

pass through a bridge. The bridge uses the network connection
mechanism of each link to form connection tables, which contain the
information necessary to forward the packet from one link to the
next. The bridge forms network layer connections only, and does not
participate in transport connections.
Chapter
21

Messaging is defined as one or more service transactions between
objects. Each service transaction comprises a service request and a
corresponding service response. The objects involved communicate
through network connection nodes that understand the
network-connected messaging protocol. Messages are sent via a
class 3 connection to the message router or via the unconnected
message manager through the message router. The goal of
network-connected messaging is to provide a flexible yet highly
interoperable communications protocol standard for all messaging
activity.
Messaging includes a set of common services that provide common
behaviors across the network. These behaviors form the minimum
set of standard, predefined behaviors available in a system. An
object definition defines which services are required in an object
implementation. Refer to Appendix A for object descriptions.
Messaging Protocol
Section
Page
Messaging Protocol
211
Protocol Formats
212
Data Formatting
215
Services
215
Message Router
219
Unconnected Message Manager
2112
Examples Of Messaging Packets
2113
The entire messaging stream is transmitted on networks as a byte

stream. All data is packed, transmitted, and encoded little endian on
communications networks. The term little endian refers to the
packing method in which:
The least significant byte of a data item is packed first.
The most significant byte of a data item is packed last (not
counting pad bytes).
All bytes in between are packed sequentially, from least
significant byte to most significant byte.
In ControlNet, little endian also describes the sequence in which
message bytes are transmitted (in sequential order from most
significant byte to least significant byte).
212
Protocol Formats
Protocol formats are detailed in the following sections. The sections

below explain the structure of general request messages and the
structure of general response messages.
Structure of a General Request Message

Figure 21.1 details the structure of general request messages in a
ControlNet system. The first byte of the message contains the service
code, and the second byte contains the size (in words) of the internal
object identifier (IOI). The IOI comprises one or more system
address segments, each of which is made up of an even number of
bytes. The data following the IOI are parameters of the specified
object or service.
Figure 21.1
Structure of a General Request Message
8 bits
Service Code
Number of
words of IOI
IOI
..
.
The IOI can be zero or more words.
Object/ServiceSpecific Parameters
..
.
The object/service-specific parameters can
range in size from zero bytes to the maximum
packet size (in bytes).
The bytes of a general request message are transmitted in the same

order (from the top down) as they are shown in Figure 21.1.
Message Service Codes

Figure 21.2 illustrates the format of a message service code, which
must contain 8 bits. The value of the most significant bit determines
whether a message is a request or a response: a value of zero (bit
cleared) signals a request message, and a value of one (bit set)
signals a response message. The remaining bits in the byte are
reserved for the service identifier.
213
Figure 21.2
Format of a Message Service Code
8 bits
Service Identifier
Request/ Response
Flag
Internal Object Identifier

An Internal Object Identifier (IOI) specifies the object within a
device that is being asked to perform a service. An IOI can comprise
zero or more system address segments. Refer to Tab 6 for more
information on system addressing. The types of system address
segments that an IOI can contain are the path, logical and symbolic
segments; IOIs can not contain data segments. The maximum
number of segments in an IOI is the number of segments needed to
uniquely identify a given object instance.
If the value for the number of words of IOI is zero, an IOI has not
been defined for the request. An object interprets the zero value to
mean that the request should be processed by the object that received
it, which is the consuming application.
A non-zero value in the number of words of IOI means that the IOI
is specified in the system address segments that follow. These
segments must be interpreted to determine which internal object
should process the service. The interpretation is usually performed
by the message router, but could be performed by any object whose
definition includes this functionality.
When a class logical segment is transmitted in an IOI without an
instance logical segment, the default value for the instance number
of the object requested is 1. As a result, when a class logical segment
is transmitted in an IOI without an instance logical segment, it
identifies object instance 1 of the specified object class.
Structure of a General Response Message

Figure 21.3 shows the structure of a general response message. The
first two bytes of the response message contain the response service
code and a null field. The format of the service code is shown in
Figure 21.2.
214
The second two bytes of the response message contain the general
status code and the size of the object/service-specific extended status
data. The specified number of words of object/service-specific
extended status follows. The words following the
object/service-specific extended status data make up the
object/service-specific response data.
Figure 21.3
Structure of a General Response Message
8 bits
Service Code
0
General
Status
Number of 16bit words of objectspecific
or servicespecific extended status data
Objectspecific or service-specific extended status data
..
.
The object/service-specific extended status

data can be zero or more words.
Objectspecific or service-specific response data

..
.
The object/service-specific response data

can be zero or more bytes.
Object/Service-Specific Extended Status

Data on the object/service-specific extended status is optional,
depending on which object generates the service response. A value
of zero in the field for the number of words of object/service-specific
extended status data means that there will be no data in this portion
of the response message.
A device that is not interested in or which can not access the format
of the object/service-specific extended status data can easily skip it.
The device simply adds the value in the number of words of
object/service-specific extended status data to its offset in the
message buffer.
215
Data Formatting
Data formatting adheres to the data typing and value encoding

methodology specified in Chapter 18, ControlNet Data
Management.
Services
Services encompass both the common services and services reserved

for class-specific applications. Common services are defined as
services that every object in a system can both request and respond
to, and class-specific services are those which have been defined for
use by a particular object class. To support either a common or
class-specific service, an object class must implement the service
interface as specified in the service definition.
See the object descriptions in Appendix A to determine which

common and/or classspecific services are recognized by the
different system objects.
Common Services
The service code corresponding to each common service has been
allocated for use by all class definitions. Although every object class
should implement some of the common services, a class is not
required to implement all of them. Any class that implements a
common service must implement the required service interface.
The common services are defined from a system view. The request
parameter formats, for example, describe how the client application
packs requests and how the objects in the connection path interpret
them. The response status and response parameter formats define
how the the objects in the connection path pack their responses and
how the client application interprets them.
The first object that detects an error always generates a response.
There is no parameter of a service definition, however, that specifies
which other objects in the connection path will also generate a
response. Additional details on service requests and responses are
provided in other parts of this section.
216
Allocation of Service Codes for Common Services

This table lists the codes and names of the common services.
Service Code (hex)
Service Name
00
<reserved>
01
Get_Attributes_All
02
Set_Attributes_All
03
Get_Attributes_List
04
Set_Attributes_List
05
Reset
06
Start
07
Stop
08
Create
09
Delete
0A
Multiple_Service_Packet
0B
App_Open
0C
App_Close
0D
Apply_Attributes
0E
Get_Attributes_Single
0F
Network_Resource_Present
10
Set_Attributes_Single
11
Find_Next_Object_Instance
12
<available for use>
13
<available for use>
14
<available for use>
15
<available for use>
16
<available for use>
17
<available for use>
18 - 31
Reserved for additional system common services
32 - 4A
Reserved for Vendor Specific services
4B - 63
Reserved for Object Specific services
63 - 7F
Reserved for future use
80 - FF
Used only as replies to above services
217
Allocation of General Status Error Codes

These numbers identify the common codes used to respond to errors
within a ControlNet system. Codes 0xD0 through 0xFF are reserved
for development use before registration.
The following table lists the codes, names and descriptions of the
general status errors that can occur in ControlNet networks.
Error
Code
(hex)
00
Error Name
Description of Error
Success
Service was successfully performed by the object

specified.
Connection failure
A connection related service failed along the

connection path. Further object specific information
should be supplied in the object specific status field of
the response.
Resources needed for the object to perform the
requested behavior were unavailable. Further object
specific information should be supplied in the object
specific status field of the response.
A portion of the data supplied as a object specific data
parameter of a service was invalid. The verification of
the data is specified in the object definition of the
object reporting the error.
The IOI segment identifier or the segment syntax was
not understood by the processing node The word
offset to the first segment of the IOI that is not
understood should be supplied in the first word of the
object specific status field of the response. IOI
processing stops when an IOI segment error is
encountered.
01
02
03
Resource
unavailable
Invalid value in
object specific data
parameter of a
service request
Internal Object
Identifier (IOI)
segment error
04
05
Internal Object
Identifier (IOI)
destination
unknown
The IOI is referencing an object class, instance or

structure element that is not known or is not contained
in the processing node. The word offset to the first
segment component that references something that is
unknown or not present in the processing node should
be supplied in the first word of the object specific
status field of the response.
06
Partial transfer
Only part of the expected data was transferred.
07
Connection lost
The messaging connection was lost.
08
Unimplemented
service
The service requested was not implemented or defined

for this class or object.
Invalid attribute
value
The value of an attribute of the object or class is invalid.

The object specific status should report the attribute
number and the status code of the first attribute
refusing data.
An attribute in the Get_Attributes_List or
Set_Attributes_List response has a non-zero status.
09
0A
0B
Attribute list error

Already in
requested
mode/state
The object is already in the mode/state being

requested by the service. The object specific status
should report the objects current status.
218
Error
Code
(hex)
0C
0D
0E
0F
Error Name
Object can not

perform service in
its current
mode/state
Object already
exists
The object can not perform the requested service in its

current mode/state. The object specific status should
report the objects current status.
Attribute value not

settable
The object attribute is not a settable attribute. The

object specific status should report the number of the
attribute refusing data.
Access permission
does not allow
service
The access permissions do not allow the object to

perform the service. The access permissions available
to the object should be reported in the extended
status).
The device containing the object does not allow the
object to perform the service in the devices current
mode/state. The object specific status should report
the devices current status.
The data to be transmitted in the response buffer is
larger than the allocated response buffer, therefore, no
data was transferred.
11
Devices
mode/state does
not allow object to
perform service
Reply data too
large
12
Fragmentation of a
primitive value
The service specified an operation that is going to

fragment a primitive data value, i.e., halve a REAL
data type.
Not enough data
The service did not supply enough data to perform the

specified operation.
Undefined attribute
The attribute specified is not defined for the class or

object.
Too much data
The service supplied more data than was expected

(depending on the service and the object, the service
may still be processed).
Object does not

exist
The object specified does not exist in the device.
Service
fragmentation
sequence not
currently in
progress
No stored attribute
data
The fragmentation sequence for this service is not

currently active for this data.
Store operation
failure
The attribute data of this object was not saved due to

some failure during the attempt.
Bridging failure,
request packet too
large for network
The service request packet was too large for

transmission on a network in the path to the
destination. The bridge device was forced to abort the
service.
The service response packet was too large for
transmission on a network in the path from the
destination. The bridge device was forced to abort the
service.
The service did not supply an attribute in a list of
attributes that was needed by the service to perform
the requested behavior.
10
13
14
15
16
17
18
19
1A
1B
1C
The requested instance of object to be created already

exists.
Bridging failure,
response packet
too large for
network
Missing attribute
list entry data
The attribute data of this object was not saved prior to

the requested service.
Error
Code
(hex)
1D
1E
219
Error Name
Invalid attribute
value list
The service is returning the list of attributes supplied

with status information for those attributes that were
invalid.
Embedded service
error
An embedded service resulted in an error.
Connection
Related Failure
1F
20
21 CF
D0 FF
Message Router (MR)
A service failed because of an error condition related to

the processing of a connection_related service. This
can occur during connected and unconnected
messaging. The same extended status codes used for
General Status Error Code 01 are returned for this
errors extended status.
Write-once value or An attempt was made to write to a writeonce medium
medium already
(e.g., WORM drive, PROM) that has already been
written
written, or to modify a value that cannot be changed
once established.
Reserved for future This range of error codes has been reserved for future
system use
system use.
Reserved for object This range of error codes has been reserved for use by
and class specific
object and class specific services, or for development
service errors
before registration.
The message router object allows an application to communicate

with any object in a device through a single point-to-point
connection. The message router interprets the IOI, and can only
communicate with objects that understand that protocol.
Using a Message Router in a Device

Figure 21.4 shows the context of the message router within a device.
The message router allows an application to open a connection to
communicate with any object in the same device. Objects within the
device that communicate with the message router have a predefined
connection to it; objects on other devices in the system, however,
must establish a connection to the message router using a class 3
connection services, or rely on the UCMM to pass the message to the
MR.
2110
Figure 21.4
Message Router Usage in a Device
Input
Download
Upload
Application
Scanner
Application
Message Router
Data Buffer
Transport
Connection
Manager
Transport Services
UCMM
Network
Network Connections
Link/Physical
ControlNet
backplane
DeviceNet
The message router interprets the IOI portion of a message to

determine which object is to perform the service specified, and
forwards the message to the destination object. The destination
object sends its response to the message router, which forwards it to
the requesting object via the established connection, or via a
response UCMM packet.
Data Sent by Message Router to Destination Object

The message router must report the following parameters to the
destination object: the service code of the service being requested,
the address of the message buffer from which processing should
continue, the number of words left to process in the request buffer,
and the number of words left to interpret in the IOI.
The service code is used by the message router to process the
response from the destination object. The remaining information is
determined after the destination object has interpreted the IOI. The
address and word counts are used to tell the destination object the
point at which it should continue processing the request.
2111
Message Router Interpretation of the IOI

The IOI comprises the information needed to identify an object
within a device. The message router must at least be able to interpret
an IOI made up of a class segment, an instance segment, and a
structure element segment. Greater functionality is possible
depending on the devices object hierarchy and access methods.
Interpretation of Commonly Used IOIs
A commonly used IOI is the single-level class/instance. The
example below shows the logical segments used to identify instance
1 of the connection manager (CM) class (0x06).
[20][06] [24][01]
The message router identifies the CM object from the class and
instance specified. The message router then reports to the CM object
the service, the address of the message buffer from which processing
should continue, the number of words left to process in the request
message, and the number of words left to interpret in the IOI.
A value of zero is reported for the number of words left to interpret
in a single-level class/instance IOI.
Interpretation of Complex IOIs
IOIs are considered complex if they allow various segment types to
be mixed or if they are used to access complex object hierarchies.
The methods used to interpret complex IOIs are similar to those used
to interpret an IOI containing a structure element logical segment
and an IOI containing a symbol segment. The message router either
calls a special routine that can identify the object, identifies the
object that will interpret the rest of the IOI, or both.
The interpretation of all complex IOIs requires more knowledge than
just an awareness of class and instance. This knowledge is often
device-specific, and must be implemented by the device designers.
Handling the Response from the Destination Object

The destination object is responsible for building the response,
including allocating resources for it. After the destination object
sends the response buffer to the message router, the message router
submits the response buffer to the originating object specified.
2112
Unconnected Message
Manager
Setting up a connection requires communication between devices.

These initial communications require an unconnected message
service. The unconnected message service, which only needs to
operate on a single link, is not like any of the other transports:
packets are queued at each node instead of the normal overwrite. As
a result, multiple connections can be established at the same time,
which reduces the overall time needed to set up all the connections in
a typical system.
The Unconnected Message Manager (UCMM) provides a single-link
unconnected message service that can support multiple outstanding
messages. Every device that participates in connections must have a
UCMM object. The functions of the UCMM are to:
Route the request packets to the message router
Provide a route for the response packets
Figure 21.5
Unconnected Messages Used to Set Up a Connection
Originator
Bridge
Target
NI_FWD_OPEN Conn SN 0001

FNI_WD_OPEN Conn SN 0001
Time
NI_FWD_OPEN_REPLY Conn SN 0001


Examples Of Messaging
Packets
2113
This section contain actual messaging packets captured on a running

ControlNet network. They are included to describe the two ways
which messaging packets can arrive at the message router: via the
UCMM, and via a class 3 connection.
The first example uses the UCMM to send a message to the device
object (0x01) through the message router.
Table 21.A
Device Object Get_Attribute: request
Data (hex)
07
General
Detail
ControlNet header
Size
01
Control
83 03
02
Tag
UCMM header
0A
UCMM Timeout
01 D8
01
UCMM Request
UCMM Message ID
IOI
02
Service code (Get attribute all request)

IOI size
20 01
Class (Device Object = 01)
24 01
Instance (1)
2114
Table 21.B
Device Object Get_Attribute: reply
Data (hex)
1E
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
UCMM Timeout
01 D8
81
UCMM Message ID
IOI
Service code (Get attribute all reply)
00
IOI size (not used for reply)
00
General status
00
01 00
Size of extended status in words

Electronic Key
Vendor ID (ALLENBRADLEY = 01)
0C 00
Product type
18 00
Product code
01
Major revision number
01
Minor revision number
00 00
62 51 00 00
09
Status
Serial number
Product name length
31 37 37 31 2d 41 43 4E 52
Product name in ASCII (1771ACNR)
00 00 00 00 00 00 00 00 00 00 00 00 00 00
Pad bytes
00 00 00 00 00 00 00 00 00
UCMM Request
2115
The second example uses a preestablished connection to the

message router to send a message to the PCCC object.
Table 21.C
Message to CNA30 Message Router
Data (hex)
12
General
Detail
ControlNet header
Size
12
Control
12
Tag pad
05 01 00
Tag
01 00
4B
Message ID
IOI
02
Service code (Execute PCCC)

IOI size
20 67
Class (PCCC)
24 01
Instance (1)
07 01 00 01 69 99 66 0F 00 00 00
PCCC Message
68 00 00 01 00 07 00 07 00 01 00
Table 21.D
Reply from CNA30 Message Router
Data (hex)
General
0F
ControlNet header
Detail
Size
16
Control
0F
Tag pad
01 03 00
Tag
01 00
CB
Message ID
IOI
Service code (Reply to execute PCCC)
00
00
General status
00
07 01 00 01 69 99 66 4F 00 00 99
PCCC Message
09 03 42 00 00 00
Table 21.E
Message to CNA30 Message Router
Data (hex)
12
General
Detail
ControlNet header
Size
12
Control
12
Tag pad
05 01 00
Tag
01 00
4B
Message ID
IOI
02
Service code (Execute PCCC)

IOI size
20 67
Class (PCCC)
24 01
Instance (1)
07 01 00 01 69 99 66 0F 00 00 00
PCCC Message
68 00 00 01 00 07 00 07 00 01 00
2116
Table 21.F
Reply from CNA30 Message Router
Data (hex)
General
0F
ControlNet header
Size
16
Control
0F
Tag pad
01 03 00
Tag
01 00
CB
Message ID
IOI
00
00
General status
00
07 01 00 01 69 99 66 4F 00 00 99
09 03 42 00 00 00
Detail
PCCC Message
Chapter
22

The process of establishing a ControlNet connection involves three
layers of the ControlNet Communication Model, and binds:
producers and consumers to connection IDs at the Network Layer
producers to transports at the Transport Layer
applications to transports at the Application Layer
Section
Page
Setting Up Connections Before Any Connections Are Made
222
Connection Manager
223
Example Connection Based On the Data Flow Diagram For The

Connection Manager
225
Connection Manager Services
229
Connection Manager Service Descriptions
2211
222
Establishing a ControlNet Network Connection
Setting Up Connections
Before Any Connections
Are Made
Any device which originates connections must contain a connection

manager (CM), a message router (MR), and an unconnected message
manager (UCMM). The CM sets up the connection within the
device and understands how to route the open connection service via
the UCMM to the next device in the connection path. All connection
requests, therefore, are sent to the CM on the local device. The CM
allocates the local resources required and forwards the OPEN
connection service request to the next node in the path.
The message router receives packets from the UCMM and forwards
them to the appropriate object. The MR determines the appropriate
object by interpreting the header of the packet (called the IOI). The
MR participates in connection establishment by passing connection
requests to the CM from the UCMM. Chapter 21 contains additional
details about the message router.
Figure 22.1
Typical Configuration for the Connection Manager
Local Connection Request
Real-Time
Data
Application
Real-Time
Data
Application
Message
Router
Connection
Table
Connection
Table
Connection
Manager
Unconnected
Message
Manager
Unconnected Messages
Message Connections
Connection Manager
223
The connection manager object, which is a required object in every

ControlNet device, is responsible for opening, maintaining, and
closing ControlNet network connections. The following paragraphs
provide information on how the connection manager functions to
perform these tasks.
Data Flow within the Connection Manager

The following data flow diagram includes the MR, applications,
transports, link producers / consumers and UCMM in addition to the
CM. All data flows for the connection manager are shown, but only
those data flows associated with the connection manager are shown
for the other objects.
The connection manager is treated as a single object for the purposes
of this discussion; the internals of the connection manager are
described in subsequent sections of this document. Two paths are
shown for messages between the application and the connection
manager: one using the MR, and one using local calls. Since these
messages will always be local to a device, most devices will
implement the local call version. The exact implementation of the
local calls depends on the hardware configuration, operation system,
and language selected for a device implementation. The following
data flows and service descriptions are documented in the form of
messages to the MR, and can be used to indicate the required
parameters.
224
Figure 22.2
Data Flow Diagram for a ControlNet Connection Manager
Link Producer
Consumer
NI_APP_OPEN_REPLY
NI_OPEN
CLOSE
NI_OPEN_REPLY
CLOSE_REPLY
NI_APP_OPEN
GET_ATTRIB_REPLY
NI_FWD_OPEN_REPLY
NI_OPEN_REPLY
CLOSE_REPLY
FWD_CLOSE_REPLY
NI_APP_OPEN
RESET_REPLY
Transport
NI_OPEN_REPLY
CLOSE_REPLY
NI_APP_OPEN
Message
SET_ATTRIB_
Router
REPLY
Application
NI_APP_OPEN_REPLY
NI_OPEN
CLOSE
Unconnected
Message
Manager
ControlNet
Unconnected
NI_OPEN_REPLY
CLOSE_REPLY
NI_APP_OPEN
Application
Link Producer
Consumer
Message
Router
NI_APP_OPEN_REPLY
NI_OPEN
NI_APP_OPEN_REPLY
CLOSE
NI_OPEN
CLOSE
GET_ATTRIB
NI_OPEN_REPLY
CLOSE_REPLY
NI_APP_OPEN
NI_APP_OPEN_REPLY
NI_OPEN
CLOSE
NI_APP_OPEN_REPLY
NI_OPEN
CLOSE
GET_ATTRIB
SET_ATTRIB
NI_FWD_OPEN
FWD_CLOSE
RESET
NI_FWD_OPEN
FWD_CLOSE
Producing
Connection
Producing
Producing
Table
Table
Connection
Connection
Table
NI_FWD_OPEN_REPLY
FWD_CLOSE_REPLY
Device
Device
Messages
Unconnected
Message
Manager
Transport
Consuming
Connection
Consuming
Table
Table
Connection
Connection
Table
Connection
Manager
NI_OPEN_REPLY
CLOSE_REPLY
NI_APP_OPEN
SET_ATTRIB_REPLY
GET_ATTRIB_REPLY
NI_FWD_OPEN_REPLY
FWD_CLOSE_REPLY
RESET_REPLY
NI_FWD_OPEN
FWD_CLOSE
NI_FWD_OPEN_REPLY
FWD_CLOSE_REPLY
Connection
Manager
SET_ATTRIB
NI_FWD_OPEN
FWD_CLOSE
RESET
Consuming
Connection
Consuming
Consuming
Table
Connection
Connection
Table
Table
Producing
Connection
Producing
Producing
Table
Connection
Connection
Table
Local Calls which are

Device Dependent
Example Connection
Based On The Data Flow
Diagram For The
Connection Manager
225
The following example is provided to better explain the data flow

diagram for the connection manager. In the example, a connection is
made between an application (a controller) in device 1 and another
application (an I/O module) in device 2 on the same link.
Figure 22.3
Example Connection Using the Data Flow Diagram
Device 1
Device 2
Controller
Input Module
Originator
Target
Data
ControlNet
The originator of the connection is device 1, and the target of the

connection is device 2. The originator of the connection is an
application or task in the controller, which connects all the I/O to the
global data table within the controller. The I/O module is the target
device, and the application within the I/O that produces the input
data is the logical address specified. The example uses the more
general form of having all messages sent via the Message Router.
Most devices will implement the local calls via a subroutine call and
an upcall for the reply, but since that method is somewhat
devicedependent, the following paragraphs explain a connection
being established using the message version. Refer to Figure 22.2,
Data Flow Diagram for a ControlNet Connection Manager, to see
more clearly what is being described in each paragraph.
226
Before the Connection can be Opened

The originating application in device 1 must first allocate a buffer
transport structure and link producers and consumers for the
connection. In many cases, such as a PLC5/40C, the location of the
buffer is part of the configuration of the module, the memory for the
buffer is allocated when the user program is built, and the address is
fixed. In other modules, the transport structure, link producers and
consumers and buffer may be created dynamically. And in the
simplest modules, the buffer, link producers and consumers and
transport will be fixed by the firmware at the time the module is
designed. By having the application allocate the buffer, link
producer and consumer and transport, the greatest flexibility is
preserved.
Originating Application Opens the Connection

The originating application opens the connection by building and
sending the OPEN message to the originating connection manager
via the MR. Many devices will implement the open request via a
subroutine call directly to the connection manager. The originating
application is responsible for specifying all the parameters in the
OPEN message, which include:
Pointer to the instance of the link producer and consumer to be
used for this connection

Network connection parameters
Transport connection parameters
Connection Path
Application data segment (optional)
Originating Connection Manager Receives the OPEN Message

When the originating connection manager receives the OPEN
message, whether via subroutine call or as a message from the
Message Router, the connection process begins. The originating
connection manager determines the context of the connection (which
is the originator context in the example), allocates a connection
structure, processes the connection request, and builds a
FWD_OPEN message for the next node in the path. The originating
connection manager then sends the message to the connection
manager on the port and link address specified in the first segment of
the connection path via the unconnected message manager.
227
Originating (Client) UCMM Sends Message

The client unconnected message manager sends the message to the
addressed node on the local link. The message is received by the
server UCMM on device 2, the target device. An ACK is sent back
from device 2 to device 1. If no ACK is received in a link specific
time the message is repeated. The target UCMM forwards the
message to the target connection manager via the MR in device 2.
Target Connection Manager Receives FWD_OPEN

The connection manager in the target device receives the
FWD_OPEN message and determines that the current device is the
target of the connection. The target connection manager builds an
NI_APP_OPEN message and sends the message via the Message
Router to the application specified by the segments of the connection
path. Some implementations will use a direct subroutine call to the
application, which will require the connection manager to have
access via the MR to the class and instance tables to call the
specified application. The APP_OPEN message contains any
additional path segments and information about the transport type
and connection size.
Target Application Builds Transport

The target application receives the APP_OPEN message via the
Message Router or via a subroutine call, and must return a pointer to
the link producer and consumer to be used by the connection. In
many implementations, the buffer, transport and link producer and
consumer will be built as part of the firmware, and the application
will simply return static pointers.
In higher function modules, the application will dynamically allocate
the buffer, transport and link producer and consumer instances.
Once again, allowing the application to manage the link producer
and consumer yields the greatest flexibility. In the
NI_APP_OPEN_REPLY, the target application returns status and a
pointer to the link producer and or consumer for the connection to
the target connection manager via either the Message Router or an
upcall, depending on the implementation. Depending on the
implementation, the target application may have to maintain a list of
connection serial numbers and owners or a count to know when to
stop communicating on a multicast connection. For point to point
connections the target application will need to know if the transport
is in use.
228
Target Connection Manager Completes Connection

The connection manager in the target device completes the
connection by setting up the link producer, consumer and screeners.
A FWD_OPEN_REPLY is built and returned to the originating
connection manager via the MR.
Target UCMM Forwards Reply

The MR returns the FWD_OPEN_REPLY to the server unconnected
message manager, which sends the reply back to the client UCMM.
The originating (or client) UCMM receives the reply and completes
the transaction by returning the reply to the originating CM. An
ACK is sent back from device 2 to device 1. If no ACK is received
in a link specific time, the reply is repeated.
Originating Connection Manager Completes the Connection

The originating CM completes the connection using the information
in the FWD_OPEN_REPLY. Completing the connection includes
setting up the link producer, consumer, and screeners; and building
an OPEN_REPLY. The OPEN_REPLY is then sent to the
originating application via either the MR or an upcall, depending on
the implementation.
Originating Application Uses the Connection

Once the OPEN_REPLY is received and the status is OK, the
originating application can use the connection. The connection
exists until either the originating application closes it or until no
packets have been forwarded on the connection for the specified path
timeout time. The originating application is returned to the
connection serial number in the OPEN_REPLY and must remember
the serial number to use in the close connection message.
Connection Manager
Services
229
The services of the connection manager are the same as the external
services of the connection processor.
Connection Manager Service Parameters Description

The following parameters are used for the NI_OPEN connection
service request message.
Nomenclature Used in the Descriptions

In the following descriptions, the letters in brackets are either 8bit
bytes or 16bit words, and have the formats shown below:
[xx]
8-bit byte
[xxxx]
16-bit word
[xxxxxxxx]
32-bit word
Service (Service_Code)
The service is designated using a standard ControlNet service code
that is represented as an 8bit value in which the upper bit indicates
request or reply.
Figure 22.4
Representation of the Service Request/Response
Service Request
MSB
LSB
Service Code
Request/Reply
The service is represented by

[rx]
USINT
r=
Request/Reply
x=
Command Code
2210
IOI Address Size (IOI_Size)

The IOI address size is the size in words of the internal module
address. For all services to the connection manager, the size of the
IOI will be fixed at one word. The destination of the connection
services will always be the connection manager. The IOI address
size is represented by:
[ss]
USINT
ss =
Size in words
Internal Object Identifier (IOI)

The internal object identifier is the logical address of the function or
data structure for which the service is to be performed. The internal
object identifier is specified using path segments, as described below.
In most of the services for connections, the IOI will be the logical
address, and will use a logical segment of the connection manager.
This will normally be determined by a single logical segment
specifying the class of the connection manager, as shown below:
Example:
[tp][l..l]..[tp][l..l]
t is segment type
l..l is variable based on the segment type
Connection Manager
Service Descriptions
2211
The following paragraphs describe services performed by the

connection manager and services which the connection manager will
request from other applications for ControlNet. The services are
described as being sent to the MR, but some services could be
implemented as local subroutine calls.
The following table shows the possible services. Figure 22.2, Data
Flow for a ControlNet Connection Manager, shows how some of the
objects in a ControlNet device relate to each other via the connection
managers services.
Service
Service
Code
Implemented
via Local
Subroutine Call
NI_FWD_OPEN
4Chex
No
NI_FWD_OPEN_REPLY
CChex
No
FWD_CLOSE
4Ehex
No
FWD_CLOSE_REPLY
CEhex
No
GET_ATTRIBUTES_SINGLE
0Ehex
No
Returns the contents of the specified attributes
GET_ATTRIBUTES_ALL
01hex
No
Returns the contents of all attributes of an object
SET_ATTRIBUTES_SINGLE
10hex
No
Modifies an attribute value
SET_ATTRIBUTES_ALL
02hex
No
Notes
Open a connection
Close a connection
2212
Table 22.A
Forward Open to Message Router: Request
Data (hex)
16
General
Detail
ControlNet header
Size
01
Control
83 05
02
Tag
UCMM header
38
UCMM Timeout
01 00
4C
UCMM Request
UCMM Message ID
IOI
02
Service code (Forward Open request)

IOI size
20 06
Class (Connection Manager)
24 01
Instance (1)
01
Forward open
Priority
38
parameters
Timeout
02 00 05 80
OT connection ID
02 00 01 80
TO connection ID
0A 00
Connection serial number
01 00
01 69 99 66
Serial number of connection owner
D0 2B
EPR
07 47
OT connection type
07 47
TO connection type
A3
02
Trigger
Connection Path
Path size
20 02
Class (Message Router = 02)
24 01
Instance (1)
Table 22.B
Forward Open Request to Message Router: ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
01 00
UCMM Request
UCMM Timeout
UCMM Message ID
2213
Table 22.C
Forward Open to Message Router: Reply
Data (hex)
10
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
UCMM Timeout
01 00
CC
UCMM Request
UCMM Message ID
IOI
Service code (Forward open reply)
00
00
General status
00
01 00 05 80
Forward open
OT connection ID
02 00 01 80
parameters
TO connection ID
0A 00
01 00
01 69 99 66
D0 2B
EPR
00
Application reply size
00
Reserved
Table 22.D
Forward Open Reply to Message Router: ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 05
05
Tag
UCMM header
00
01 00
UCMM Request
UCMM Timeout
UCMM Message ID
2214
Table 22.E
Forward Close to Message Router: Request
Data (hex)
0F
General
Detail
ControlNet header
Size
01
Control
83 05
02
Tag
UCMM header
38
UCMM Timeout
01 28
4E
UCMM Request
UCMM Message ID
IOI
02
Service code (Forward close request)

IOI size
20 06
24 01
Instance (1)
01
Priority
38
Timeout
00 00
Forward close
01 00
parameters
01 69 99 66
02

Connection Path
00
Path size
Pad byte for alignment
20 02
Class (Message Router = 02)
24 01
Instance (1)
Table 22.F
Forward Close Request to Message Router: ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
01 28
2215
Table 22.G
Forward Close to Message Router: Reply
Data (hex)
0B
General
Detail
ControlNet header
Size
01
Control
83 05
03
Tag
UCMM header
00
UCMM Timeout
01 28
CE
UCMM Request
UCMM Message ID
IOI
Service code (Forward close reply)
00
00
General status
00
00 00
Forward close
01 00
parameters
01 69 99 66
00
00
Reserved
Table 22.H
Forward Close Reply to Message Router: ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 05
05
Tag
UCMM header
00
01 28
UCMM Request
UCMM Timeout
UCMM Message ID
OPEN
The OPEN request service starts the open connection process, and is
sent from the originating application to the local CM via an
implementationdependent local subroutine call.
OPEN_REPLY
The OPEN_REPLY is sent from the local CM back to the originating
application. The reply indicates the status of the connection and
provides information about the connection including the connection
serial number if not specified by the originating application.
2216
The reasons for a connection failure fall into five major categories:
lack of resources
invalid addresses
errors detected by the target application
transport errors
target node is powering up
Lack of Resources
The possible reasons for a lack of resources at any of the nodes in the
path are lack of:
buffer memory at one of the intermediate nodes
bandwidth on one of the links in the path
screeners or CIDs at one of the nodes
Invalid Addresses
The invalid address errors occur when any node in the path cannot
forward the connection request. This can be the result of:
Unknown port number or port not supported at originator or
intermediate nodes
Unknown link address or link address not supported at originator
or intermediate nodes. (This is detected by a UCMM timeout)
Unknown class number or class number not supported at the
target node
Unknown instance number or instance number not supported at
the target node
Application Errors
The target application can reject the connection for a number of
possible errors. These include:
attempt to connect to a transport which can only support a single
connection
lack of an available transport to satisfy the connection
invalid address for an internal structure element of connection
point
transport type requested is not supported for this application
error in the format or value of the data segment
electronic key failed
owner conflict
duplicate owner. Owner already has opened a connection.
2217
Target node is powering up

A target node may not accept any connections for three seconds after
power is applied to the node. This delay allows nodes which may
have established connections before the target node was powered
down to deactivate their connections to the target node before new
connections are attempted.
The target node should have its receivers turned off during this time
so that messages cant be received. The target node should not
appear on the network until after the three seconds has elapsed.
FWD_OPEN
The FWD_OPEN service request sets up all required network,
transport and application connections. An application connection
consists of a single transport connection, and one or two network
connections which are in turn comprised of multiple link
connections. Each path segment in the connection path uses a link
connection. The FWD_OPEN service between two devices builds
one or two link connections as specified by the network connection
parameter and the requested packet interval (RPI). Since up to two
network connections can be required for a single transport
connection, they are differentiated by the OT (originator to target)
and TO (target to originator) designations.
The fields described are not used for all combinations of network
and transport connections, but must appear in the FWD_OPEN
service. Figure 22.2 shows the transmission of this service within the
context of the other connection manager services and the objects
which send and receive them.
2218
Format of the FWD_OPEN Service

The format of the FWD_OPEN service is shown in the table below.
Table 22.I
Forward Open to Rack Object: Request
Data (hex)
1E
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
38
UCMM Timeout
01 18
4C
UCMM Request
UCMM Message ID
IOI
02

IOI size
20 06
Class (Connection Manager) = 0 x 06
24 01
Instance (1)
01
Forward open
Priority
38
parameters
Timeout
01 00 02 80
OT connection ID
00 00 02 00
TO connection ID
01 00
01 00
D2 53 00 00
71 0E
EPR
26 48
OT connection type
2A 28
TO connection type
01
0A
Trigger
Connection Path
Path size (WORDS)
20 7C
Class (Rack Object = 7C)
24 01
Instance (1)
2C 02
Connection Point (02)
2C 01
Connection Point (01)
80 05
Data segment
01 00
Electronic Key
0C 00
Product type
18 00
Product code
01
01
03 00
Logical number of slots (3)
Although the same FWD_OPEN connection request service is used

for all transport classes, not all parameters are valid for all transport
types. Although the space for all parameters must be included in the
request service, the values are ignored.
2219
FWD_OPEN_REPLY
The response to the FWD_OPEN service is a FWD_OPEN_REPLY
service. The FWD_OPEN_REPLY contains the original connection
serial number and owner vendor and serial number and the
connection IDs (CID) necessary to complete the connection if
successful, and error information if the connection failed.
Figure 22.2 shows the transmission of this service within the context
of the other connection manager services and the objects which send
and receive them.
Format of the FWD_OPEN_REPLY Service

The FWD_OPEN_REPLY has two basic formats, one if the
connection is successful and a second if the connection fails because
of a problem in the connection system or the target application. The
format of the reply can be determined by the general status code as
shown in the following table.
General Status Code
Reply Format
Notes
00
Format A
Connection Established
01
Format B
Connection Failed
2220
Success (Format A)
Format A is used when the connection is successful. Success is
returned when the connection requested has been established from
this point forward in the path. This reply also indicates the
connection serial number and the actual packet rate of the
connection. Once the Success reply has been received, the
connection is open from this point forward in the path.
Function
Bytes in the Service
Notes
Reply Service
[D4][00]
Reply service with IOI size 0
Status
[ss][oo]
ss = general status code; oo = size

of objectspecific status/event data
in words. both ss and oo are zero
for success
Net OT connection ID
[tgmmcccc]
t = ID type; g = group; mm = MAC

or slot; cccc = connection number
Net TO connection ID
[tgmmcccc]
t = ID type; g = group; mm = MAC

or slot; cccc = connection number
[cccc]
cccc = connection serial number
Vendor ID
[vvvv]
vvvv=vendor ID
Originator
[ssssssss]
ssssssss = serial number of

originator
API O-T
[iiiiiiii]
APR in us. per packet. This may be

different than the O-T RPI.
API T-O
[iiiiiiii]
APR in us. between packets. This

may be different that the RPI.
Application Reply size
[xx][rb]
Size in words of the reply from the

application as a result of the data
segment
rb=reserved byte must be set to
zero
Application Reply
[xxxx]....[xxxx]
Array of words for the application

reply
serial number
2221
Failure (Format B)
Format B is used for all failures of the connection system. The
requested connection is not established, and the objectspecific
status words contain information about the reason for the failure. A
remaining path parameter contains the remaining path from the point
at which the connection failed. This information can be used to
debug the problem. The format of the FWD_OPEN_REPLY service
for a connection failure is:
Data (hex)
10
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
UCMM Timeout
01 18
CC
UCMM Request
UCMM Message ID
IOI
00
00
General status
00
01 00 02 80
Forward open
OT connection ID
02 00 02 00
parameters
TO connection ID
01 00
01 00
D2 53 00 00
71 0E
EPR
00
00
Reserved
The reasons for a connection failure fall into four major categories:
lack of resources
invalid addresses
errors detected by the target application
target node is powering up
CLOSE
The CLOSE service is sent by the originator application of a
connection to close the connection and deallocate the resources
associated with the connection. The service is sent from the
originator application to the local connection manager. The service
indicates the connection to close by using the original path and the
connection serial number. The originating application must save
both the connection path, required to open the connection, and the
connection serial number, returned by the OPEN_REPLY.
2222
CLOSE_REPLY
The CLOSE_REPLY service is sent from the local connection
manager to the originating application to indicate the status of the
close connection request.
The reasons for a close connection failure can be the result of invalid
addresses in the close connection path or a connection not found at
one of the nodes. It is possible for multiple errors to occur while
closing a connection, only the first error detected on the close reply
will be reported. The invalid address errors occurs when any node in
the path can not forward the close connection request. The close
connection request has not been completely executed and some
nodes may still have an open connection. This can be the result of a:
node in the path being powered down or removed.
broken or disconnected cable.
device being reset.
Any of the above causes can result in one of the following invalid
addresses:
Unknown port number or port not supported at originator or
intermediate nodes
Unknown link address or link address not supported at originator
or intermediate nodes (ICP can detect empty slots, ControlNet
can not detect unused MAC addresses)
Unknown class number or class number not supported at the
target node
Unknown instance number or instance number not supported at
the target node
FWD_CLOSE
The FWD_CLOSE service removes a connection from all the nodes
participating in the original connection. The FWD_CLOSE is sent
between connection managers as specified in the connection path.
The FWD_CLOSE request causes all resources in all nodes
participating in the connection to be deallocated, including
connection IDs, bandwidth, and internal memory buffers.
and receive them.
2223
Format of FWD_CLOSE
The format of the FWD_CLOSE service is:
Function
Notes
Service
[4E]
Close Connection
Size of IOI
[ss] = [02]
size of IOI in words
Class segment for connection manager
[SS][cc]= [20][06]
SS = logical class segment 8bit

format
Class segment for Conn

Manager Instance
[SS][ii]= [24][01]
cc = class of connection manager

SS = logical class segment 8bit
format
ii = instance number (1)
Connection priority
[xp]
1 = high; 0 = low (priority of the

UCMM messages to set up the
connection)
Connection timeout
[tt]
tt = connection timeout value

(Note 1)
Connection serial no.
[cccc]
Vendor ID
[vvvv]
vvvv=vendor ID
Originator
[ssssssss]
ssss = originator serial number
Connection path size
[ss][rb]
Size of connection path

zero
Connection path
[tp][ll]..[tp][ll]
t = segment type; p = port; ll =

segment address in reverse order
serial number
The close connection service specifies only the connection serial

number to identify the connection.
FWD_CLOSE_REPLY
The FWD_CLOSE_REPLY service is sent between connection
managers in response to a FWD_CLOSE, and contains the status of
the close request.
and receive them.
2224
Format of the FWD_CLOSE_REPLY

The FWD_CLOSE_REPLY has two basic formats, one if the close
connection is successful and a second if the close connection fails.
The format of the reply can be determined by the general status code
as shown in the following table.
General Status Code
Reply Format
Notes
00
Format A
Connection Successfully closed
01
Format B
Close Connection Failed due to

connection system
Success (Format A)
Format A is used when the close connection is successful. A
successful FWD_CLOSE_REPLY service is returned when the close
has been acknowledged by all the nodes from this point in the path to
the end of the path. The reply indicates the connection serial number
and owner vendor and serial number of the closed connection. Once
the reply indicating success has been received, the connection is
closed from this point in the path to the end. The target application
can optionally pass back application specific information in the
successful close reply. This information is object specific. For
further information refer to the specific object specification. If no
application reply information is contained in the service the
Application reply size will be zero.
Function
Notes
Reply Service
[CE][00]
Status
[00][00]

in words
[cccc]
Vendor ID
[vvvv]
vvvv=vendor ID
Originator serial number
[ssssssss]
Application Reply size
[xx][rb]
Size in words of the reply from the

application as a result of the data
segment
zero
Application Reply
[xxxx]....[xxxx]
Array of words for the application

reply
2225
Close Connection Failure (Format B)

Format B is used for all failures of the connection system. The
connection close request was not completely executed and some of
the connection may still be in place. The objectspecific status words
contain information about the reason for the failure. The remaining
path parameters contain the remaining size and path from the point at
which the close connection failed. This information can be used to
debug the problem. The format of the CLOSE_REPLY service for a
connection failure is:
Function
Notes
Reply Service
[CE][00]
Status
[01][03]

in words
Objectspecific status
[rrrr]
rrrr = Reason for resource failure
[cccc]
Vendor ID
[vvvv]
vvvv=vendor ID
Originator serial number
[ssssssss]
Remaining Connection
path size
[ss][rb]
Size of remaining connection path

zero
Remaining Connection
path
[tp][ll]..[tp][ll]
t = segment type; p = port; ll =

segment address
Reason for failure
APP_OPEN
The APP_OPEN service is sent from the target connection manager
to the target application. The APP_OPEN service contains
information needed by the application to open the connection. This
information includes any remaining address segments which could
be a data segment used to configure the application, the transport
class, and the connection serial number. The application must reply
to the APP_OPEN service with either a pointers to link producers
and or consumers to use for the connection, or an indication of
failure. For multicast connections the target application is
responsible for maintaining a count or list of the open connections on
this transport. For point to point connections the target application is
responsible for maintaining the state of the transport, in use or
available.
2226
APP_OPEN_REPLY
The APP_OPEN_REPLY is returned by the target application. The
reply contains a pointer to the transport if the application can accept
the connection, or an objectspecific reason for rejecting the
connection request.
APP_CLOSE
The APP_CLOSE service is sent from the target connection manager
to the target application to close the connection. The application
may deallocate the transport or perform other applicationspecific
operations as the result of the connection closing.
The close connection service specifies the connection using both the
pointer to the transport and the connection serial number. The
applications can use either to identify the connection to be removed.
APP_CLOSE_REPLY
The APP_CLOSE_REPLY is sent from the target application to the
target connection manager to indicate the success of the requested
close operation. For multicast connections the target application
must return a null link producer and consumer instance if this is not
the last connection.
GET_ATTRIBUTES_LIST
The GET_ATTRIBUTES_LIST service returns a list of attributes
about the connection manager or about a single connection. See
Chapter 21 ControlNet Messaging, for further details.
SET_ATTRIBUTES_LIST
The SET_ATTRIBUTES_LIST service makes it possible to set some
of the attributes of the connection manager. See Chapter 21
ControlNet Messaging, for further details.
Chapter
23

The ControlNet Product Developers Guide for Adapter Applications
requires that all products developed for the ControlNet network have
a Statement of Compliance.
Use this document as a guide to complete a ControlNet Statement of
Compliance. As each product is unique, each Statement of
Compliance will also be unique.
Whats Included
Section
Page
Whats Included
231
Completing The Form
232
The Statement of Compliance identifies protocol options, device

profile options, object options to the ControlNet specified
implementations which have public access from the ControlNet
network.
Required Sections
Each Statement of Compliance must include these sections:
Section
Function
General Device
Data
Describes the general nature of a device and the device profile

options
ControlNet Specification version that the device conforms to
vendor name
ControlNet device type
product catalog number
product series/revision
ControlNet
Physical
Conformance Data
Provides a summary of features of the ControlNet physical

conformance data
MAC ID setting method
MAC ID range
default MAC ID
communication rate setting method
required connectors
ControlNet
Required Object
Implementation
Provides the specific implementation of the Identity, Message

Router, Connection Manager, ControlNet Configuration Manager,
Non-Volatile Storage, and ControlNet objects options
Object Class (ControlNet services
and attributes)
Object Instance (ControlNet services
and attributes)
232
Creating A ControlNet Statement Of Compliance
Completing The Form
As each device is unique, you will need to adapt the example on

page 234 for each devices Statement of Compliance in the
ControlNet Required Object Implementation.
Guidelines for Object-specific Information

Follow these guidelines when completing the object-specific
information:
List implemented attributes in numeric order of attribute ID.
Indicate the attribute access rules actually implemented.
Specify attribute Value Limits different from those defined in the
ControlNet Specification.
List implemented services in numeric order of service code.
Specify service Parameter Options supported.
Include information only for attributes and services implemented
in the device.
When a section is not applicable, check the None Supported box.
Omit references to optional attributes or services defined for the
object that are not implemented.
Omit object implementation pages for objects not supported.
Definitions
Use these terms when completing the ControlNet Required Object
Implementation section.
Term
Definition
Value Limits
This data provides limits imposed on the associated attribute value

by the implementation beyond those stated in the ControlNet
Specification.
Parameter Options
This data specifies optional service parameter values supported by

the implementation vendor services require types and values.
Object Name - ID
The object name and class code.
233
Completion Steps
The Statement of Compliance for your device defines the specific
implementation of the ControlNet Required Objects.
Use the example Statement of Compliance for a 1771-ACN
communications adapter beginning on page 234 as a guide when
you complete your own Statement of Compliance.
To complete this form, you must have a thorough knowledge of your
product and the ControlNet protocol. Follow these steps when
completing your own Statement of Compliance.
Important:
Remember that each series/revision of a product catalog

number will have a unique Statement of Compliance.
You may need to add or delete information when you
create your own Statement of Compliance.
Complete this section:
On this page of the

form:
Using the example

as a guide on page:
General Device Data
F-1
234
ControlNet Physical Conformance Data
F-1
234
ControlNet Required
Object Implementation
F-2
F-3
F-4
F-5
235
236
237
238
N/A
F-6
F-7
239
N/A
Identity Object
Message Router Object
Connection Manager Object
ControlNet Object
Manager Object
Non-Volatile Storage Object
ControlNet Scheduling Object
234
Statement of Compliance
ControlNet
Example Form (for Photoelectric Sensor)
Complete this form using the definitions previously outlined.

Fill in the blank or
General
Device
Data
Conforms to ControlNet Product Developer Guide
ControlNet
Physical
Conformance
Data
Vendor Name
Device Type
Product Catalog Number
Product Series/Revision
MAC ID Setting
the appropriate box
Revision
____________________
DIP Switch
Rotary Switch
Software Settable 7
MAC ID Range
1-99
____________________
Other
None
____________________
None
____________________
Default MAC ID
Communication Rate Setting
Revision
__________________________________
Allen-Bradley Company, Inc.
________________________________
Communications Adapter (12)
________________________________
1771-ACN
__________________________________
A/A
__________________________________
DIP Switch
Software Settable 7
Other None
____________________
Required Connectors
Network Access Port

Non-Redundant Media1
To offer a non-redundant media product, a redundant media product must also exist.
F-1
Redundant Media
1 of 6
ControlNet
ControlNet
Required
R
q i d
O j c
Object
I
aImplementation
Object Class
Identity Object 0x01

Identity Object Specification
ID Description
Attributes
Revision
Max instance
Number of instances
Optional attribute list
Optional service list
Max ID of class attributes
None Supported
Release _________________________
Get
Set
Value Limits
7
7
7
7
7
7
7
7
7
7
7
7
7
7
___________________
___________________
___________________
___________________
___________________
___________________
Max ID of instance attributes

7
ControlNet Services
___________________
Parameter Options
7
7
7
7
Get_Attribute_All
________________________________
Reset
________________________________
________________________________
________________________________
Get_Attribute_List
________________________________
Object Instance
ID
Description
Get
Set
Value Limits
Attributes
Vendor
Product type
Product code
Revision
7
7
7
7
___________
7
7
7
7
Status
___________
Serial number
___________
Product name
__________________
Services
7
None Supported
ControlNet Services
Services
F-2
235
Reset
Get_Attribute_All
Get_Attribute_List
Get to indicate that attribute value is Gettable.
Set to indicate that attribute value is Settable.
___________
___________
___________
___________________
Parameter Options
None
____________________________
____________________________
____________________________
____________________________
2 of 6
236
ControlNet
ControlNet
R q i d
Required
O j c
Object
I
Implementation
ai
Message Router Object 0x02
Message Router Object Specification
Release _________________________
Object Class
ID
Description
Get
Set
Attributes
Revision
7
7
7
7
7
7
7
7
None Supported

7
ControlNet Services
Services
7
None Supported
___________________
Parameter Options
________________________________
________________________________
Get_Attribute_List
Object list
Maximum connections supported
Number of active connections
Active connections list

4
ControlNet Services
7
7
7
7
___________________
Attributes
F-3
___________________
Get_Attribute_All
Description
Services
7 None Supported
___________________
ID
None Supported
___________________
Object Instance
Value Limits
Get_Attribute_All
Get_Attribute_List
Multiple_Command
Get
Set
7
7
7
7
7
7
7
Value Limits
___________________
___________________
___________________
___________________
Parameter Options
________________________________
________________________________
________________________________
________________________________
3 of 6
ControlNet
ControlNet
Required
R
q i d
O j c
Object
Implementation
I
ai
Object Class
Connection Manager 0x06

Connection Manager Object Specification
ID Description
Attributes
Revision
Max instance
None Supported
ControlNet Services
Services
7
None Supported
7
7
_________________
_________________
Parameter Options
Get_Attribute_List
_______________________________
Get_Attribute_All
_______________________________
_______________________________
Get
Description
Attributes
Open Reqs
Open Format Rejects
3
4
Set
Value Limits
Open Resource Rejects
7
7
7
7
7
7
Open Other Rejects
__________________
Close Reqs
__________________
Close Format Rejects
__________________
Close Other Rejects
__________________
__________________
__________________
__________________
__________________
Conn Timeouts
Num Conn Entries
__________________
10
Conn Open Bits
__________________
11
CPU Utilization
__________________
12
Max Buff Size
__________________
13
Buff Size Remaining
__________________
ControlNet Services
Parameter Options
_______________________________
Get_Attributes_All
_______________________________
Get_Attributes_List
_______________________________
Set_Attributes_All
_______________________________
Set_Attributes_List
_______________________________
_______________________________
Open
_______________________________
Fwd_Open
_______________________________
Close
_______________________________
Fwd_Close
_______________________________
Find
_______________________________
Proxy_Open
_______________________________
Proxy_Close
_______________________________
Unconnected_Send
_______________________________
Ni_Open
_______________________________
Ni_Fwd_Open
_______________________________
Ni_Proxy_Open
_______________________________
Get_Connection_Data
_______________________________
Search_Connections_Data
_______________________________
7
7
7
7
F-4
7
7
ID
None Supported
Release _____________________
Get
Set
Value Limits
Object Instance
237
4 of 6
238
ControlNet
ControlNet
Required
Object
Implementation
Object Class
ControlNet Object 0x65

ControlNet Object Specification
ID Description
Attributes
Revision
Maximum instance number
ControlNet Services
Services
Release _____________________
Get
Set
Value Limits
7
7
7
7
_______________
_______________
Parameter Options
Get_Attributes_Single_____________
____________________________
______________________________
____________________________
______________________________
____________________________
Get
Set
Object Instance
ID
Description
Attributes
80
Pending Network Config Parameters
81
Current Network Config Parameters
82
Diagnostic Counters
7
7
7
83
Station Status
7
7
7
7
84
MAC ID Switch and Current Settings
_______________
85
Scheduled Data Limit
Error_log
_______________
86
87 Additional Diagnostic Counters

ControlNet Services
F-5
Value Limits
_______________
_______________
_______________
_______________
_______________
_______________
Parameter Options
Reset
____________________________
____________________________
____________________________
Get_Attributes_All
____________________________
Set_Attributes_All
____________________________
Get_Attributes_List
____________________________
Set_Attributes_List
____________________________
Sync
____________________________
Get_And_Clear
____________________________
Enter_Listen_Only
____________________________
Where_Am_I
____________________________
5 of 6
ControlNet
ControlNet
Optional
Object
Object Class
Implementation
Non-Volatile Storage Object 0xA1

Release _____________________________
ID Description
Get
Set
Value Limits
Attributes
7
F-8
239
None Supported
1
2
Revision
Number of Instance
7
7
7
7
___________________________
___________________________
ControlNet Services
Parameter Options
Services
7
7
7
Get_Attributes_List
Get_Attributes_All
________________________________________
________________________________________
________________________________________
Object Instance
ID
Description
Get
Set
Attributes
Current Status of NVS Object
Value Limits
___________________________
ControlNet Services
Parameter Options
7
7
7
7
7
7
7
7
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
Get_Attributes_List
Get_Attributes_All
Update
Upload
Transfer
Restore
Read
6 of 6
2310
2311
Complete this form using the definitions previously outlined.
Fill in the blank or
General
Device
Data

Vendor Name
Device Type
Product Catalog Number
Product Series/Revision
the appropriate box

Revision ______________________
______________________________
______________________________
______________
______________
ControlNet
Physical
Conformance
Data
Revision ____________________
MAC ID Setting
DIP Switch
Software Settable
Rotary Switch
MAC ID Range
Other
Default MAC ID
______________
Communication Rate Setting
DIP Switch
Software Settable
Other
Required Connectors
Network Access Port

Non-Redundant Media1
Redundant Media
2312
ControlNet
ontrol et
Required
Object
Implementation
Identity Object 0x01

Identity Object Specification
Object Class
ID
Description
Attributes
Revision
Max instance
Number of Instances
Optional Attribute List
None Supported
_____________________
_____________________
Optional Service List
_____________________
_____________________
ControlNet Services
Services
None Supported
Release
__________________________
Get Set Value Limits
_____________________
_____________________
_____________________
Parameter Options
Get_Attribute_All
________________________________
Reset
________________________________
Get_Attribute_List
________________________________
_
________________________________
_
________________________________
Object Instance
Attributes
ID
Description
Vendor
Product type
Product code
Revision
Status
Serial number
Product name
ControlNet Services
Services
_
Get
Set
Value Limits
___________
___________
___________
___________
___________
___________
_____________________
_____________________
Parameter Options
Reset
________________________________
Get_Attribute_All
________________________________
Get_Attribue_List
_
________________________________
_
________________________________
_
ControlNet
R q i d
Required
Object
I
Implementation
ai
Message Router Object 0x02

Message Router Object Specification
Object Class
ID
Description
Attributes
Revision
None Supported
ControlNet Services
Services
None Supported
2313
Release
__________________________
_____________________
_____________________
_____________________
_____________________
_____________________
Parameter Options
Get_Attribute_All
________________________________
Get_Atrribute_List
________________________________
_
________________________________
Object Instance
ID
Description
Attributes
Object list
Maximum connections supported
Number of active connections
None Supported
4
Active connections list
ControlNet Services
Services
None Supported
Get_Attribute_All
Get_Attribute_List
Multiple_Command
_
Get
Set
Value Limits
_____________________
_____________________
_____________________
_____________________
Parameter Options
________________________________
_
________________________________
_
________________________________
_
________________________________
_
2314
ControlNet
ontrol et
Required
Object
Implementation
Connection Manager 0x06

Connection Manager Object Specification
Release
__________________________
Object Class
ID
Description
Attributes
1
2
Revision
Max Instance
ID
ControlNet Services
Parameter Options
Get_Attribute_List
Get_Attribute_All
________________________________
_
________________________________
_
________________________________
_
None Supported
Services
None Supported
Object Instance
ID
Description
Attributes
1
2
3
4
5
6
7
8
9
10
11
12
13
Open Reqs
Open Format Rejects
Open Resource Rejects
Open Other Rejects
Close Reqs
Close Format Rejects
Close Other Rejects
Conn Timeouts
Num Conn Entries
Conn Open Bits
CPU Utilization
Max Buff Size
Buff Size Remaining
None Supported
ControlNet Services
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
Parameter Options
Get_Attributes_All
Get_Attributes_List
Set_Attributes_All
Set_Attributes_List
Open
Fwd_Open
Close
Fwd_Close
Find
Proxy_Open
Proxy_Close
Unconnected_Send
Ni_Open
Ni_Fwd_Open
Ni_Proxy_Open
Get_Connection_Data
Search_Connection_Data
2315
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
2316
ControlNet
ontrol et
Required
Object
Implementation
Object Class
Attributes
ControlNet Object 0x65

ControlNet Object Specification
ID
Description
1
2
Revision
Maximum Instance Number
ControlNet Services
___________________________
___________________________
Release ________________________
___________________
_
___________________
_
Parameter Options
_______________________________
_
_______________________________
_
_______________________________
_
Object Instance
ID
Description
Get
Attributes
80
81
82
83
84
85
86
87
Pending Network Config Parameters

Current Network Config Parameters
Diagnostic Counters
Station Status
MAC ID Switch and Current Settings
Scheduled Data Limit
Error_log
Additional Diagnostic Counters
___________________
_
___________________
_
___________________
_
___________________
_
___________________
_
___________________
_
___________________
_
___________________
_
Parameter Options
ControlNet Services
Reset
Get_Attributes_All
Set_Attributes_All
Get_Attributes_List
Set_Attributes_List
Sync
Get_And_Clear
Enter_Listen_Only
Where_Am_I
Auto_Address
Set
2317
Value Limits
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
_______________________________
_
2318
ControlNet
ontrol et
Required
Object
Implementation
Object Class
ControlNet Configuration Manager Object 0x79

ControlNet Configuration Manager Object
Release
__________________________
ID
Description
Attributes
Revision
ControlNet Services
Object Instance
Attributes
ID
ID
_____________________
Parameter Options
________________________________
___________________________ ________________________________
___________________________ ________________________________
Description
Status
Description
Get
Set
Get
Set
Value Limits
_____________________
Value Limits
0
1 FE
FF
100
101
102
103
104
105
Status
Port Status for Node 1-254
Current Network Parameters
Current Name of this Subnet
CCM Table Unique Identifier
NetworkTUI
Current Cable Configuration
Co Summary
Connection Originator Info
ControlNet Services
Get_Attributes_List
Set_Attributes_List
Get_Attribute_Fragment
Set_Attribute_Fragment
Obtain_Network_Resource
Hold_Network_Resource
Release_Network_Resource
Change_Start
Change_Complete
Change_Abort
Sync_Change
Get_Signature
2319
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
_____________________
Parameter Options
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
2320
ControlNet
ontrol et
Optional
Object
Implementation
Non-Volatile Storage Object 0xA1

Object Class
ID
Description
Attributes
None Supported
1
2
Revision
Number of Instance
ControlNet Services
Services
Get_Attributes_List
Get_Attributes_All
Object Instance
ID
Description
Attributes
Current Status of NVS Object
ControlNet Services
Get_Attributes_List
Get_Attributes_All
Update
Upload
Transfer
Restore
Read
Release
__________________________
_____________________
_____________________
Parameter Options
________________________________
_
________________________________
_
________________________________
_
_____________________
Parameter Options
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
ControlNet
ontrol et
Optional
Object
Implementation
Object Class
Attributes
2321
ControlNet Scheduling Object 0xAB

ControlNet Scheduling Object
Release
__________________________
ID
Description
1
2
3
Revision
Max Instances
Number of Instance
ControlNet Services
Services
Get_Attributes_List
Get_Attributes_All
Create
Object Instance
ID
Description
Attributes
1
2
Route
Time Out
ControlNet Services
7
7
7
_____________________
_____________________
_____________________
Parameter Options
________________________________
_
________________________________
_
________________________________
_
________________________________
_
7
7
_____________________
_____________________
Parameter Options
2322
7
7
7
7
7
7
Get_Attributes_List
Get_Attributes_All
Set_Attributes_List
Set_Attributes_All
Create
Delete
Read
Conditional Write
Forced Write
Change Start
Break Connections
Change_Complete
Kick Timer
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
________________________________
_
Chapter
24

This chapter presents conformance criteria for ControlNet products.
Conformance is defined as the testing of products for the existence
of characteristics/behavior required by architectural standards.
The conformance criteria presented in this document are the current
minimum standards that must be supported by ControlNet products.
While there are subtle differences, the terms conformance and
compliance are considered to be interchangeable.
There are three categories of conformance:
This conformance category:
Is concerned with:
physical
the look and feel of a product
technology
the technology pieces that must be present for

products to co-exist on the same ControlNet network
application
value-added functionality that provides

interoperability among ControlNet products

Section
Page
Physical Compliance Criteria
242
Technology Compliance Criteria
243
Application Compliance Criteria
244
242
ControlNet Conformance Criteria
Physical Compliance
Criteria
Physical criteria is identified in Table 24.A. It is not the role of

compliance tests to assess the conformance of products to specific
environmental requirements. This activity is covered by product
development testing. Presence indicates whether the Physical Piece
is required or optional. Physical Piece refers to a physical part or
component of the product. Criteria are the expected
behaviors/qualities as defined in various documents in the Reference
column.
Table 24.A
ControlNet Physical Criteria
Presence
Physical Piece
Criteria
Reference
Required
Serial Number
Visible on exterior of product
Registering Product
Constants
Required
Connector
(ControlNet Access
Port)
RJ45 type
Pinout as specified in reference
Connectors and Electrical

Connections
Required
Connector
(ControlNet
Network)
BNC as specified in reference

Electrical connections as specified in
reference
Mechanical connections as specified
in reference
Connectors and Electrical

Connections
Required
Product Labeling
specified in reference
ControlNet Physical and

Required
Status LED
States/indications as specified in
reference
LEDs and Switches
Required
LED
States/indications as specified in
reference
ControlNet Physical and

Optional
Address Switches
Operation as specified in reference
LEDs and Switches
Technology Compliance
Criteria
243
Technology criteria is identified in Table 24.B. Technology Piece

refers to a discrete unit of functionality. Practically, they are
software implementations of architectural behaviors. The Class
Code refers to codes assigned to the technology pieces. Criteria are
the expected behaviors.
Table 24.B
ControlNet Technology Criteria
Technology Piece
Class Code
(Hex)
UCMM
N/A
Message Router
Object
02
Connection Manager
Object
06
ControlNet
ontrol et Object
65
Device/Identity Object
01
Non-volatile
on- olatile Storage
A1
Criteria
Accepts Low priority fwd_open service
Accepts Low priority fwd_close service
Accepts High priority fwd_open service
Accepts High priority fwd_close service
Accepts datagram service
Can support at least one connection
Denies connection to non-existent class
Closes an open connection
Denies closing a previously closed connection
Correctly routes a message not directed to
itself
Process open connection to Message Router
Denies connection containing connection
serial number from existing connection
Denies connection containing reserved
connection type
Denies connection containing reserved
connection path
Process close connection to Message Router
Process close connection to previously closed
connection
Powers up in listen-only mode
Transitions to on-line via set_attribute_single
service
Reset service transitions from on-line to
listen-only
Will not transition to on-line via
get_attribute_single service
Pending config sched.rate = current config
sched.rate following power-up
Macrocycle start <= macrocycle length
following power-up
Pending config state = current config state
following power-up
Responds to get_attribute_single service
Responds to the get_attribute_all service
Responds to reset service (power-cycle
emulation)
Responds to the get_attribute_single service
Responds to the get_attribute_all service
244
Application Compliance
Criteria
ControlNet value-added applications must fit into one of four classes

and meet specific class criteria:
message class
adapter class
scheduled peer class
scanner class
Chapter
25

Use this chapter to install and use the ControlNet network
compliance tool (cat. no. 9220-CC). This tool verifies a products
compliance to the ControlNet network protocol.
This tool was designed for engineers and developers familiar with
the ControlNet network and network troubleshooting. To use the
tool efficiently, you should be familiar with ControlNet protocols.
Understanding The Tool
Section
Page
Understanding The Tool
251
System Requirements
253
Installing The Compliance Tool
254
Configuring The Traffic Analyzer Tool
255
Using The Compliance Tool
2510
Understanding The Tests
2512
Troubleshooting
2513
Use this tool to:

examine and analyze a device for ControlNet network compliance
assist in the testing and debugging of ControlNet products
This tool contains these tests:
Test
ucmm.exe
Typical test time:

50 s
Used to test the:

UCMM (unconnected message manager)
mr.exe
40 s
MR (message router)
cm.exe
50 s
CM (connection manager)
cnet.exe
20 s prior to power cycle,

55 s after test resumes
ControlNet object
devobj.exe
35 s prior to power cycle

25 s after test resumes
device object
nvs.exe
35 s
nonvolatile storage
252
Using The ControlNet Network Compliance Tool
To acquire packets from the network and record the test results, you
need to install and run the ControlNet traffic analyzer tool (9220-TA)
on a separate personal c
omputer.
Use this computer to run the tests
and create log files (.log) of the tests.
Use this computer to capture packets from

the network and write them as displayed
to a text file (.txt).
personal computer running

compliance tests (9220-CC)
personal computer running

traffic analyzer (9220-TA)
9220-KTCT
device
under
test (DUT)
9220-KTCT
ControlNet link
Use this table to become familiar with some of the tools terms.
This term:
Refers to the:
CM
connection manager, that opens and closes connections as well as

maintains the networks connection tables. The CM:
S sets up a connection within its node
S processes all connection requests sent on the local service
S routes all open connection service via the UCMM to the next node in a
connection path
S forwards the open connection service request to the next node in the path
S establishes a connection to a target nodexs
Lpacket
link packetdata packaged and labeled by a node in preparation for

transmission.
MR
message router. The MR allows an application to open connections to

objects within the same node and
S routes the connection request to the UCMM on a target node
S interprets the part of a message that indicates the destination object
S routes the message to the appropriate object for execution
SMAC
ControlNet Media Access Control interface circuitry used to send and

receive data on an ControlNet network.
UCMM
unconnected message manager, that provides the ability to send a message

without an established connection. The UCMM:
S receives incoming UCMM messages
S sends and receives unconnected messages to and from its local MR and
CM
System Requirements
253
You need two personal computers with these specifications.

Attribute
microprocessor
operating system
memory
hard disk space
Description
486 33 Mhz PC AT or higher
MS-DOS 3.3 or higher
4 MB or higher
8 MB
VGA or high resolution
video adapter and
recommended: ATI VGAWonder XL card and color, super VGA
display (800 x 600)
monitor
minimum: VGA card and a display capable of 640x480 VGA
disk drive
one 3.5 high-density drive
ISA/EISA bus
ControlNet ISA/EISA bus interface (9220-KTCT)
communication interface for interfacing to the ControlNet network
pointing device
Microsoft Mouse or compatible
S ControlNet traffic analyzer tool (9220-TA)
software
S 9220-KTCT DOS driver KTCX.SYS, version 0.48,
shipped with 9220-CC
The amount of RAM determines how much data you can capture4 MB captures 1.5 MB of data.
The amount of hard disk space determines how much data you can store to disk files.
Important:
On the computer with the traffic analyzer tool installed,

make sure:
the CONFIG.SYS file contains the lines

files = 15 and buffers = 20.
there are not any device drivers or TSRs loaded except the
mouse driver software.
254
Installing The Compliance

Tool
1. Insert the 9220-CC disk into your computers 3.5 diskette drive.
2. Create a directory on your hard drive for the tool:
mkdir tool_directory
Enter
3. Copy the contents of the tool disk to the directory you created.
copy A:*.* c:\tool_directory
Enter
4. Edit your config.sys file to set up the path for the CNXOR.CFG
file and for the DOS driver.
A. Open your config.sys file.
edit config.sys
Enter
B. Add these statements to the file.

set cnxpath=C:\tool_directory
DEVICE=C:\tool_directory\KTCX.SYS/0,5,D000,0,1,200
C. Save this change to the file.

Alt
D. Close the file.

Alt
E. Activate this change by rebooting your computer.

Ctrl
Alt
Del
Configuring The Traffic

Analyzer Tool
Important:
255
Before running any of the compliance tests, you need to

configure the traffic analyzer tool as shown.
1. Start the traffic analyzer tool:

This command should be performed in
the directory you installed the traffic
analyzer software in.
ta
Enter
You see:
Important:
If you see the following error message, your

computer is not using the CONFIG.SYS file
supplied with the traffic analyzer tool.
***Abort: system not in 80286 or 80386 real mode ***
To initiate use of the traffic analyzer tools

CONFIG.SYS file:
A. rename c:\config.sys c:\config.old
B. copy c:\ta_directory\config.sys c:
C. Reboot your computer
Ctrl
Alt
Del
D. Repeat step 1.
2. Click on Continue.
256
3. From Setup, choose Analyzer Collection Display and Setup.
4. Set the data source information.

A. From Input, choose Network.
B. From Timeout, choose timeout and 60
Enter
A. & B.
5. Set the pre-collection filter information.

A. From Pre-collection Filters, choose Turn Filtering On.
B. From Pre-collection Filters, choose Select Filters.
A. & B.
C. From Packet Status, choose Good and Bad.

D. From Packet Type, choose Sched & Unsched.
C.
E. Choose Add.
D.
257
F. Choose Save.
F.
E.
6. Set the trigger pattern information.

A. From Trigger, choose Turn External Pulse Off.
B. From Trigger, choose Buffer Full.
C. From Trigger Point, choose the first position, for Start.
D. From Packet Buffer, choose Buffer Size and 10000
Enter
A. & B.
C.
D.
7. Set the layer display to Interpret.
258
8. Set the post-collection filter information.

A. From Post-Collection Filters, choose Filtering On.
B. From Post-Collection Filters, choose Select Filters.
A. & B.
C. From Packet Status, choose Good and Bad.

D. From Packet Type, choose Sched & Unsched.
C.
E. Choose Add.
F. Change MAC ID to 02.
D.
259
G. Choose Add.
H. Choose Save.
H.
G.
9. Set the display format.

A. From Display, choose Hex / ASCII.
B. From Display, choose Time On.
A. & B.
C. Choose Exit, Make Setup Changes Active.
2510
10. Set the SMAC configuration.

A. From Setup, choose SMAC Configuration, Initialize.
B. Choose save.
Using The Compliance

Tool
Important:
Before running any of the compliance tests,
install the compliance tool as shown on page 254

configure the traffic analyzer tool as shown on page 255
To run a test:
1. Activate the traffic analyzer tool to capture information. On the
computer that the traffic analyzer tool is configured, choose Run.
2. On the computer that the compliance tests are installed, change to

the tool directory.
cd tool_directory
Enter
3. Run the test youve selected.

cm XXCM.log
test
Enter
name of the test log file to create
XX=last two digits of the catalog number you are testing
2511
You see test information. An example of what is displayed for

the CM test is shown below.
ControlNet Connection Manager Compliance Test Group started
Initializing interface...Complete
Loading CN parameters...Complete
Going online...Complete
Test 5.3.1 passed

Test 5.3.6 passed
Test 5.3.7 passed
Test 5.3.2 passed
ControlNet Connection Manager Compliance Test Group FInished
Complete
Press any key to continue.
4. On the computer that the traffic analyzer tool is installed:

A.
ESC
to display the captured packets.
B. From File, choose Write Display to File, All Displayed

Packets.
C. Type in a name for the .txt file
Enter
2512
"
We recommend that you follow the naming convention you used for
the .log file: xxCM.txt
name of the test display file to create
XX=last two digits of the catalog number you are testing
Repeat steps 3 and 4 for each test you want to execute.
Understanding The Tests
The following table provides a description of each test in the

ControlNet network compliance tool.
ControlNet Network Compliance Tool
Test
ucmm.exe
mr.exe
cm.exe
cnet.exe
devobj.exe
Test cases
UCMM (unconnected message manager) executes these tests:
Criteria
Test
UCMM 2.3.1
accepts low-priority fwd_open service
UCMM 2.3.5
accepts low-priority fwd_close service
UCMM 2.3.2
accepts high-priority fwd_open service
UCMM 2.3.6
accepts high-priority fwd_close service
UCMM 2.3.10
accepts datagram service
MR (message router) executes these tests:
Test
Criteria
CM 5.3.1
can support at least one connection
MR 4.3.2
denies connection to non-existent class
CM 5.3.2
denies connection to existing connection
CM 5.3.6
closes an open connection
CM 5.3.7
denies closing a previously closed connection
CM 5.3.1
correctly routes a message not directed to itself
CM (connection manager) executes these tests:
Test
Criteria
CM 5.3.1
process open connection to MR
CM 5.3.2
denies connection containing connection serial
number from existing connection
CM 5.3.6
process close connection to MR
CM 5.3.7
process close connection to previously closed
connection
ControlNet object executes these tests:
Test
Criteria
CNET 7.3.1
powers up in listen-only mode
CNET 7.3.2
transitions to online via set_attribute_single service
CNET 7.3.3
reset service transitions from online to listen-only
CNET 7.3.4
will not transition to online via get_attribute_single
service
CNET 7.3.5
pending configuration scheduled rate=the current
configuration scheduled rate following power-up
CNET 7.3.6
pending configuration state=current configuration
state following power-up
CNET 7.3.8
responds to get_attribute_single service
device object executes these tests:
Test
Criteria
DEVICE 8.3.1
responds to get_attribute_all service
DEVICE 8.3.2
responds to reset service (power-cycle emulation)
2513
ControlNet Network Compliance Tool

Test
nvs.exe
Troubleshooting
Test cases
nonvolatile storage executes these tests:
Test
Criteria
NVS 11.3.1
responds to the get_attribute_single service
NVS 11.3.1
responds to the get_attribute_all service
This test:
CM 5.3.2
(part of cm.exe)
nvs.exe
Fails if:
the DUT supports multiple connections to the MR. This test
assumes that the DUT supports only one connection to the MR.
If the DUT supports multiple connections, the DUT should respond
with a general status code of 0x00.
the DUT does not support the NVS object
If a test fails:
1. View the display or test log file (.log) to determine which test
is failing.
2. Locate the failing test and its criteria in the table on page 2512.
3. Check the traffic analyzer display (.txt file) to determine what
packet was sent and the corresponding response from the device
under test.
4. Make the necessary adjustments to the device under test.
For additional assistance resolving test failures, contact the
Allen-Bradley Compliance Test Group.
2514
Notes:
Chapter
26
Developing A ControlNet
Conformance Test Plan
This chapter identifies the conformance plan for developers of
ControlNet products. This chapter contains these sections:
Purpose Of The Plan
Section
Page
Purpose Of The Plan
261
References
262
Requirements
263
Risks/Contingencies
263
Support Personnel And Resources
263
Audit Procedures
264
The test plan describes how conformance/compliance testing will be

completed by developers of ControlNet products. The test will
generate a go/no go result. The intended audience is anyone who
has an interest in such an activity.
Scope
The test plan covers three areas of product compliance:
physical
technology
application
Identification
Product developers that wish to make a statement of conformance to
the ControlNet standard must be tested according to this plan.
262
Developing A ControlNet Conformance Test Plan
Definitions
The following definitions, acronyms, and abbreviations are used in
this document:
"
References
Term
Explanation
CNet
Abbreviation for the ControlNet network.
Compliance
Verification of the existence of specific characteristics required by

standards (conformance).
Conformance
Verification of the existence of specific characteristics required by

standards (compliance).
Interoperability
The capability of products to communicate at application level with

little or no effort by users.
Compliance is not sufficient on its own, to guarantee

interoperability. However, it increases the probability that different
implementations are able to interoperate. Compliance testing does
not include robustness testing, (full system) interoperability testing,
acceptance testing or performance testing. The intent of compliance
testing is to give product developers confidence that an
implementation has the required capabilities and that its behavior
conforms consistently.
International Standard ISO 10303-31 Industrial
Automation Systems and Integration Product data
representation and exchange Part 31:
Conformance testing methodology and framework:
General concepts; ISO 10303-31:1994 (E)
Refer to the following documents when developing your test plan:

Chapter 24 ControlNet Conformance Criteria
Chapter 25 Using the ControlNet Network Compliance Test
Tool
Requirements
263
Conformance criteria are described in the documents listed in the

Reference section. The following documentation must be submitted
to Allen-Bradley for audit:
Any and all log files generated by the tests
Documentation of all product revisions and dates of testing
"
Microsoft Word is the suggested format for electronic submission.

Allen-Bradley will provide the following to product developers:
Executable images of testware and associated documentation
Retesting may be required if modifications are made to the product.
Decisions as to whether retesting is required will be based on the
scope of the intended modifications, consultation with
representatives from Allen-Bradley and conditions in the licensing
agreement.
Risks/Contingencies
Risks
The developer executing the test is responsible for performing the
test as described in the associated documentation.
Contingencies
If a product fails compliance testing, modification of the product or
test must take place and the product retested before the product is
released for sale. Exceptions to this rule can only be approved by
representatives from (at minimum) the product developer,
Allen-Bradley marketing, Allen-Bradley technology development,
and Allen-Bradley program management.
Support Personnel And

Resources
Allen-Bradley and the product developer will provide a point of

contact for all test-related issues.
264
Audit Procedure
Product developers are free to test as often as they wish. Documents

required for audit are listed in Requirements, on page 263.
Audit documentation must be provided to Allen-Bradley for all
released product versions.
Feedback to the product developer on the submitted audit
documentation will take place as soon as possible.
Chapter
27

The ControlNet network provides fast, deterministic scheduled data
transfer for control purposes and unscheduled nontimecritical
messaging for configuration and housekeeping on the same
network. This is accomplished by partitioning the bandwidth into a
scheduled portion that is guaranteed to be delivered within a
specified Network Update Time and a unscheduled portion that is
essentially the time remaining after the scheduled traffic is handled.
A critical user-supplied parameter for ControlNet is the Network
Update Time or NUT. This parameter is the base update rate of the
network, upon which all other slower rates of data transmission are
based.
Within each NUT, all nodes have a guaranteed time slice in which to
send their scheduled messages and data. Unscheduled messages are
sent after the scheduled messages within the NUT; there are 510
bytes of messaging reserved for unscheduled messages, in addition
to any unused scheduled time.
ControlNet configuration is composed of:
Network Configuration Data: this data is common to all devices
on the subnet, and must be identical for all devices on the subnet.
Device-specific Port Configuration Data: this data may be
unique for each device on the subnet, and supplies scheduling and
security information.
Device-specific Application Configuration Data
Device-specific NonVolatile Storage Data
Section
Page
Network And Port Configuration
272
Device-specific Application Configuration Data
273
Device-specific Non-volatile Storage Data
273
272
Introduction To ControlNet Configuration
Network And Port

Configuration
ControlNet network and port configuration parameters are stored and

distributed on the subnet from the ControlNet Configuration
Manager (CCM). The function of the ControlNet Configuration
Manager device may not be the devices primary function; there may
be many devices on the network that could function as the
ControlNet Configuration Manager, storing network and port
configuration data. The CCM with the lowest MAC ID is the
Master CCM; which actually distributes configuration data to all
kept devices on the subnet.
Configuration data is placed in each ControlNet Configuration
Manager with a programming device that is connected to the subnet.
Network Configuration data includes the Network Update Time
(NUT) and the Maximum Scheduled Node (SMAX); items that are
part of the Network Configuration are the same for all devices on the
subnet. The following are the Network Parameters:
nut_time
smax
umax
slot_time
blank_time
gb_start
gb_center
redundancy
int_cnt_mod
gb_prestart
273
Port Configuration data includes the maximum size of each nodes

scheduled data (scheduled_max_frames) and the number of NUTs
required to transmit a nodes data (macrocycle_length); see Chapter
30, ControlNet Rates, for a complete description. Port
Configuration data may vary from device to device on the same
subnet. The Port Parameters are:
sched_max_frame
status
macrocycle_start
macrocycle_length
macrocycle_count
macrocycle_multiplier
vendor
product type
product code
major revision
minor revision
serial_number
Device-specific
Application Configuration
Data
Device-pecific configuration data consists of data to specify:

Vendor
Device Type
Catalog Code
Revision Major
Revision Minor
Device-specific
Non-volatile Storage Data
Most devices possess writeable firmware, that may be updated from

a programming device in the network; this is very device specific.
274
Notes:
Chapter
28

The ControlNet network configuration is stored in devices on the
network that have non-volatile storage. These devices are capable of
updating other devices configurations; a device with this capability
is called a ControlNet Configuration Manager (CCM). One
device capable of performing the configuration manager function is
the PLC5 processor.
Configuration parameters that must be retained after a power failure
are stored in a CCM. All devices on a ControlNet network, except
for autoaddress nodes, have an entry in the CCM Reservation Table
and are called kept devices. It is the responsibility of the CCM to
distribute this configuration to kept devices.
Section
CCM Overview
Page
CCM Overview
281
Temporary CCM
282
Real CCM
283
Auto-address Node
285
Network Resource
285
The goal of real CCM powerup is to determine the current state of

the network, and then to act accordingly to either join the network,
fault or bring the devices on the network to a state where its real
configuration manager action will configure all the kept nodes on the
network.
During real CCM powerup, a CCM determines if it contains a valid
Reservation Table; if the table is valid, it proceeds with the
powerup sequence. If the CCM Reservation Table is not valid,
the temporary CCM powerup sequence is performed and the
unconfigured CCM becomes a temporary CCM until it is configured.
The CCM powerup sequence is executed whenever power is cycled
or when a Rogue or Duplicate Node condition is detected by the
CCM.
282
ControlNet Configuration Manager (CCM)
Temporary CCM
The goal of Temporary CCM powerup is to determine the current

state of the network and then act accordingly to either join the
network or bring the devices on the network to a state where
Temporary configuration manager action will configure all the kept
nodes with loose default network parameters and all port
parameters set to zero. In this state the network CCMs can easily be
configured by a programming device; then the real configuration
manager action of the configured Real CCMs will distribute the
configuration to all nodes on the network, and useful work can be
done.
A Temporary CCM operates in the absence of a configured real
CCM to maintain an existing network or establish a network with
Loose network parameters and zeroed port parameters. A
Temporary CCM will join an existing network that has no CCM,
adopt the existing network parameters, and bring any devices added
to the network online with the adopted network parameters and
zeroed port parameters. If no network is found during powerup, the
Temporary CCM will attempt to establish a network using loose
network parameters and zeroed port parameters.
Devices on the network established by the Temporary CCM can not
do scheduled messaging, because they are not completely
configured; for the network to be completely configured a real CCM
must be present, and it must have been configured for the network it
is connected to by a programming device.
A configured network whose CCM has been removed can continue
to do useful work; it can not be reconfigured until a real CCM is
returned to the network. If power fails on this network, it can not
recover and continue operating without the CCM.
The Temporary CCM repetatively broadcasts a scheduled Table
Unique Identifier (TUI) message that identifies itself as a
Temporary CCM, and allows for interactions between other
Temporary CCMs and Real CCMs. On networks with multiple
Temporary CCMs, the one with the lowest MAC ID does the TUI
broadcast.
The Temporary CCM does a repetitive unscheduled datagram
broadcast of loose network parameters and zeroed port
parameters. On networks with multiple Temporary CCMs, the
one with the lowest MAC ID does the datagram broadcast.
The Temporary CCM will stop broadcasting the TUI message and
enter a wait state if it hears a TUI from a real CCM or a TUI from
a Temporary CCM with a smaller MAC ID.
When a Temporary CCM is blocked by a real CCM, the
Temporary CCM will remember the TUI parameters broadcast by
the real CCM, so that if the real CCM is removed, the Temporary
CCM can maintain the TUI broadcast using the correct values.
Real CCM
283
A real CCM establishes a network after a powerfail condition and

maintains the network as devices are removed and replaced; a
programming terminal reconfigures the network by giving the CCM
updated information, which the CCM then distributes to all devices
on the network. To reconfigure an operating network, a
programming terminal performs the network change algorithm
described in this document; to alter the configuration of a particular
device, the programming tool must perform the Port Change
algorithm also described in this document.
A CCM will join an existing network only if the configuration
information stored in its Reservation Table matches the network
configuration; this is guaranteed if the Table Unique Identifier (TUI)
parameters of the CCM match the TUI parameters being circulated
through the network and stored in other CCMs.
If no network is established, the real CCM will attempt to establish a
network using the configuration stored in its Reservation Table.
The Reservation Table is maintained in NonVolatile Storage. If the
Reservation Table stored in NonVolatile Storage is not valid, the
real CCM will act as a Temporary CCM until it becomes configured.
284
A configured network whose CCM has been removed can continue

to do useful work; it can not be reconfigured until the real CCM is
returned to the network. If power fails on this network, it can not
recover and continue operating without the CCM.
The real CCM repetitively broadcasts a scheduled Table Unique
Identifier (TUI) message that identifies itself as the real CCM,
provides a CRC value of its Reservation Table. On networks with
multiple Real CCMs, the one with the lowest MAC ID is called
the Master CCM.
The CCM broadcasts its Table Unique Identifier (its current
Reservation Table CRC) and the Table Unique Identifier flag
word SCHEDULED at a rate of at least once every 4 PITs using
the Datagram broadcast service (that does not require a return
status).
The CCM device reserves 12 bytes of bandwidth for this purpose
(1 byte source node MAC ID, 1byte reserved status, 4 bytes TUI
+ 2 bytes TUI_flag + 4 bytes Lpacket overhead). The timeout
interval is defined as t = 2*UMAX*NUT. When a network is
operating with the Scheduled_max_frames parameter set to zero,
the ASIC will send the TUI message UNSCHEDULED.
The real CCM does repetitive CCM polling: unscheduled
broadcasts of the network parameters and specific port
parameters, to each device configured to be on the network, at a
rate of 2 per second. In addition, the real CCM does a datagram
broadcast of the Network Parameters (from the Reservation
Table) and zeroed Port Parameters; this brings autoaddress
nodes online quickly.
If a CCM goes Lonely while configuring, it will enter a Fast Start
state where it will Datagram broadcast its network parameters
(with port parameters zeroed); this will allow the CCM to form a
new network quickly, once more nodes are added to the network.
When the CCM is no longer Lonely, it will return to the normal
state and continue with the CCM polling algorithm.
Auto-address Node
285
An autoaddress node is a device that does not have a fixed MAC

ID. Currently, the only ControlNet devices that do not have a fixed
MAC ID are the KTC and KFC cards; these cards interface the
ControlNet Network to an IBM PC AT-compatible computer,
enabling the computer to be a ControlNet node.
An autoaddress node has a powerup sequence defined that allows
it to choose an unused MAC ID in the range between the Scheduled
Maximum (SMAX) and the Unscheduled Maximum (UMAX) Node.
UMAX is defined to be 8 more than SMAX; the largest SMAX is
99.
No autoaddress nodes defined to date have nonvolatile storage, so
they can not become the real CCMs.
Network Resource
Because the network configuration can be changed online, only one

programming device can be allowed to change the network at a time;
this is accomplished through the Network Resource. A
programming device must first acquire the Network Resource before
attempting any system changes. If the Network Resource is not
available, the programming device must wait. When a programming
terminal has acquired the Network Resource, it may modify and
update the network configuration stored in the networks Master
CCM; while the programming terminal has the Network Resource,
other programming devices are prevented from accessing the
configuration data in CCMs until the Network Resource is released.
The later action is useful when network parameters are altered and
the network must be reconfigured using the Network Change
procedure.
If a device asks to acquire the ControlNet Network Resource, the
Network Resource Object listens for the Network Resource
present message on the wire; if there is no Network Resource
present message, it can gain the Network Resource by
broadcasting the Network Resource present message.
The Network Resource present message must broadcast
periodically until the Network Resource is no longer needed.
The network resource present service should be broadcast
SCHEDULED using fixed tag 85 every 4 NUTs, while the
network resource is in use. Because it is broadcast
SCHEDULED, this message must be guaranteed to be sent every
attempt. Devices that will send the Network Resource Present
Message must reserve 6 bytes in each NUT for the transmission
of this message (4 bytes Lpacket overhead + 1 byte for MAC ID
parameter and 1 byte for the flag word).
286
"
Often a device will broadcast both the Table Unique Identifier

and the Network Resource message; these messages may not be
broadcast in the same NUT. In this case the TUI and NR
messages are sent in different PITs, so it is necessary to reserve
space in each NUT for only the larger of the two messages.
Under some circumstances, a Temporary CCM must broadcast
the Network Resource Present Message when the
scheduled_max_frame for the device is 0.
In this case the Network Resource Present should still be
broadcast; the SMAC chip will send the packet unscheduled and
generate a blockage interrupt. There each node is guaranteed to
get an opportunity to send unscheduled data every n PITs, where
n is equal to the number of actual unscheduled nodes. Since the
number of unscheduled nodes cannot exceed UMAX, we can
safely use UMAX as the value for n. Therefore the worst case
network resource present transmission rate is once every
UMAX times NUT time; to be safe, we specify the timeout for
the Network Resource Present message to be 2*UMAX*NUT.
Valid NUT times are 2100 msec.
Chapter
29

The network parameters must be the same in all devices on a given
network; these parameters define the network for the ASIC in each
device. A programming device is required to query the user for the
basic parameters like the Network Update Time, cable lengths,
repeater count, SMAX, UMAX, etc. used in the calculations to
determine the remaining network parameters, such as Guardband
and Slot time.
Port parameters are specific to each device on the network; different
devices have different port parameters and identical devices may
have some different port Parameters. Port parameters include those
related to specifying message transmission rates.
See the ControlNet object description in Appendix A for more
information.
Network Parameters
Section
Page
Network Parameters
291
Port Parameters
293
The NUT (Network Update Time) is one of the network parameters

that must be configured on the network; because not all network
traffic needs to be sent at a high rate, it is necessary to be able to
schedule the transmission of data at rates slower than the NUT.
This is accomplished by placing slower scheduled traffic into a
group called the Macrocycle; a Macrocycle is a binary multiple of
the NUT. The Macrocycle is then grouped together to define the
slower rates required by the network.
The maximum amount of scheduled data that can be sent by a node
in one NUT is 510 bytes.
Each device on the ControlNet network is assigned a unique
identifier called the MAC ID. Mac IDs range from 1 to 99.
The scheduled maximum number of nodes, SMAX, can range from 1
to 99; the unscheduled maximum number of nodes UMAX is defined
to be 8 more than SMAX. The MAC ID for each device on the
ControlNet network is typically set through a switch located on the
device (except for autoaddress nodes like the KTC and KFC).
292
Network And Port Parameters
NUT
The Network Update Time in 10 microsecond tics; a basic network
parameter that determines the fastest transmission times over the
network. The smallest value for the NUT is 2 milliseconds (200
ticks).
smax (USINT)
The Scheduled Maximum Node MAC ID on the network (199).
This parameter is the MAC ID of the last node which obtains
scheduled access; it should be set to reflect the actual highest MAC
ID of all the devices on the network. Specifying more MAC IDs
than are actually present will waste small amounts of the network
bandwidth.
umax (USINT)
The Unscheduled Maximum Node MAC ID on the network, used by
autoaddress nodes (at least smax + 8); it is the MAC ID of the last
node which obtains unscheduled access to the network.
slot_time (USINT)
The Slot Time is the time that nodes wait to see if the node which
currently has the token is going to use it. The actual value used for
the slot time depends on the length of cable used in the network and
the number of repeaters present.
blank_time (USINT)
The Blanking Interval, in bytes; assumed to be a constant (6 bytes);
this is the time in bytes that the receiver will be deaf after a
transmission. (This helps avoid problems with echoes on the
network.
gb_start (USINT)
The Guard Band Start, in 10 microsecond ticks is the time before the
next ASIC tone where the guardband should start. This is a
calculated parameter based on the NUT parameter, number of
repeaters and cable lengths.
293
gb_center (USINT)
The Guard Band Center, in 10 microsecond ticks, is the time before
the next ASIC tone, where the moderator will begin transmitting the
moderator frame. This is a calculated parameter based on the NUT
parameter, number of repeaters and cable lengths.
redundancy: Redundancy Control (USINT)

The Redundancy Mode Control bits are the 2 least significant bits
of the byte.
Bit 0 set selects channel B only.
Bit 1 set selects channel A only.
Bits 0 and 1 set selects redundant media; the modem selects between
A and B.
int_cnt_mod (USINT)
Interval Count Modulus is fixed at 255. The interval count can be
adjusted to allow for nonpoweroftwo macrocycles.
gb_prestart (USINT)
The Guard Band Prestart, in 10 microsecond ticks, is the time before
the next ASIC tone beyond which nodes may not transmit.
A calculated parameter based on the NUT parameter , number of
repeaters and cable lengths. (This parameter is larger than gb_start
to allow for propogation delays and clock mismatch.)
Port Parameters
The port parameters are device specific data, associated with each
possible MAC ID in the network (1 thru 99).
sched_max_frame (USINT)
The sched_max_frame is a parameter limiting the amount of
scheduled traffic which can be generated by a node. A value of 0
indicates the node will not transmit scheduled data; anything sent
scheduled will instead be placed into the unscheduled bandwidth.
This parameter is a number of 16-bit words between 0-255.
294
status (USINT)
CCM status:
bit 0 = 0 for a future reservation and bit 0 = 1 for a current
reservation.
bit 1 = 0 for a nonCCM device, bit 1 = 1 for a CCM.
macrocycle_start (USINT)
The nodes macrocycle start NUT number, used to schedule data from
multiple nodes on the network. A value of 0 means that the
macrocycle will start on this nodes first NUT. The macrocycle_start
value is less than or equal to the macrocycle_length. (This parameter
is not currently used by ControlNet Phase 1.0.)
macrocycle_length (USINT)
The number of NUTs required for the nodes data minus 1; a value
of 0 implies a single NUT macrocycle, where the node will transmit
scheduled data every NUT. (This parameter is set to the fastest rate
of the ControlNet node.)
macrocycle_count (USINT)
Number of consecutive NUTs within a macrocycle allocated to the
scheduled rate (0 128); values of macrocycle_count less than
macrocycle_length indicate that a node is expected to not transmit
during portions of the scheduled rate. A value of 0 indicates the
node will not transmit during the scheduled portion of the NUT.
(This parameter is not currently used by ControlNet Phase 1.0.)
macrocycle_multiplier (USINT)
Array of bits used to specify which rates to enable in a device
[1,2,4,8,16,32,64,128]. The number of NUTs in a nodes macrocycle
determines the fastest possible data rate; the multiplier sets the
nodes data rates based on the macrocycle rate. A nodes macrocycle
is the nodes fast data production rate and a multiple of the
macrocycle will be one of the nodes slow data production rates.
A value of 0 for the macrocycle_multiplier means the fast and slow
rates are equal. For nodes which support only a fast and slow rate,
the multiplier represents the number of macrocycles for the single
slow rate.
Chapter
30

The term rate refers to the guaranteed messaging speeds provided by

scheduled transmissions on the ControlNet network; multiple rates
implies multiple guaranteed message transmission speeds.
Network Update Time
Section
Page
Network Update Time
301
Possible Schedules
304
Multiple Rates
305
Accepting/Rejecting Connections
306
Order Of Connections
307
ControlNet Rates Implementation
308
Sample Breadth-first Accept/Reject

Algorithm
309
Sample Delete Algorithm
3012
ControlNet nodes can support 0 to 8 different schedule rates.

Nodes that support 0 rates will not be permitted to send scheduled
data. (They can still send unscheduled data.) Most nodes will
support 1 or 2 scheduled rates. The fastest rate for a node is called
the macrocycle of the node and the slowest rate for a node is simply
called the slow rate of the node. All of the rates must be binary
multiples of the Network Update Time (NUT).
The Network Update Time is a critical user-supplied parameter for
the ControlNet network. This parameter is the base update rate of
the network, upon which all other slower rates of data transmission
are based.
Within each NUT all nodes have a guaranteed time slice in which to
send their scheduled messages and data. Unscheduled messages are
sent after the scheduled messages within the NUT; there are 510
bytes of messaging reserved for unscheduled messages, in addition
to any unused scheduled time.
The valid NUT multipliers are 1, 2, 4, 8, 16, 32, 64, and 128.
The macrocycle can be 1, 2, 4, 8, 16, 32, 64 or 128 NUTs long.
If the device supports a single rate, then the macrocycle and slow
rate for that device are equal. Some devices, such as the 1771-ACN,
must have their fast rate equal to the NUT; other devices like the
1794-ACN permit their fast rate to be a binary multiple of the NUT.
302
ControlNet Rates
A ControlNet node must be configured with network parameters that

define the NUT and the network characteristics; all nodes on the
network must have the same network parameters.
When a node is first poweredon, it adapts loose network
parameters and waits in a listen-only state for a CCM or Temporary
CCM to communicate with it and bring it online with specific
network and port parameters.
Before an node can send scheduled traffic, it must have its unique
port parameters initialized so that the ASIC knows the size of the
messages it will be transmitting, and the rates involved; a node with
default (zeroed) port parameters is only capable of unscheduled
messaging.
The Network Update Time includes:
the Scheduled Interval, where the (implicit) Scheduled Token is
passed around once
the Unscheduled Interval, where the (implicit) Unscheduled
Token is passed around as many times as possible
the Guardband or Moderator Slot, in which the Moderator frame
falls
Figure 30.1
Structure of a Network Update Time
.
Scheduled
Lpackets
Network Update Time
Scheduled
Interval
Unscheduled
Lpackets
Unscheduled
Interval
tone
moderator
slot, alias
the guardband
The tone is the instant in time which marks the boundary between
two periodic intervals. It is considered to be the first event in the
Periodic Interval. There is a gap of 20 microseconds between the
tone and the first scheduled interval transmission slot.
ControlNet Rates
303
The Scheduled Interval is the portion of the Periodic Interval

immediately following the tone, where the scheduled traffic is
transmitted. The Scheduled Intervals duration in any given NUT is
equal to the amount of time it takes to pass around the (implicit)
Scheduled Token one time.
Scheduled Messages or Scheduled Traffic refers to Lpackets
intended for transmission in the Scheduled Interval within the NUT.
These Lpackets receive deterministic (hence the term scheduled)
delivery service. Lpackets which for any reason dont fit in their
Scheduled Interval, or which arrive too late to be sent there, may be
transmitted in the subsequent Unscheduled Interval, along with the
nondeterministic traffic normally appearing there. These tardy
Lpackets may not receive deterministic delivery in such a case.
A programming tool that generates the configuration for each node
should never allow this situation to occur.
Unscheduled Messages or Unscheduled Traffic refers to
nondeterministic Lpackets, which are excluded from transmission
during the Scheduled Interval, and are transmitted in the time
remaining after the last scheduled transmission and during the
unscheduled interval. These include reply Lpackets generated by the
ASIC itself, and any Lpackets so identified when supplied by the
ASICs host.
Example: Assume a device is programmed to support a single rate that is equal to 2
NUTs. The corresponding Port Parameters are:
macrocycle_length = 1
macrocycle_multiplier = 0
We will assume that transmission starts at NUT 0 and that no restrictions have been
placed on which NUTs can be used for transmission.
Schedule_max_frames = 50 words (100 bytes)
nut_time = 500 tics (5 milliseconds)
If two 100 byte (or larger) 10 ms scheduled connection requests to transmit are received,
request a and b, the connection manager should accept both of them, assuming
application resources are available.
Both a and b must be transmitted every 10 ms.
304
ControlNet Rates
Possible Schedules
Macrocycle
NUT 0
Case 1
Case 2
Case 3
NUT 1
a,b
a,b
Case 1 is a valid schedule. Here packet a is scheduled to be sent

in NUT 0 in the scheduled portion of the NUT, and packet b is
scheduled to be sent in NUT 1 in the scheduled portion of the
NUT.
Case 2 is not a valid schedule, because we can not guarantee that
packet b will always be transmitted in the desired time frame,
because of network loading.
Here packet a is scheduled to be sent in NUT 0 in the scheduled
portion of NUT 0, and packet b is scheduled to be sent in NUT 0
during the unscheduled portion of the NUT. Packet b is not
guaranteed to arrive during NUT 0 because unscheduled
bandwidth may not be available to each node every NUT, but
there is still available bandwidth in the scheduled portion of NUT
1. When unscheduled bandwidth is not available in NUT 0, this
case will attempt to send data at the same time as case 1.
Case 2 has more jitter than case 1; the data probably will arrive
within the scheduled macrocycle, although this is not guaranteed.
In situations where the amount of scheduled and unscheduled
traffic varies, packet b could experience enough jitter to violate
the schedule.
Case 3 is not a valid schedule. Here no data is scheduled to be
sent in NUT 0, assuming that there will be sufficient unscheduled
bandwidth available to send packet b in the unscheduled portion
of NUT 1. There is no difference between Case 2 and Case 3.
In both cases, it is possible for packet b not to be sent on some
macrocycles and sent twice on others.
ControlNet Rates
Multiple Rates
305
Example:
Rate 1
= Once every 2 NUTs (Macrocycle)
Rate 2
= Once every 4 NUTs
Rate 3
= Once every 8 NUTs (Slow Rate)
Network Parameter:
nut_time = 500tics (5 milliseconds)
Port Parameter:
Schedule_max_frames = 50 words (100 bytes) per NUT
macrocycle_length = 1 (2 NUT macrocycle)
macrocycle_multiplier = 6 (rates of 1, 2 and 4 times the macrocycle enabled)
Fwd_opens:
(a) 50 bytes @ 10msec (Rate 1)
(b) 60 bytes @ 10msec (Rate 1)
(c) 30 bytes @ 20msec (Rate 2)
(d) 40 bytes @ 40msec (Rate 3)
After the forward opens have been received the following schedule
should be created.
"
The data sent during each NUT is less than sched_max_frames.

Macrocycle 0
Macrocycle 1
Macrocycle 2
Macrocycle 3
NUT 0 NUT 1 NUT 0 NUT 1 NUT 0 NUT 1 NUT 0 NUT 1

Packets scheduled a,c
a
50
b
c
50
60
a,c
50
60
30
d
Total bytes
b,d
50
60
60
30
40
80
100
50
60
80
60
50
60
If the additional connection request, listed below was received,

it should be rejected because it could not be scheduled.
Fwd_open:
(e) 30 bytes @ 10 msec (Rate 1)
306
ControlNet Rates
If this same connection request was received at a slower rate it

should be accepted.
Fwd_open:
(e) 30 bytes @ 20 msec (Rate 2)

Macrocycle 0
Macrocycle 1
Macrocycle 2
Macrocycle 3
NUT 0 NUT 1 NUT 0 NUT 1 NUT 0 NUT 1 NUT 0 NUT 1

Packets scheduled a,c
a
b
c
b,d
50
a,c
50
60
30
a,e
50
60
60
30
40
Accepting/Rejecting
Connections
50
60
d
Total bytes
a,e
30
80
100
30
80
60
80
60
80
60
It is the responsibility of the Transport software to determine

whether a connection can be established without violating the
sched_max_frames of any NUT. To do this, the Transport should
know which NUT data is scheduled to be transmitted. The Transport
distributes the allocation of bandwidth within a macrocycle by
allocating bandwidth on breadth first basis.
Bandwidth is allocated and checked on a NUT basis. In the
following example, 99 bytes of data is attempted to be scheduled into
two 50 byte NUTs, but it fails because the individual packets cannot
be schedule into an available NUT.
Example:
Rate 1 = Once every 2 NUTs
NUT = 5 msec
Sched_max_frames = 50 bytes
macrocycle_multiplier = 0 (a rate of 1 times the macrocycle is enabled)
The third forward open would fail:
Fwd_opens:
(a)
33 bytes @ 10 msec
(b)
33 bytes @ 10 msec
(c)
33 bytes @ 10 msec
ControlNet Rates
307
A network that has been configured with a programming tool should

never experience an open failure due to insufficient bandwidth;
the programming tool should provide sufficient bandwidth for all
expected connections.
Order Of Connections
Because the packing of connection request into schedule slots is not

always optimal, it is possible for some connections to be rejected that
would have fit in a previous ordering. The probability of this
occurring increases as the limit for a device is approached.
"
In the following example all connections are accepted.

Example:
Rate 1= Once every 2 NUTs (Macrocycle)
Network Parameter:
nut_time = 500tics (5 milliseconds)
Port Parameter:
Schedule_max_frames = 50 words (100 bytes) per NUT
macrocycle_multiplier = 6 (rate of 1 times the macrocycle enabled)
Fwd_opens:

Macrocycle
Packets scheduled
a
NUT 0
NUT 1
a,c
b,d
60
b
c
70
40
d
Total bytes
30
100
100
308
ControlNet Rates
If the order of the forward opens were changed, the 4th connection
would be rejected.
Fwd_opens:

Macrocycle
Packets scheduled
a
NUT 0
NUT 1
a,c
60
b
c
Total bytes
70
30
90
70
Ideally a programming tool could calculate the worst possible

schedule that could occur and if this schedule does not have
sufficient bandwidth to handle all the required traffic, the user should
be forced to alter the setup and try again.
ControlNet Rates
Implementation
The general approach for determining the schedule for transmitting

data assumes that a base Network Update Time has already been
chosen; then based on the device types listed in Table 30.A, worst
case message sched_max_frames are determined and the schedule is
formed. The schedule should include some extra pad bytes
(approximately 20 percent more than is actually required) so that
extra connections can be handled with a Port Change, without
resorting to the more disruptive Network Change. Phase 1
ControlNet scheduling does not include the pad bytes because
Port Change is not implemented. If the final schedule cannot be
made with the chosen network parameters, the NUT and the chosen
transmission rates must be adjusted and the scheduling done again.
The schedule that is generated is for transmission only; it does not
apply to message reception.
ControlNet Rates
309
Table 30.A
Example ControlNet Devices
Device
Programming Tool
Scheduling Requirements
End Node Transmission

Scheduling
1794 ACN Modular Block
Fixed
One Connection Only
1771 ACN
Fixed for Discrete I/O
Breadthfirst transmission
scheduling
Analog: Reserve Space in

each NUT for the largest
block transfer to be
processed.
PLC5
Uses actual I/O present to

find worsecase values.
Schedule created in the

programming tool is
downloaded to the PLC5
processor.
A schedule is created using

the ControlNet Breadthfirst
algorithm.
Sample Breadth-first
Accept/Reject Algorithm
MinniScanner
Same as the 1771 ACN
scheduling
ICP ACN/SCN
Same as the 1771 ACN
scheduling
(Transmission only, does not apply to receive)
slow_size = # of NUTs in slowest rate;

Create array
Scheduled_bytes[slow_size];
Create array nut_ptr[# of rates];
Create array rate[# of rates module supports];
Create struct schedule *entry
/* Sched bytes array, per NUT */

/* Pointer to NUTs within a rate */
/* Specifies number of NUTs in each rate */
/* One entry in the master schedule
*/
Set all Scheduled_bytes[] = 0;

Set all nut_ptr[] = 0
;
For each connection request
{
rate_index = index to rate closest to EPR without going over
remaining_attempts = rate[rate_index] /* Try all NUTs within a macrocycle */
Do
{
/* Test for fit for a NUT within the macrocycle*/
fit = GOOD;
/* Test all relevant NUTs within the slowest rate for fit */
/* NUT_ptr points to the next available NUT */
For( i = 0; i <= slow_size; i = i + rate[rate_index])
If (Scheduled_bytes[nut_ptr[rate_index] + i] ) +
size_of(new_connection) > sched_max_frames)
{
fit = BAD;
break;
}
If (fit = GOOD)
{
/* Accept connection
*/
/* Add new connection to schedule by adding */
/* the message length to the appropriate array elements */
For( i = 0; i <= slow_size; i = i + rate[rate_index])
Scheduled_bytes[nut_ptr[rate_index] + i] =
Scheduled_bytes[nut_ptr[rate_index] + i] +
3010
ControlNet Rates
size_of(new_connection);
/* Move nut_ptr to next entry in the Scheduled_bytes */
/* array, corresponding to the next NUT.*/
/* The nut_ptr can not be shifted by a number */
/* greater than the Rate */
/*
For multiple connections this forces */

/* Breadthfirst filling of the NUT sched */
nut_ptr[rate_index] = (nut_ptr[rate_index] + 1)
Mod (rate[rate_index]);
break;
}
If (fit = BAD)
If(remaining_attempts > 0)
{
/* Move NUT_ptr to next entry in the */
/* Scheduled_bytes array, corresponding to the next NUT.*/
/* Maybe there will be enough room there.
*/
/* The NUT_ptr can not be shifted by an number greater */
/* than the Rate */
nut_ptr[rate_index] =
(nut_ptr[rate_index] + 1)
Mod (rate[rate_index]);
remaining_attempts;
}
Else
{
/*
reject connection;
*/
break;
}
}
While( );
/*
Update the master schedule
*/
if (fit = GOOD)
{
/*
Get a blank entry from the master schedule
entry = get_entry_from_list ();
*/
/*
Add the information for the new connection */
/*
into the master schedule entry */
entry>size = sizeof (new_connection);
entry>rate_index = rate_index;
entry>nut_ptr = nut_ptr[rate_index];
entry>tag = tag;
/*
Place the updated entry into the master schedule */
update_entry_pointers (entry);
}
/*
Pass updated master schedule to the Transport, */

update_transport ();
ControlNet Rates
3011
Consider an example where the fast rate (macrocycle) is 2 times the

NUT, and there are three rates supported: the macrocycle, 2 times the
macrocycle, and 4 times the macrocycle. The port parameter settings
required to specify this are:
macrocycle_length = 1
(2 NUT macrocycle)
macrocycle_multiplier = 6 (rates of 1, 2 and 4 times the macrocycle are enabled)
In the diagram below, if the macrocycle is 2 NUTs, the nut_ptr will

successively point to Scheduled_bytes[0], Scheduled_bytes[2],
Scheduled_bytes[4] and Scheduled_bytes[6].
For the Rate = 2 times the macrocycle, the nut_ptr will successively
point to Scheduled_bytes[0] and then Scheduled_bytes[4].
In the algorithm, if the fit is BAD, the nut_ptr will be shifted one
array element at a time (corresponding to one NUT at a time) until a
fit is made ; then the next Scheduled_bytes array element, offset by
the Rate, is checked, etc. as described above. If the number of array
elements checked is greater than the desired Rate, the desired
connection can not be made.
Macrocycle
NUT
Rate 1 (macrocycle)
rate = 1*macrocycle (every 2 NUTs)

NUT_ptr[1]
Rate 2

NUT_ptr[2]
Rate 3 (Slow Rate)

NUT_ptr[3]
nut0nut1nut2nut3nut4nut5nut6nut7
Schedule
3012
ControlNet Rates
Sample Delete Algorithm
This algorithm finds the information in the master schedule about

the connection to be deleted, subtracts the message length from the
appropriate entries in the Scheduled_bytes array, removes the entry
from the master schedule, and then calls the transport, assuming it
will use the updated master schedule to break the desired connection.
Set all nut_ptr[] = 0
For each deletion request

{
/*Get the entry to be deleted from the schedule
*/entry = get_entry_from_tag ();
/*Get index to the Rate of the traffic to be deleted */
del_rate_index = entry>rate_index;
/*Get the value of the nut_ptr used to accept the connection */
local_nut_ptr = entry>nut_ptr;
/*
Subtract the message size from the appropriate NUTs */
for (i=0; i<=slow_size; i = i + rate[del_rate_index])
{
Scheduled_bytes[local_nut_ptr + i] =
Scheduled_bytes[local_nut_ptr + i] entry>size;
}
/*
Delete the entry from the schedule. */
delete_entry (entry);
/*
Notify the Transport about the traffic to be deleted */
delete_from_transport ();
)
Chapter
31

An offline configuration can be developed in a programming tool,
and later downloaded to a new or operating network. In either case,
the Network Change procedure must be followed to configure CCMs
and insure an orderly configuration of all kept devices.
If the programming tool must query a CCM to determine the
existing network configuration before continuing with an offine
configuration, it must first listen for the Network Resource
Present Message; if the message is detected, it must not access
any CCM on the network until there is no Network Resource
message detected for time of 2*UMAX*NUT.
While the terminal is accessing the CCM data, it must broadcast
the Network Resource Present Message, with the NR_flag bit 0
set to 1; this will lock out other programming terminals and
permit the CCMs to return to their normal operating state once
the NR message stops.
Offline configuration is identical to the online configuration,
with the exception that pending edits will not appear in the offline
configuration because the auto-configuration command will not
work offline.
This can be accomplished by using a driver for the offline
configuration that allows the programming device to operate as
though it were online.
Once the new configuration is downloaded to the controller,
a Network Change will occur to reconfigure the CCM and in turn
each device on the subnet.
312
Offline Configuration
Notes:
Chapter
32

A programming terminal finds devices on a link by using the WHO
command, once the devices are online through Real or Temporary
CCM action. The who command allows an application to identify
all the devices connected to either a specific ControlNet subnet or the
entire ControlNet network. The devices are identified by Keying
and Ownership data: vendor, module type, revision and serial
number.
Since all devices have an Identity object, who is just a
get_attributes_all to the Identity object.
When the programming tool must query a CCM to determine the
existing network configuration, it must first listen for the
Network Resource Present Message; if the message is detected,
it must not access any CCM on the network until there is no
Network Resource message detected for time of 2*UMAX*NUT.
While the terminal is accessing the CCM data, it must broadcast
the Network Resource Present Message, with the NR_flag bit 0
set to 1; this will lock out other programming terminals and
permit the CCMs to return to their normal operating state once
the NR message stops.
In general, the programming terminal must continue to broadcast
the Network Resource message until the programming terminal is
removed from the network.
If a Network Change or Port Change is performed, the Network
Resource NR_flag bit 0 will be set to 0, as part of the change
procedures; this will place the CCM on the subnet into a waiting
state, and allow the CCM to perform an abort change procedure
if the Network Resource Message stops for longer than
2*UMAX*NUT.
322
Online Configuration
Notes:
Chapter
33
Who Command (For Active And

Inactive Nodes)
This service allows the user application to identify all the devices
connected to either a specific ControlNet subnet, or the entire
ControlNet network. If the who is for the entire network, this
function will identify devices connected directly to the ControlNet
network, as well as modules that reside in a connected backplane.
The devices will be identified by vendor, module type, revision and
serial number.
Functionality
Section
Page
Functionality
331
Suggested Algorithm
332
Function
who( path, who_list)
Table 33.A
who() Parameters
Parameter Name
Description of Parameter
path
A pointer to the connection path (relative address) of the subnet

on which to perform a Who. For performing a who on the local
subnet, or performing a network wide who, this parameter
should be NULL.
who list
Who_list will point to the list of devices found when the function
returns. Identifying information includes vendor, module type,
revision, status and serial number.
Returns
General Status Error Codes
Behavior
The who function is a breadthfirst search of the ControlNet network
or backplane. It consists of sending an unconnected
Get_Attributes_All message to the Device object of every possible
MAC ID on the ControlNet network, and to every possible slot
number on the backplane. The who must be able to handle circular
networks.
332
Who Command (For Active And Inactive Nodes)
Suggested Algorithm
The following algorithm outline may be used to implement the who

function. This who is performed in a series of steps, listed below:
1. Find umax for the subnet on which to perform a who.
Send a Get_single to the ControlNet object of a device on the
target subnet.
2. Send a Get_Attributes_All via an unconnected message to the
Device object of every possible MAC id from 1 to umax.
The device will respond with all of the attributes contained in its
Device Object, thus identifying the device.
Chapter
34

Changing the network parameters on a ControlNet network requires
that control be stopped for a period of time while the network
parameters are changed. It is analogous to a warm boot.
The network will start again without removing the power.
A Network Change allows the user application to change the
attributes of all devices on one subnet of the ControlNet network at
the same time. By convention, only a network configuration
application may perform a Network Change of any subnet.
This service allows the user application to change the attributes of all
devices on one subnet of the ControlNet network at the same time.
By convention, only a network configuring application may perform
a Network Change of any subnet on the ControlNet network.
Functionality
Section
Page
Functionality
341
Algorithm
342
Function
net_change( path, network parameters, port parameters, time)
Table 34.A
net_change() Parameters
Parameter Name
path
A pointer to the path (relative address) of the subnet

to be changed. For changing the local subnet, this
parameter should be NULL.
network_parameters
A pointer to the parameters valid for the entire

ControlNet network. (This is the pending_net_config
attribute of the ControlNet object.)
port_parameters
An array of pointers to parameters for each

individual device on the ControlNet network.
There is one for each possible devices MAC ID from
199.
time
Number of network update times (NUTs) to wait

before synchronizing the attribute changes.
Accepted values are 10255.
Returns
342
Network Change
Behavior
The network change must minimize the risk of creating rogues on
the network. To do this, it will reset all nonCCM devices, thus
making them listenonly, until the sync change is complete. CCM
objects on the ControlNet network will have their attributes updated
and the ControlNet object in the same device will receive the new
parameters. After the sync command is complete and the sync
change is verified, the CCMs will be signalled to begin polling, and
will bring the nonCCM devices back online with the new, correct
parameters.
Algorithm
Services Required
Network Stop Causes a change into the associated Net
Change state, no other action for both CCM and Temp.
Apply Copy from current into non-volatile storage (CCM
only)
Abort Copy from NonVolatile storage into current (CCM
only); change state from Net Change into associated state (both).
Change Complete Causes a change from Net Change state
into associated state (both)
State Behaviors
Net Change state assumes that a CCM stops polling and stops
broadcasting a TUI
Set_attributes is only accepted in any of the three Net change
states
Reservation Table
The CCM object has only a current and nonvolatile copy of the
RT. The pending copy is eliminated. If it is needed for some
reason other than making a network change, the Network Change
procedure can be modified to accommodate it, and the above
definitions of the CCM/ temp CCM services must be revised.
Network Change
343
Changes/Assumptions About Connection Manager and

ControlNet Object
At some point during the change, all connections must be broken and
disallowed until after the change, since the new parameters may
make the connections invalid. A suggested method of doing this:
1. When any ControlNet object receives a Reset command,
it causes an indication to be sent to the connection manager.
2. When the connection manager receives this indication, it locally
closes the connections (but does not send any close messages).
3. The connection manager reinitializes the transports, and rejects
further connections.
Another solution to breaking connections is to create a new service
to the connection manager to break and disallow connections.
It is assumed that when a node finishes powerup, the connection
manager will automatically allow unscheduled connections, and
scheduled ones are allowed as soon as the bandwidth is allocated
(i.e., the nodes get their full ControlNet parameters from a CCM ).
A related change to the ControlNet object is to make the object

notify the connection manager or transport when it applies new
parameters to the ASIC (this would mean sending a tminus done
indication). The connection manager or transport would then
perform a get attributes to get the new parameters from the object.
Assumptions Prior to Starting the Network Change

the network change procedure is supplied with a new reservation
table (RT)
the new RT is correct and valid for the subnet being changed
the network change procedure is told who the CCMs are (this info
is stored in the CCM RT attribute 1)
a broadcast is not received by the sender (a separate local msg is
needed if the sender must get this msg)
a lonely interrupt does not transition out of any net change
state in the CCM or Temporary CCM
the sender (application doing the change) is either directly
connected to the ControlNet or has a proxy
344
Network Change
Network Change Description

(Use this section with Figure 34.1.) These notes are to illustrate the
behavior of CCM, temp, and kept nodes through each step of the
network change. From step 1 to step 8, all CCMs and temp CCMs
powering up will be stuck in the checkformod box (due to the
network resource being broadcast) in their powerup sequence. From
step 2 through step 8, all kept nodes powering up will be stuck
waiting for a CCM to set their ControlNet object parameters.
These notes also describe what happens if the sender of the net
change goes away or has a power glitch in the middle of the
procedure, and contains descriptions of problems that may be created
by this procedure.
Network Change
345
Figure 34.1
Network Change Flowchart
Steps 1 and 2
Start Broadcasting Network
Resource, with NR_flag bit 0 =
0; all CCMs and temp CCMs
receiving this message will
perform the Network Stop
service, to enter the Net
Change state.
Distribute & Verify New RT

(series of set_attribute messages
to each CCM on the list provided)
4
Broadcast apply_attribute message
(3 times plus send to self). Set
NR_flag bit 0 = 1 in subsequent NR
broadcasts.
Lonely or
Continue
6
Local Set_attribute to my
ControlNet object with new
parameters
Broadcast reset message until lonely; if

lonely is not achieved after 5 seconds,
give the user a choice:
1. Abort and repeat steps 3 and 4 with
the old network and port parameters;
then the user can correct the problem.
2. Continue on; this will force all nodes
not participating in the
network change to go Rogue.
Abort
7
TUI flag bit 0=1 (valid)
bit 1 = 1 (real)
Broadcast a set_attribute to the
bit 2 =0 (temp set)
ControlNet object with new params
(3 times)
Moderator starts when
another node comes online
8
Stop broadcasting Network
Resource
Keepers and Temps will

start through powerup
9 Local change_complete (to return

sender to a keeping state in case
the sending node is a CCM or temp
CCM)
346
Network Change
1. Get the Network Resource

Behavior of
ffect of sender power

po er off/glitch
off/ litc after this
t is step
Effect
CCM
TEMP
KEPT
no change
no change
no change
none
2. Stop CCM polling function (NR_flag bit 0 set to 0)

Behavior of
CCM
TEMP
Transition to the associated

net change state
Effect of sender power off/glitch

after this step
KEPT
no change
The CCM will be stuck in the net

change state (because the NR_flag bit
0 is set to 0) until the CCM detects the
loss of the NR message (after waiting
2*UMAX*NUT); then the CCM in the
Net Change state will perform the
Change Abort service. The Change
Abort service will restore the
Reservation Tables from non-volatile
storage.
no change
3. Send the new RT to the CCM.

This can be connected or unconnected, but cannot be a broadcast.
The positive reply to each message serves as a verification.
(If a message fails, you can resend the message, or, if you are tired of
retrying, broadcast an abort (datagram, 3 times). This causes the
CCM to copy from NV into the CCM object current and causes a
state transition out of net change for the CCM. Kept nodes ignore
an abort message.
Behavior of
CCM
TEMP
RT is put into the

CCM object
no change
KEPT
no change
Effect of sender power off/glitch after this

step
The CCM will be stuck in the net change
state until the CCM detects the loss of the NR
message (after waiting 2*UMAX*NUT); then
the CCM in the Net Change state will perform
the Change Abort service. The Change Abort
service will restore the Reservation Tables
from non-volatile storage.
Network Change
347
4. Broadcast ApplyAttribute to make CCMs copy RT to NV

storage, and leave the net change state.
Set the broadcast NR_flag bit 0 to 1 for subsequent broadcasts
Aborts are no longer valid after this step. Once NV is changed,
theres no going back (unless you do the change all over with the
old parameters).
Behavior of
CCM
TEMP
Copy RT into NV storage
KEPT
no change
no change
Effect of sender power off/glitch after

this step
Nodes powering up after the sender dies
will steal the moderator parameters (which
are old). If a CCMs reservation table is
old it will start keeping; otherwise it will
fault.
5. Broadcast reset all until Lonely
ATTENTION: Under no circumstances should the

sender receive this message and reset itself.
If the Lonely state can not be obtained after 5 seconds, then the
user must choose one of two options:
A. The Network Change may be aborted; steps 3 and 4 must be
repeated with the old saved network and port parameters.
Then the user can go and isolate the nodes that would not go
Lonely.
B. The user can choose to continue on with the Network
Change; eventually the nodes that do not participate in the
Network Change will go Rogue, and can be identified by
their railroad red LEDs.
Behavior of
CCM
TEMP
All CCMs and TEMPs start their

powerup routines, and get stuck at
check-for-mod since the NR is still being
broadcast
KEPT
all go to listen only

this step
if the sender powers off at this point the
NR will stop, there is no moderator and all
nodes continue through powerup (see
below).
6. Local SetAttribute (set parameters in my ControlNet object)

with new parameters
Behavior of
CCM
TEMP
The CCM still stuck at check-for-mod.
KEPT

this step
all still in listen only
same as above
348
Network Change
7. Broadcast my ControlNet params

Since the broadcast has the port parameters 0 (such as
sched_max_frame), no scheduled work can be done.
Unscheduled traffic can start here because the broadcast
SetAttributes command brings all the devices in ListenOnly
back OnLine. Scheduled traffic can begin as the master CCM
goes through the CCM algorithm
Behavior of
CCM
TEMP
The CCM come online, but are still

stuck at check-for-mod.
KEPT
comes online

po er off/glitch
t is step
Effect
no effect, the other nodes will come online as a
result of the broadcast and will continue through
powerup
In the broadcast ControlNet object parameters, the TUI flags bit

0 = 1 (valid), bit 1 = 0 (temp) and bit 2 = 0 (set by temp) are set
this way on a fast start to initialize the TUI data of the ControlNet
object; this broadcast SetAttributes to the ControlNet object
causes the ControlNet object pending data table to be updated
along with the current data table and all devices in ListenOnly
mode leave the ListenOnly mode, and join the network.
The decision box at C on the Real CCM powerup chart should
be clarified as to what part of the TUI is compared: Should
definitely ignore bit 2; bits 0 and 1 should be compared.
Network Change
349
8. Stop broadcasting the NR message (return Network Resource).

The CCM will proceed through its powerup sequences, and will
begin broadcasting TUI messages; it will broadcast a TUI_flag
with bit 0 = 1 (valid), bit 1 = 1 (real) and bit 2 = 1 (set by a Real).
The CCM will begin its polling action by performing
Set_Attributes of Network and port parameters to each kept
device with the TUI_flag parameters set: TUI_flag with bit 0 = 1
(valid), bit 1 = 1 (real) and bit 2 = 1 (set by a Real).
Upon receiving the SetAttributes message, each ControlNet
object checks the current value of TUI_flag bit 2, which was set
to 0 in step 7: this and the received TUI_flag (bit 2 = 1) triggers
the Set Pending Attribute for the network or updated port data
and causes a local sync of the ControlNet object, to update the
device with the correct port parameters.
Subsequent Set_Attributes messages to the kept devices will only
update the pending table of the ControlNet object, because the
current ControlNet object TUI_flag bit 2 = 1 after the Network
Change is completed.
Behavior of
CCM
TEMP
The CCM will continue through powerup sequence since

the NR was holding it at the check-for-mod step.
KEPT
Effect of sender power

off/glitch after this step
no change
no effect
9. Send local ChangeComplete to return sender to CCM polling.

This Local ChangeComplete is addressed to the CCM object of
the sender.
Behavior of
CCM
TEMP
KEPT
no change
no change
no change

po er off/glitch
t is step
Effect
no effect
3410
Network Change
Notes:
Chapter
35

Changing some of the port parameters on the ControlNet network
can be performed while the network is running as long as the new
port attributes dont cause a violation of the network parameters.
The device that is being changed will be stopped when the port
changes are made.
This service allows the user application to change the port attributes
of a device on one subnet of the ControlNet network. By
convention, only a network-configuring application may perform a
port change of a device on any subnet on the ControlNet network.
Functionality
Section
Page
Functionality
351
Algorithm
352
Function
port_change( path, port parameters, time)
Table 35.A
port_change() Parameters
Parameter Name
path
A pointer to the path (relative address) of the subnet to be

changed. For changing the local subnet, this parameter should
be NULL.
port_parameters
An array of pointers to parameters for each individual device on

the ControlNet network. There is one for each possible
devices MAC ID from 199.
time
Number of periodic interval times (NUTs) to wait before

synchronizing the attribute changes. Accepted values are
10255.
Returns
352
Port Change
Behavior
The Port Change must minimize the risk of creating rogues on the
network. The CCM object on the ControlNet network will have its
port attributes updated, and the ControlNet object in the same device
will receive the new parameters; then the device whose port
parameters are to change will have the pending port parameters of its
ControlNet object changed, before being sent a local synch change
command. After the Port Change command is complete and the Port
Change is verified, the CCM will be signalled to continue polling.
Algorithm
To perform a Port Change, assume that the network parameters

saved at the start of the algorithm are valid for the entire subnet (i.e.,
the reservation table matches the rest of the subnet). It also assumes
that the network resource has been obtained by the application. A
Port Change is performed in a series of steps, listed below:
1. Find the CCM.
To node 1, send a get_single to the CCM object to determine if
this device has a CCM object.
If no CCM is found, an error will be passed back to the
application and the port change aborted. No devices have been
changed.
2. Save the current CCM attributes.
Get the attributes of the CCM on the subnet and save in case they
are needed for error recovery.
3. Stop the CCMs polling function.
Set the CCM Stop bit in the broadcast Network Resource
message. This causes the CCM device to disable the CCM
Object polling algorithm (keeping function) and break
connections to the device.
4. Send new port parameters to the CCM object.
These messages must be unconnected since the CCM object will
disallow connections while in this state.
5. Send the common service apply_attribute to the CCM.
The CCM will copy the pending attributes to current attributes.
If any message fails up to this point, retry the message and then
send the classspecific service abort change to the CCM object,
return an error to the application, and abort the rest of the port
change.
Port Change
353
6. Verify that the CCM has the correct copy of the parameters.
Send a series of get_attribute_list or get_single messages to
the CCM to retrieve the attributes sent to the CCM objects in the
step above. Compare each with the original attributes sent. They
should match exactly.
If any message or the compare fails at this point, retry the
message or resend the attributes. If this cannot be fixed, send
the classspecific service abort_change to the CCM, return an
error to the application, and abort the rest of the port change
7. Update the ControlNet objects of the CCM.
From the port_parameters argument passed to the function, find
the port parameters for the CCM device by MAC ID. Combine
these with the existing network_parameters so that there is one set
of values for each MAC ID. Save these pending_config
attributes of each ControlNet object. Send a set_single
message containing the attribute values saved above to the
ControlNet object of the CCM device. This will put the proper
new port parameters into the CCM ControlNet object.
If there are errors at this point, the original parameters, saved
above must be sent to both the ControlNet object of the CCM
device and the CCM object of the CCM device. Then send the
abort_change to the CCM object, return an error to the
application and abort the rest of the Port Change.
8. Do a verification. Send a get_single to the ControlNet object
of the CCM device to obtain the pending_config attribute values.
Compare each retrieved attribute with what was saved above.
They should match exactly.
the original parameters saved to both the ControlNet object of the
CCM device and the CCM object of itself. Then send the
classspecific service abort_change to the CCMs return an
error to the application, and abort the rest of the Port Change.
9. Send new port parameters to the ControlNet object of the
appropriate device via an unconnected set_attribute_list or a
series of set_single messages.
These messages must be unconnected since the CCM object will
disallow connections while in this state.
10. Do a verification.
Send a get_single to the ControlNet object of the device that
just received the new port parameters to obtain the
pending_config attribute values. Compare each retrieved
attribute with what was sent They should match exactly.
354
Port Change

classspecific service abort_change to the CCM, return an error
to the application, and abort the rest of the port change.
11. Send a local synch change with the t-minus count set to 1 to the
same device that just received the updated port configuration.
This should force the ControlNet object of the device to move the
new port parameters to the current ControlNet object tables.
12. Do a verification.
Send a get_single to the ControlNet object of the device to
obtain the current_config attribute values. Compare each
retrieved attribute with what was sent. They should match
exactly.
classspecific service abort_change to the CCM, return an error
to the application, and abort the rest of the sync.
13. Complete the change and restart the polling algorithm (keeping
function).
Send the classspecific service change_complete to the CCM
object of each CCM device. The CCM will save the parameters
to nonvolatile storage, allow connections to the device, and
restart its polling operation (bring the nonCCM devices back
online with their new parameters)
At this point the new attributes are being used by the CCM
device, and all nonkeeping devices are being brought back
online with the new attributes. The port change is complete.
Chapter
36

Section
Page
Adding A Device To An Existing Network
361
Deleting A Device
361
Replacing A Device
361
Modifying Device Parameters
362
Powering Up
362
Powering Down
362
Rogue And Dup Node Error Recovery
363
Redundant Network
363
Behavior: Unplugged And Moved Node
363
Behavior: Shared ASIC
364
Behavior: Listen-only Node
364
Configuration Save And Restore Behavior
364
Adding A Device To An
Existing Network
A new device does not require a Network Change, but it does
Deleting A Device
No Network Change is required to remove a device from the
require network bandwidth to be available for the new device.

Execution of the Network Change procedure is required if there is
not enough available bandwidth, probably because the bandwidth
was not pre-allocated.
Bandwidth may be pre-allocated and reserved for future use.
If there is enough bandwidth for the new device, a Port Change
can be used to adjust some of the port parameters for the device.
network.
To take away the network reservation for a device, possibly to
optimize the network, a Network Change is required to
redistribute the updated reservation table.
Replacing A Device
A device may be replaced with an identical device.

If the replacement device is different from the original device,
the original device should be deleted and the replacement device
added to the configuration, this will require a Port Change unless
more bandwidth must be allocated (then a Network Change is
required).
362
ControlNet Miscellaneous Information
Modifying Device
Parameters
Parameters associated with the ControlNet object should not be

changed unless the devices are offline.
A device specific change can be made to the port parameters of a
online device without a Network Change by performing the Port
Change sequence discussed in this document.
Changing Scheduled Max Bytes

Changing the Scheduled Max Bytes shall not be done without a
Network Change; changing this parameter has ripple effects and it
should not be done unless all the network parameters are changed.
Powering Up
Cold Power Up
A system that was previously configured, or that has lost power in
the middle of a Network Change, is configured by its CCM, with
whatever the CCM thinks is correct.
Warm Restart
When a system that was configured and running has power removed
and returned (before the complete power down sequence has been
completed), it may have some nodes that enter the listenonly state
and other nodes that continue operating. Kept nodes that enter the
listenonly state will be configured and brought back online by the
CCM. If the CCM executes its powerup sequence, it will get the
correct network and port parameters from nonvolatile storage, and
use these parameters to bring other nodes in listenonly mode online.
Powering Down
There are no special power down requirements.
Removal and Insertion under Power

Nodes may be removed or connected to the ControlNet network.
Unconfigured devices, when added to a running network, will
remain in a listenonly state until configured. If the device was
already configured in the CCM reservation table, the network CCM
will configure the device and bring it online.
Rogue And Dup Node

Error Recovery
363
Dup Node Listen-only Behavior

A Dup node (a node with the same MAC ID as another node) enters
the Dup listenonly state, where it remains until a Network Change
occurs or power is cycled. See the ControlNet object in Appendix A
for more information.
Rogue Node Listen-only Behavior

A Rogue Node (a node with network parameters that do not match
the network it is connected to) performs a Rogue Detection scheme
which is transparent to the user. Once a node is defined as Rogue, it
must enter the listenostate, where it will remain with Railroad Red
LEDs.
Redundant Network
All ControlNet network defaults are redundant; the ASIC will

automatically switch from channel A to channel B, in redundant
mode, if errors are detected in channel A. The redundancy port
parameter specifies the channel used by a device. A redundant
network requires both channels of the device to be connected to
networks.
Behavior: Unplugged And

Moved Node
The following describes behavior when a node is unplugged and

moved, network to network.
Node Un-powered when Moved

On a network, if the node is the CCM, it will figure out it is Rogue
(its network MAC Parameters do not match those of the network)
and enter a faulted state; the network will be unaffected.
A Rogue Node needs an order of magnitude or more difference in
NUT lengths to hear the Moderator and continue operating the
network with a longer NUT. Usually, the NUT length is reduced to
2 milliseconds and the network stops.
Node under Power when Moved (Cable Swap)

If the transfer takes longer approximately 2 seconds,the device is
lonely during the transfer; it will follow the normal network
procedures. A n errant moderator packet could be sent and there is
a small probability it could cause a Rogue event. No permanent
network damage will occur, only a hiccup.
364
If the transfer takes less than approximately 2 seconds, the device

will not become lonely; it does not realize it needs to rejoin the
network. It will continue to transmit as though it was not moved.
Collisions will occur and the new node will probably go Rogue.
There is a small probability that a Rogue CCM will win and take
over the new network; this would result in a complete malfunction of
the network.
Evil CCM
There is a small possibility, as a result of the move, that the network
MAC Parameters of the moved CCM will match the networks MAC
Parameters; then if the reservation table of the CCM is different, the
new CCM could take over the network undetected, and cause
difficult problems.
Behavior: Shared ASIC
The following describes behavior when a Network Access Port

(NAP) allows a terminal to share the ASIC:
The NAP terminal, on all devices that support the ASIC, allows
a programming terminal to share the ASIC.
It will respond like other terminals to a who command, unless
it does not have a MAC Address.
Behavior: Listen-only
Node
The following describes behavior when a terminal is plugged into

a NAP of a listen only node.
In listen only mode the modem is still on, so it should respond.
It will do its repeater function. The node must be powered up.
Configuration Save And

Restore Behavior
A new network, or a network that has a new CCM device, must be

initialized with reservation table information about all the devices
connected to the network.
Chapter
37

This chapter defines terms you need to know to understand
ControlNet system configuration.
CCM
A ControlNet device which stores and distributes network and port
parameters for an entire ControlNet link.
Temporary CCM
A service performed by CCMs and and programming terminals.
The purpose of the Temporary CCM is to establish a new network in
the absence of a configured Real CCM and to maintain an existing
network when the Real CCM is removed from the network.
A Temporary CCM does a Datagram broadcast of network
parameters with zeroed port parameters.
Link
A collection of nodes with unique addresses (in the range of 199).
Segments connected by repeaters make up a link; links connected by
bridges make up a network (this replaces subnet).
Listen-only Mode
A state that all devices enter during their power-up sequences; a
device in listen-only is circulating moderator packets and can receive
data from any node on the subnet. The listen-only mode device can
not transmit.
Moderator
Node with the lowest MAC ID; responsible for circulating MAC
Packets.
Master CCM
A device capable of performing the CCM function, with the lowest
MAC ID of all the devices on the network capable of being the
CCM.
372
System Configuration Glossary
Network Parameter
Those network parameters which must be the same for every device
on the subnet. This is the attribute net_config for the ControlNet
CCM Object and the pending_net_config portion of the
pending_config_ attribute of the ControlNet object.
Network Resource
An object in the ControlNet device which governs changing the
attributes of a CCM object. The object ensures that only one
application may change the CCM attributes at a time.
Port Parameter
Those parameters of the ControlNet object which may be different
for different devices on the subnet. This is the sched_rate portion
of the pending_config attribute of the ControlNet object. In the
CCM object, the port parameters are in the port_config attribute.
Powered-on Node
A node with active LEDs.
Reservation Table
The term for the network and port parameters for all scheduled nodes
on an entire subnet. This table is defined by the attributes for the
CCM object. Within one subnet, there is one set of network
parameters plus one set of port parameters for each node.
Subnet
A portion of a ControlNet network where all devices are attached to
a single cable run; formerly known as a link.
Port
A connection to a network; on the ControlNet network, a node is
equated with a device and there is 1 port per MAC ID.
373
Rogue Node
A node whose MAC parameters do not match the associated
parameters of its network CCM.
Evil CCM
A device with an incorrect reservation table that has become the
network CCM.
Rogue Event
When a Rogue node transmits a moderator packet; this will probably
effect network transmissions.
Lonely
Condition where a node finds itself on a network where no
moderator is circulating, implying there are no other active nodes on
the network.
374
Notes:
Chapter
38

Message/Traffic Generator
Tool
Use this chapter to install and use the ControlNet message/traffic
generator tool (cat. no. 9220-TG).
network installation and troubleshooting. To use this tool efficiently,
you should be familiar with ControlNet protocols. This chapter
contains these sections:
Section
Introduction To The Tool
Page
382
System Requirements
382
Installing The Tool
383
Configuring The Tool
385
Using The Tool
386
382
Using The ControlNet Message/Traffic Generator Tool
Introducing The Tool
Use this tool to:

construct, edit, and send data packets and messages on a
ControlNet network
Using this tool, you can:
open connections to different objects and send predefined
messages, data bytes, or packets individually or in a sequence.
construct, edit and send data packets and messages. These

edited data packets and messages can be saved to and
retrieved from files. Once you have saved data in a file, you
can use function keys to send predefined packets or messages
into the network one by one. You can also use the play option
to send all the data saved in a file, at once.
"
If you want to view the messages or data packets being sent on the
network, use the ControlNet Traffic Analyzer tool (9220-TA).
assist in the designing and debugging of ControlNet products

Use this table to become familiar with some of the tools terms:
System Requirements
Term
Definition
CNXOR.CFG
the configuration file the tool utilizes to initialize itself
PIT
network update time; repetitive time interval in which data

can be sent on the ControlNet network
packets
any data bytes, patterns, or messages
MAC ID
a nodes address on the network
SMAC
the ControlNet Media Access Control interface circuitry

used to send and receive data on an ControlNet network.
Item
microprocessor
operating system
memory
hard disk space
video adapter and
monitor
diskette drive
ISA/EISA bus
pointing device
Description
4 MB or higher
8 MB
VGA or high-resolution
super VGA display (800 x 600)
one 3.5 high-density diskette drive
ControlNet 9220-KTCT test card
Important:
The CONFIG.SYS file must, at least, contain the lines

Installing The Tool
383
1. Insert the tool disk into your computers 3.5 disk drive.
mkdir tg
Enter
The tg directory is used in TG.BAT. If you create a different

directory for the tool, you need to edit the cnxpath in TG.BAT
(set CNXPATH=c:\new_directory). The path sets a DOS
environment variable to instruct the tool where to look for
CNXOR.CFG. This gives you flexibility in placing the file and
lets you load multiple files, in different directories.
3. Change to that directory:
cd tg
Enter
4. Copy the contents of the tool disk to the directory you created:
copy A:*.*
Enter
5. Start the tool:

tg
Enter
You see:
384
and the current status of the tool:
6. Click with your right mouse button in the Current Status window
to close it.
"
To navigate through the tool, use your left mouse button to access
drop-down menus, cascading menus, and dialog boxes, and your
right mouse button to close them.
drop-down menu
cascading menu
dialog box
Configuring the Tool
385
From the Setup drop-down menu, you can set these configuration
options:

This parameter:
Simulation
Is used to:
display the tools menus and capabilities without actually
communicating with a node on the network. While in this mode,
the tool does not interface with the 9220-KTCT card.
Online
set the tool online in the ControlNet network and set the
9220-KTCT card in an online mode. The 9220-KTCT card waits
for a moderator message to go online. Once the 9220-KTCT card
is online, the tool acquires the current network parameters and is
configured to them.
Offline
take the tool and 9220-KTCT offline from the ControlNet network.
This is the default setting for the 9220-KTCT card and the tool.
Port Number
select which 9220-KTCT card will be used. This parameter

specifies the port that the card is installed in (03). You can
install as many as four 9220-KTCT cards in one PC.
Mac ID
set the network address of the 9220-KTCT card.
Target Mac ID
set the target nodes network address. This address should be

the node you want to communicate with (i.e., get attributes from,
open connections to, and send messages to, etc.).
CN Parameters
set the Network Update Time (NUT), in milliseconds.
The tool selects a default value based on the configuration file at start-up.
386
Using The Tool
This figure shows the functional blocks for navigation through the
tool, with each block representing a single window.
Main Menu
Status
Display
Send Unconnected
Messages
Open
Connections
Send Connected
Messages
Traffic Generator
Data Bytes
Data Patterns
For information on:
Data Repeater
See page:
Changing the network update time
386
Changing the port number of the 9220-KTCT card
387
Changing the MAC ID of the 9220-KTCT card
387
Viewing the tools current status
388
Sending a message to a target node
388
Sending an unconnected message
3812
Closing a connection
3813
Using the traffic generator
3814
Taking the card offline
3817
Exiting the tool
3817
Editing the tools configuration file
3817
Changing the Network Update Time

From Setup, choose CN Parameters, and choose a time in
milliseconds.
387
Changing the Port Number of the 9220-KTCT Card

From Setup, choose Port Number, and set the port number equal to
the port of 9220-KTCT card you are using (03).
Changing the MAC ID of the 9220-KTCT Card

From Setup, choose MAC ID, and set the network address of the
9220-KTCT card (099).
388
Viewing the Current Status of the Tool

To view the current status of the tool, choose Status. This displays a
status window showing the current state of the traffic generator with
respect to the ControlNet network, the status of any open
connections, the Port Number, and the source and target MAC IDs.
Sending a Message to a Target Node

1. Select the node you want to communicate with.
From Setup, choose Target MAC ID.
Click the arrows to select the

network address of the target node.
389
2. Go online to the ControlNet network.

From Setup, choose Online.
Resetting KTCT Card..
Enabling Network Events..
Soft Resetting KTCT Card..
Transitioning to Online..
3810
3. Open a connection.
From Connections, choose Open Connection and then choose the
type of connection you want to open.
"
Connections and connection parameters (e.g., Expected Packet Rate

and Connection Size) are defined in CNXOR.CFG.
The connections are used to open defined objects and instances for
the target node. You can edit this file as necessary for
your application.
C.
CBT = cyclic block transfer
BT = block transfer
D.
E.
4. Send the message to the target node.
To:
Choose:
send a message
Connected, Send Message
send and monitor a message
Connected, Send/Monitor Messg.
monitor the connection
Connected, Monitor Connection
As shown on
page 3811, in:

"
3811
The list of connected messages displayed is based on active

open connections.

displays...
then...
Important:
If you did not open a connection (see step 3),

you see:
3812
Sending Unconnected Messages

You can send unconnected messages to:
send predefined unconnected messages
get attribute information on an object
reset a device
Sending Predefined Unconnected Messages
To send an unconnected message, choose Unconnected, Send
Message, and choose the message you want to send.
To:
set the target nodes in the Listen Only mode
Choose this message:

CNet Listen Only
send Keeper type messages when not in an operating

network
Keeper 5ms, 15, 16
obtain loose parameters information
Keeper Loose Params
obtain the pending parameters
CNet Get Pending
obtain the current parameters
CNet Get Current
obtain diagnostic information
CNet Get Diags
These messages are defined in the tools configuration file, CNXOR.CFG.
Getting Attribute Information

To send an unconnected message to get attribute information, choose
Unconnected, Get Attr All, and choose the object you want attributes
on.
3813
Resetting a Device
To reset a device, choose Unconnected, Reset, and choose the object
you want to reset.
Closing a Connection
To close a connection, choose Connections, Close Connection
and choose the connection you want to close from the list of
open connections.
3814
Using the Traffic Generator

The traffic generator provides an editing window for constructing
data packets (bytes, patterns and messages). The bottom portion of
the editing window lists the main commands to use.
1. To access the traffic generator, choose Build, Traffic Generator.
You see:
From this window, you can

construct your data packets
(bytes, patterns, and messages).
Important:
If you see this error, you need to go online.

See step 2, on page 389.
3815
2. Use the traffic generator to construct and send messages.

To:
view the traffic generators options
You:
Type help
Type the message enclosed in <>.
<xx xx xx xx>
a. press a function key
construct and send a message
assign a set of data packets to

a function key
F1
to
F10
Shown in:

b. type in the message parameters

load a saved
function-key-assignment file
save current function-key
assignments to a file
log all key strokes into a file, for
later playback
play a file (send predefined
messages on the network)
load filename
save filename
log filename
not shown
play filename
not shown
A filename must not exceed 8 characters in length.

A predefined-message file, PLAYSOME
is shipped on the traffic generator disk. See page 3816.
3816
"
A file on the traffic generator disk (PLAYSOME) contains predefined

messages you can send on your ControlNet link. Using your DOS
editor, you can edit these messages as necessary.
Running a Separate DOS Program

To run a separate
DOS program from:
You:
the Modules drop-down menu edit CNXOR.CFG to define your tests. These tests then
appear in the cascading menu that lists the tests. See
the figure below and page 3826.
the DOS prompt
a. choose File, DOS Shell

b. run the program: program.exe
3817
Taking the Card Offline

From Setup, Choose Offline.
Exiting the Tool
Editing The Tools

Configuration File
To:
Choose:
exit to a DOS prompt for viewing and editing

configuration files (e.g., CNXOR.CFG)
File, DOS Shell
exit the program and take the card offline

without closing open connections
File, Exit
This tools functionality is defined in its configuration file,

CNXOR.CFG. This ASCII file is read, as necessary, as the
tool executes. In this file, information is defined through a set of
keywords, called Resources, that configure the menus and provide
the data to be used. A resource consists of:
keyword.name.resource: value
This part:
keyword
name
resource
value
Is:
a predefined identifier the traffic generator searches to know what to do.
Defined keyword
Defines
CN
ControlNet specific setup parameters
Object
ASA objects used by the target device
Connection
ASA connections used by the target device
Message
ASA messages that can be sent to the objects
Module
a module that has tests associated with it
Test
a test associated with a module
a user-provided identifier that groups a set of resources together. The
name:
must be an alphanumeric string
cannot contain a colon
cannot contain any spaces
is case sensitive
a predefined name data item.
the data to be used by the tool. This data is a numeric value, a data
byte string, or an ASCII string, depending on the resource being defined.
3818
When editing CNXOR.CFG, remember that:

white spaces, blank lines and tabs are used as separators and
are ignored
if a resource value is long, the resource can be extended to the
next line by placing a \ character as the last character on the line
the tools search function is case sensitivebe sure to observe the
exact case of the resource as you define it or the tool will not find
your definition in CNXOR.CFG
you can add comments to CNXOR.CFG using the # character
place them at the beginning of a line, or at the end of a line as the
beginning character of the comment
comments (#) cannot be placed on a line that is defining a string
of characters or data bytes
The following table lists the parameters specified in CNXOR.CFG.
3819
ControlNet Setup Parameters

Resource
CN.name:
CN.___.title:
CN.___.originatorPortNum:
CN.___.originatorMacId:
CN.___.targetMacId:
CN.___.pit_time:
CN.___.smax:
CN.___.umax:
CN.___.slot_time:
CN.___.blank_time:
CN.___.gb_start:
CN.___.gb_center:
CN.___.redundancy:
CN.___.sched_max_frame:
CN.___.int_cnt_mod:
CN.___.gb_prestart:
CN.___.mcycle_start:
CN.___.mcycle_length:
CN.___.mcycle_count:
CN.___.mcycle_multiplier:
Description
Provides a list of ControlNet setup names to be
included in the SETUP>CN PARAMETERS cascading
menu. These names are shown in the menu unless a
CN.___.title resource is provided for each name. The
default parameters, if present, will be loaded
automatically upon startup of the program.
CN.name: default setup2ms setup5ms
Provides a title to be displayed in the
SETUP>CN PARAMETERS cascading menu. If it is
not provided, the name will be displayed.
CN.default.title:
Default
CN.setup2ms.title: Worst Case PIT
CN.setup5ms.title: Normal PIT
Specifies the 9220-KTCT card to use for the setup.
Valid port numbers: 03.
CN.setup2ms.originatorPortNum: 0
Specifies the network addresses (MAC IDs) of the
originator (9220-KTCT) and target devices. Valid
address: 0 99.
CN.default.originatorMacId: 1
CN.default.targetMacId: 2
These parameters make up the ControlNet Object
Attribute to send to the 9220-KTCTs ControlNet
Object.
CN.default.pit_time: 200
CN.default.smax: 5
CN.default.umax: 6
CN.default.slot_time: 21
CN.default.blank_time: 6
CN.default.gb_start: 12
CN.default.gb_center: 9
CN.default.redundancy: 3
CN.default.sched_max_frame: 255
CN.default.int_cnt_mod: 255
CN.default.gb_prestart: 15
CN.default.mcycle_start: 0
CN.default.mcycle_length: 0
CN.default.mcycle_count: 1
CN.default.mcycle_multiplier: 8
3820
Object Setup
Resource
Description
Object.name:
Provides a list of Object names for use in the

Unconnected>Send Message, Get Attr All and
Reset cascading menus. These names are
displayed unless an Object.___.title is provided for
each name.
Object.name:
Object.___.title:
device mr rack

Unconnected>Send Message, Get Attr All, and
Reset cascading menus. If a title s not provided,
the name is displayed.
Object.device.title: Device
Object.___.number:
Specifies the Object number for the Object.

Object.device.number:
Object.
.max_instance:
Specifies the maximum instance supported by

this Object. It is used to create the Instance
cascading menu after an object is chosen.
Object.device.max_instance:
Connection Setup
Resource
Connection.name:
Description
Provides a list of Connection names for the
Unconnected>Open Connection and
Close Connection cascading menus. These
names are displayed in the menu unless a
Connection.___.title is provided for each name.
Connection.name: mr rackio rackin
rackout cycbtr cycbtw
Connection.___.title:

Unconnected>Open Connection and Close
Connection cascading menus. If this resource is
not provided, the name is displayed.
Connection.mr.title:
Message Router
Connection.___.max_instance:
Specifies the maximum instance supported by the

Connection being made. It is used to create an
instance cascading menu after a Connection has
been chosen.
Connection.cycbtr.max_instance: 16
Connection.___.timeout:
The UCMM timeout value used in an Open/Close

Connection message to the target Object. This
value is in hex.
Connection.mr.timeout: 0A
Connection.___.epr:
The Expected Packet Rate for the Connection

being established, expressed in the form of a
16bit scaled integer as described in the
Connections in the ASA Product Developers
Guide, cat. no. 9250-DOC. This value is in hex.
Connection.rackio.epr: 0E71
3821
Connection Setup (continued)

Resource
Description
Connection.___.net_t_o:
Connection.___.net_o_t:
Specify the Net_T_O and Net_O_T values in the

Open message. These values are bit fields as
described in the Connections in the ASA Product
Developers Guide, cat. no. 9250-DOC. These
values are in hex.
Connection.rackio.net_t_o: 281A
Connection.rackio.net_o_t: 480A
Connection.___.class:
Specifies the class number of the Object being

connected to. This value is in hex.
Connection.mr.class: 02
Connection.___.transport:
Specifies the Transport Class/Trigger value for the

Open message. The value is a bit field as
described in the Connections in the ASA Product
Developers Guide, cat. no. 9250-DOC. This
value is in hex.
Connection.mr.transport: A3
Connection.___.path:
Specifies the path segment to be attached to the

end of the Open message. The path begins
immediately following the instance segment of the
Open and typically begins with the Connection
point information. The path is sent byte for byte
as specified. The data bytes are in hex.
Connection.rackio.path:
2c 02 2c 01 80 05 01 00 0c 00 18 00 01
01 02 00
Connection.___.1stmsg:
Specifies a message to be sent on the Connection

immediately after a successful Open has
completed (optional). This makes sure the
Connection does not timeout before you have a
chance to send the first data on the Connection.
The value must be a name of a message specified
in Message.___.data.
Connection.rackio.1stmsg:
rout1
(see Message Setup)
Message.___.list:
Provides a list of message names for the

CONNECTED>SEND MESSAGE cascading
menu. These message names will be associated
with the Connection name specified. Once a
Connection has been opened, these messages
could be sent across that Connection. These
names will be shown in the menu unless a
Message.___.title is provided for each name.
Connection.name: rackio (see Connection
Setup)
Message.rackio.list: rout1 rout2 rout3 rout4
The name unconnected is reserved for messages
to be sent unconnected.
Message.unconnected.list:
Provides a list of message names for the

UNCONNECTED>SEND MESSAGE cascading
menu. These names will be shown in the menu
unless a Message.___.title is provided for each
name.
Message.unconnected.list: reset gaa
3822
Connection Setup (continued)

Resource
Description
Message.___.title:

UNCONNECTED>SEND MESSAGE or
CONNECTED>SEND MESSAGE cascading
menus. If this is not provided, the name will be
displayed.
Message.rout1.title: Pattern AA55
Message.reset.title: Reset
Message.gaa.title: Get Attributes All
Message.___.data:
The data associated with the message.

For Unconnected messages, the data begins with
the Unconnected Service Code and is sent byte
for byte as specified. For Connected messages,
the data begins with the byte immediately
following the Transport header. The data bytes
are in hex.
Message.rout1.data: 01 00 00 00 AA 55 AA 55
Message.reset.data: 05 02 20 01 24 01
Message.gaa.data: 01 02 20 01 24 01
Module.name:
Provides a list of module names to be included in

the MODULES drop-down menu. This menu lists
executable tests that can be launched. These
Module.___.title is provided for each name.
Module.name: 1771acn 1785l40c
Module.___.title:
Provides a title to be displayed in the MODULES

drop-down menu. If this resource is not provided,
the name will be displayed.
Module.1771acn.title: 1771ACN/ACNR
Module.___.tests:
Specifies a list of tests for the desired module

under the MODULES drop-down menu. These
Test.___.title is provided for each name.
Module.1771acn.tests: ftp1 ftp2 ftp3 ftp4 ftp5 ftp6
ftp7 ftp8 ftp9 ftp10 ftp11 ftp12
Test.___.title:
Provides a title to be displayed under the

MODULES drop-down menu or the desired
module. If this resource is not provided, the name
will be displayed.
Test.ftp1.title:
UCMM Test
Test.___.file:
Specifies the name of a pair of files associated

with the desired test. The program runs make
with a make filename of value.mak and then
attempts to execute the file value.exe. This lets
you build and execute programs written using the
traffic generator API library and executed from the
user interface.
Test.ftp1.file:
acn_ucmm (this assumes
acn_ucmm.mak and acn_ucmm.exe exist)
3823
Example CNXOR.CFG File

##########################
## CN Setup Parameters ##
##########################
##################################
# Define the CN Parameter Setups
#
CN.name: default setup2ms
#
# Describe the CN Setups
#
CN.default.title: Default
CN.default.originatorPortNum: 0
CN.default.originatorMacId: 0
CN.default.targetMacId: 8
CN.default.pit_time: 200
CN.default.smax: 5
CN.default.umax: 6
CN.default.slot_time: 21
CN.default.blank_time: 6
CN.default.gb_start: 12
CN.default.gb_center: 9
CN.default.redundancy: 3
CN.default.sched_max_frame: 255
CN.default.int_cnt_mod: 255
CN.default.gb_prestart: 15
CN.default.mcycle_start: 0
CN.default.mcycle_length: 0
CN.default.mcycle_count: 1
CN.default.mcycle_multiplier: 0
CN.setup2ms.title: 2ms PIT
CN.setup2ms.originatorPortNum: 0
CN.setup2ms.originatorMacId: 1
CN.setup2ms.targetMacId: 8
CN.setup2ms.pit_time: 200
CN.setup2ms.smax: 15
CN.setup2ms.umax: 16
CN.setup2ms.slot_time: 21
CN.setup2ms.blank_time: 6
CN.setup2ms.gb_start: 12
CN.setup2ms.gb_center: 9
CN.setup2ms.redundancy: 3
CN.setup2ms.sched_max_frame: 255
CN.setup2ms.int_cnt_mod: 255
CN.setup2ms.gb_prestart: 15
CN.setup2ms.mcycle_start: 0
CN.setup2ms.mcycle_length: 0
CN.setup2ms.mcycle_count: 1
CN.setup2ms.mcycle_multiplier: 0
3824
Example CNXOR.CFG File (continued)

########################################
# Define the Objects we will be using.
#
Object.name: device cn mr rack
#
# Describe the Objects
#
Object.device.title: Device
Object.device.number: 01
Object.device.max_instance: 1
Object.cn.title: CNet
Object.cn.number: 65
Object.cn.max_instance: 1
Object.mr.title: Message Router
Object.mr.number: 02
Object.mr.max_instance: 1
Object.rack.title: 1771 Rack
Object.rack.number: 7c
Object.rack.max_instance: 1
#######################################################
# Define the Unconnected Messages we will be sending.
#
Message.unconnected.list:
reset gaa
#
# Describe the Messages
#
Message.reset.title: Reset
Message.reset.data: 05 02 20 01 24 01
Message.gaa.title:
Get Attributes All
Message.gaa.data:
01 02 20 01 24 01
3825

############################################
# Define the Connections we will be using.
#
Connection.name: mr rackio rackin rackout
#
# Describe the connections.
#
# default values for those not specified
Connection.default.timeout:
0A
Connection.default.epr:
0E71
# 5ms epr
Connection.default.net_t_o:
0000
Connection.default.net_o_t:
0000
Connection.default.transport: 01
# Message Router parameters.
Connection.mr.title: Message Router
Connection.mr.max_instance: 1
Connection.mr.epr:
2BD0
Connection.mr.net_t_o:
43ff
Connection.mr.net_o_t:
43ff
Connection.mr.transport:
A3
Connection.mr.class:
02
# 1 second epr
# Input Rack parameters.

Connection.rackin.title: Input Rack
Connection.rackin.max_instance: 1
Connection.rackin.net_t_o:
281A
Connection.rackin.class:
7C
Connection.rackin.transport: 81
Connection.rackin.path:
2c 01 80 05 01 00 0c 00 18 00 01 01
02 00
# Output Rack parameters.
Connection.rackout.title: Output Rack
Connection.rackout.max_instance: 1
Connection.rackout.net_o_t:
4816
# 16 slot, single density
Connection.rackout.class:
7C
Connection.rackout.transport: 01
Connection.rackout.path:
2c 02 80 04 01 00 0c 00 18 00 01
01
Connection.rackout.1stmsg:
rout1
# Output/Input Rack parameters.
Connection.rackio.title: I/O Rack
Connection.rackio.max_instance: 1
Connection.rackio.net_t_o:
281A
#Connection.rackio.net_o_t:
Connection.rackio.net_o_t:
Connection.rackio.class:
Connection.rackio.transport:
Connection.rackio.path: 2c 02
4816
480A
7C
01

2c 01 80 05 01 00 0c 00 18 00 01 01 02
00
Connection.rackio.1stmsg:
rout1
3826

###############################################################
# Define Object Messages
# Note: The message name for the list header must be the
#
same as that defined in the Connection.name object.
#
Message.rout1.title:
Pattern 1
Message.rout1.data:
01 00 00 00 01 02 03 04
Message.rout2.data:
Pattern 2
01 00 00 00 02 03 04 05
Message.rout3.data:
Pattern 3
01 00 00 00 03 04 05 06
#
# Rack Output Message List
#
Message.rackout.list: rout1 rout2 rout3 rout4 rout5 rout6 rout7
rout8\
rout9 rout10 rout11
#
# Rack I/O Message List
#
Message.rackio.list: rout1 rout2 rout3 rout4 rout5 rout6 rout7
rout8 \
rout9 rout10 rout11

###########################################
# Define the modules with specific tests
#
Module.name: 1771acn
Module.1771acn.title:
1771ACN/ACNR
Module.1771acn.tests:
ftp1 ftp2 ftp3 ftp4 ftp5 ftp6 ftp7
ftp8\
ftp9 ftp10
Test.ftp1.title:
UCMM Test
Test.ftp1.file:
acn_ucmm
Test.ftp2.title:
Test.ftp2.file:
MR Object Test
acn_mr
Test.ftp3.title:
Test.ftp3.file:
CN Object Test
acn_cn
Test.ftp4.title:
Test.ftp4.file:
Device Object Test

acn_dev
Test.ftp5.title:
Test.ftp5.file:
Output Rack Test

acn_rcko
Test.ftp6.title:
Test.ftp6.file:
Input Rack Test

acn_rcki
Test.ftp7.title:
Test.ftp7.file:
Cyclic BT Read
acn_cbtr
Test.ftp8.title:
Test.ftp8.file:
Cyclic BT Write
acn_cbtw
Test.ftp9.title:
Test.ftp9.file:
Cyclic BT Status
acn_cbts
Test.ftp10.title:
Test.ftp10.file:
Async BT Test
acn_abt
3827
Message/Traffic Generator API Functions

The following functions can be used to create executable test
programs, for testing on a ControlNet network. Once created, these
programs can be added to CNXOR.CFG so they can be accessed in
the tool from the Modules pull-down menu.
Use this function:
To:
MG_Env ( )
read the message/traffic generator

environment variable and fill in the global
configFile string.
3828
MG_Init ( )
initialize the message/traffic generator

interface.
3828
MG_Cleanup ( )
clean up the message/traffic generator

interface.
3828
MG_LoadCNSetup ( )
load a ControlNet setup from

CNXOR.CFG.
3828
MG_Online ( )
put the message/traffic generator in listen

only mode until it receives a moderator
type packet, then it goes online with the
target, otherwise it remains in the listen
only mode.
3829
MG_Offline ( )
take the message/traffic generator offline

with the target.
3829
MG_OpenConnection ( )
open a connection with the target device.
3829
MG_CloseConnection ( )
close a previously opened connection.
3829
MG_SendUnconnected ( )
send an unconnected user-supplied

message.
3830
MG_SendUnconnectedMsg ( )
send an unconnected message from

CNXOR.CFG.
3830
MG_ReceiveUnconnected ( )
receive an unconnected message from

the UCMM.
3830
MG_SendConnected ( )
send a user-supplied message on a

connection previously opened with a call
to MG OpenConnection.
3830
MG_ReceiveConnected ( )
receive a message on a connection

previously opened with a call to
MG OpenConnection.
3831
MG_SendConnectedMsg ( )
sends a message from the config file on a

connection previously opened with a call
to MG_OpenConnection.
3831
MG_RegisterClass ( )
registers a class with the message router

for receipt of the unsolicited messages.
3831
MG_UnregisterClass ( )
unregistered a class with the message

router
that was previously registered with
MG RegisterClass.
3831
See
page:
3828
/*****************************************************************\
**
** Name: MG_Env ( )
**
** Description:
** This function reads the Message/Traffic Generator environment
** variable and fills in the global configFile string.
**
** Inputs:
None
**
** Outputs: UINT status
SUCCESS
**
BAD_PARAMETER_VALUE
**
** Copyright (c) 1995, 96 AllenBradley Company
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_Init ( )
**
** Description:
** This function initializes the Message/Traffic Generator
** interface. It must be the first MG_ API function called.
**
** Inputs:
None
**
SUCCESS
**
BAD_PARAMETER_VALUE
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_Cleanup ( )
**
** Description:
** This function cleans up after the Message/Traffic Generator
** interface. It must be the last MG_ API function called.
**
** Inputs:
None
**
** Outputs: None
**
**
\*****************************************************************/
/*****************************************************************\
**
** Name: MG_LoadCNSetup ( )
**
** Description:
** This function loads a CNet setup from the configuration file.
**
** Inputs:
USINT *setupName Name of setup to load.
**
SUCCESS
**
BAD_PARAMETER_VALUE
**
**
\*****************************************************************/
3829
/*****************************************************************\**
** Name: MG_Online ( )
**
** Description:
** This function puts the Message/Traffic Generator in Listen Only
** mode until it receives a Moderator type packet, where at that
** time will go Online with the target, otherwise it will remain
** in Listen Only mode.
**
** Inputs:
None
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_Offline ( )
**
** Description:
** This function takes the Message/Traffic Generator offline with
** the target.
**
** Inputs:
None
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\
**
** Name: MG_OpenConnection ( )
**
** Description:
** This function opens an ASA Connection with the target device.
**
** Inputs:
UINT *connIndex
Pointer to connection index that
**
will be filled in by the function.
**
USINT *connName
Name of connection from.
**
configuration file to be opened.
**
UINT instance Instance number of object to
**
connect to.
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_CloseConnection ( )
**
** Description:
** This function closes a previously opened ASA Connection.
**
** Inputs:
UINT connIndex
Connection index that was returned **
by the MG_OpenConnection function.
**
SUCCESS
**
BAD_PARAMETER_VALUE
**
**
\*****************************************************************/
3830
/*****************************************************************\**
** Name: MG_SendUnconnected ( )
**
** Description:
** This function sends an unconnected ASA message provided by
** the user.
**
** Inputs:
USINT *message
Message to be sent.
**
UINT dataSize
Size, in bytes, of the
**
message to be sent.
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_SendUnconnectedMsg ( )
**
** Description:
** This function sends an unconnected ASA message from the
** configuration file.
**
** Inputs:
USINT *message
Message to be sent.
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_ReceiveUnconnected ( )
**
** Description:
** This function receives an unconnected ASA message from the UCMM.
**
** Inputs:
USINT *message Pointer to where to put the
**
received message.
**
UINT *dataSize
Size, in bytes, of the
**
message received.
**
** Outputs:
UINT status
SUCCESS if message received
**
FAILURE if no message received
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_SendConnected ( )
**
** Description:
** This function sends a user provided message on a Connection
** previously opened with a call to MG_OpenConnection.
**
** Inputs
UINT connIndex Connection index that was returned
**
**
USINT *message Message to be sent.
**
UINT dataSize Size, in bytes, of the message to
**
be sent.
**
SUCCESS
**
**
\*****************************************************************/
3831
/*****************************************************************\**
** Name: MG_ReceiveConnected ( )
**
** Description:
** This function receives a message on a Connection
** previously opened with a call to MG_OpenConnection.
**
** Inputs:
UINT connIndex Connection index that was
**
returned by the MG_OpenConnection
**
function.
**
USINT *message Pointer to buffer for message.
**
UINT
*dataSize
Size, in bytes, of the message
**
received.
**
SUCCESS if message was received.
**
FAILURE if no message was received.
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_SendConnectedMsg ( )
**
** Description:
** This function sends a message from the configuration file on a
** Connection previously opened with a call to MG_OpenConnection.
**
** Inputs:
UINT connIndex Connection index that was returned
**
**
USINT *message Message to be sent.
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_RegisterClass ( )
**
** Description:
** This function registers a class with the Message Router
** for receipt of the unsolicited messages.
**
** Inputs:
USINT class
ASA class to be registered.
**
SUCCESS
**
**
\*****************************************************************/
/*****************************************************************\**
** Name: MG_UnregisterClass ( )
**
** Description:
** This function unregisters a class with the Message Router
** that was previously registered with MG_RegisterClass.
**
** Inputs:
USINT class
ASA class to be unregistered.
**
SUCCESS
**
**
\*****************************************************************/
3832
Notes:
Chapter
39

Use this chapter to install and use the ControlNet traffic
analyzer tool (cat. no. 9220-TA). This information is also available
in the tools README file or online help.
network installation and troubleshooting. To use this tool efficiently,
you should be familiar with ControlNet protocols.
Section
Page
391
Navigating Through The Tool
392
System Requirements
253
Installing The Tool
394
Initializing The Tool
395
Using The Tool
3910
Troubleshooting
3928
Use this tool to:

examine and analyze network data on a ControlNet network
Using this tool, you can capture and display large amounts of
packet data from a ControlNet link. Triggering and filtering
mechanisms allow you to determine when data capture is to begin
or end and exactly which packets are to be captured.
Once the data has been captured you can filter it, search for
patterns, and display the packets in a variety of formats and in
varying levels of detail. Some network performance data can also
be calculated from the captured data.
assist in the designing and debugging of ControlNet products
392
Using The ControlNet Traffic Analyzer Tool
Use this table to become familiar with some of the tools terms.
Navigating Through The

Tool
This term:
Refers to:
Filtering
a selection used to let packets that meet a specified condition to be

passed from the network to the buffer, or from the buffer to the
display. For example, you may set up an input filter that will only
allow packets with a source MAC ID of 10 to pass from the network
to the collection buffer.
Lpacket
link packetdata packaged and labeled by a node in preparation for

transmission
Trigger
a condition that causes data collection to start or stop. You specify

the condition the same way that a filter is specified.
Trigger Point
a point within the collection buffer where a trigger occurs. If the

trigger point is at the start of the buffer, data collection will begin
when a trigger condition is detected. If the trigger point is at the end
of the buffer, data collection will stop when a trigger condition is
detected.
SMAC
the ControlNet Media Access Control interface circuitry used to send

and receive data on an ControlNet network.
You can navigate through this tool using:

a mouse
Navigate through the tool using your mouse to make selections

from the drop-down menus, pop-up menus, and dialog boxes.
function keys and arrow keys

F1
F2
F3
F4
F5
F6
Use your arrow keys to make

selections from these menus.
F7
F8
Use your function keys

to access drop-down
menus, pop-up menus,
and dialog boxes.
393
You can access the tools online help:

through the Help drop-down menu
by choosing Help from a topics pop-up menu
System Requirements
Item
microprocessor
operating system
memory
hard disk space
video adapter and
monitor
disk drive
ISA/EISA bus
pointing device
Description
4 MB or higher
8 MB
VGA or high resolution
recommended: ATI VGAWonder XL card and color, super VGA
display (800 x 600)
one 3.5 high-density drive
ControlNet ISA/EISA bus tool (catalog no. 9220-KTCT)
for interfacing to the ControlNet network
The amount of RAM determines how much data you can capture4 MB captures 1.5 MB of data.
Important:
Make sure:
the CONFIG.SYS file contains the lines

there are not any device drivers or TSRs loaded except the
mouse driver software.
394
Installing The Tool
1. Insert the tool disk into your computers 3.5 disk drive.
mkdir directory_name
Enter
3. Change to that directory:

cd directory_name
Enter
4. Copy the contents of the tool disk to the directory you created.
copy A:*.*
Enter
5. Configure the mode of operation and video type by editing the

GO file.
A. edit go
Enter
B. Make changes to the file to reflect your computers video

type and the tools mode of operation.
Set the Display Screen to match your video type.
Set simulation to
true
To use the tool in

simulation modetool does
not interface with
9220-KTCT or network
network modetool
interfaces with 9220-KTCT
and acquires real data from
the network
false
C. Save your changes

D. Exit the file editor
Alt
Alt
+
+
+
+
Initializing The Tool
395
Before initializing the tool, determine:

what packets you want to capture (filter)
how much data you want to capture (buffer size)
when you want to capture the data, beginning or end (trigger)
when you want to view the data in respect to the trigger: before,
after, or before and after (trigger point)
1. Initiate use of the tools CONFIG.SYS file:
A. rename c:\config.sys c:\config.old
B. copy c:\directory_name\config.ta c:\
C. rename c:\config.ta c:\config.sys
D. Reboot your computer
Ctrl
Alt
Del
2. Start the tool:

This command should be performed in the directory
you created during installation, on page 394.
ta
Enter
You see:
396
Important:
If you see the following error message, your

computer is not using the CONFIG.SYS file
supplied with the tool. Repeat step 1.
***Abort: system not in 80286 or 80386 real mode ***
3. Click on Continue.
4. From Setup, choose SMAC Configuration, Initialize.
You see:
397
5.
If 9220KTCTs base I/O address is:
Then
default setting
Select save to exit this menu.
not default setting
a. Type in the new base I/O address.

b. Select save to exit this menu.
7. Using the online-help screens, configure the tools data collection

and display.
Access
by holding down your right mouse
button and dragging the mouse to the right.

You activate online help for an area by moving your cursor
to the area, and clicking on it with your right mouse button.
This selection:
Is used to:
Input
select where input data comes from: the network (live) or a

previously saved buffer file.
Pre-Collection
Filters
determine which packets get from the network source to the

collection buffer. If the source is a file, this block displays the
filter(s) used when the data was collected from the network.
398
This selection:
Is used to:
Trigger
define the trigger(s) for the next Run. If the source is a file, this
block displays the active trigger(s) when the data was collected from
the network. The options are Buffer Full, External, Pattern Seen,
and Pattern Not Seen. You can also use this block to toggle the
use of an External Trigger Seen Pulse.
Trigger Point
determine if the collected trigger packet will be at the beginning, in

the middle, or at the end of the buffer. If the source is a file, this
block displays the position used when the data was collected from
the network.
Layers Block
select the layer format for the data on the Main Scrolling List.
To display
Choose
Interpret
all layers and the data
LLC (LPacket)
the data broken into LPackets
MAC
show each MAC packet without interpretation
data exactly as it came from the SMAC
Data Only
PostCollection
Filters
determine what packets move from the buffer to the

collection display.
Display Block
toggle the displaying of the Time and ASCII Interpretation fields.
8.
To:
Choose:
make the new settings active
Exit, Make Setup Changes Active
cancel the changes
Exit, Abort Setup Changes
399
9. Start the tool choosing Run.
You see:
10.
save the image file and continue
Exit, Save & Continue
exit without saving
Exit, Quit & Forget
exit the tool, and save the image file
Exit, Quit & Save
This saves the initialized analyzer image with information on your environment to the directory you
created for the tool on your hard drive.
3910
Using The Tool
This figure shows the functional blocks for navigation through the
tool, with each block representing a single window. Each window
contains a help menu that explains the windows menus and features.
Packet Details
Display
Analyzer Collection
and Display Setup
SMAC
Initialization
PC Color and
File Setup
Filter and Trigger Pattern Editors
For information on:

interpreting the data
viewing details of a single packet
customizing your operating environment
adding and editing filter and trigger patterns
editing the tag and control bytes
using the search utility
using the print utility
using the file utility
using the statistics utility
examples using the tool
See page:
3910
3911
3912
3913
3914
3915
3915
3916
3917
3919
Interpreting the Data

When you run the tool, information is displayed as follows:
Access by holding down your right mouse

button and dragging the mouse to the right.

3911
This area: Displays:

the time each packet was received relative to the Trigger Position/Packet
(in this case, the first packet)
whether the SMAC thought the packet was good or bad
the type of packet: S = scheduled, U = unscheduled, M = moderator, P = PTC
the source MAC ID
a Hexadecimal dump of the packet data
an ASCII interpretation of the packet data
Viewing Details of a Single Packet

To view information on a particular packet, click on the packet from
the Main Scrolling List with your left mouse button.
3912
Customizing Your Operating Environment

To customize your workstations operating environment, choose
Setup, PC Environment Configuration. Edit the fields as necessary,
and Save your changes.
3913
Adding and Editing Filter and Trigger Patterns

You can add and edit filter and trigger patterns in the Traffic
Analyzer Setup. To get to these editors, choose Setup, Analyzer
Collection and Display Setup.
To access this editor:
Pre-collection Filter Patterns
Choose:
Pre-collection Filters, Select Filters
Trigger Patterns: Pattern Seen
Trigger, Pattern Seen
Trigger Patterns: Pattern Not

Seen
Trigger, Patter Not Seen
From within the Filter or Trigger editor,

you click in the tag field with the left
mouse button and then the right
mouse button to access the Tag Bytes
Editor or in the control field to access
the Control Bytes Editor. See the
following page for more information.
3914
Editing the Tag and Control Bytes

From within the Filter and Trigger editors (described on page
3913), you can click in the tag field with the left mouse button and
then the right mouse button to access the Tag Bytes editor or in the
control field to access the Control Bytes editor.
Tag bytes editoryou select the type of tag (fixed or generic),
its value, and if its fixed, its destination. For fixed tags, you
select from the reserved and pre-defined fixed tags in the
lower-half of the screen.
Access additional defined tags

by holding down your right
mouse button and dragging
the mouse downward.
Control bytes editoryou can edit each bit of the control byte
for an LPacket.
Each field can be set to Off (0),

On (1), or doesnt matter (X).
3915
Using the Search Utility

Use the Search drop-down menu to search the buffer for specific:
times relative to the trigger point
bit patterns
packet types
packet status
ASCII strings
The example belows shows the search for a specific time.
Using the Print Utility

The Print drop-down menu lets you print all or a portion of the
displayed buffer. The print-out includes a summary of the setup used
when the data was captured, followed by the data as shown on the
display.
3916
Using the File Utility

To:
Choose:
write the buffer to a binary file for later

use as input.
File, Write Buffer to File
write the buffer to an ASCII file for

viewing and printing
File, Write Display to File
view and edit files and directories from

within the tool
Browse Disk
You can choose to take the buffers contents before or

after post-collection filtering has occurred.
You can choose to write all or a portion of the displayed buffer

to a file. The file includes a summary of the setup used when
the data was captured, followed by the data as displayed.

Lists directories
Lists files in
selected directory
Lists contents of
selected file
Each pane in this window has a

pop-up menu you access by
placing the cursor in the pane, and
clicking the right mouse button.
3917
Using the Statistics Utility

You use the Statistics drop-down menu to view information based on
the data collected from the network.
Information on:
network performance
Is available for:
a. network traffic
As shown in:
below
b. network utilization
timing
on page
two selected packets
3918
byte count
on page
a. for selected packets
3918
b. for the entire buffer
Displays network traffic

statistics for a single
buffer full of data.
A graph displays how traffic is
distributed among the nodes on
the network.
Displays how network

utilization varies over
time.
A graph displays network

utilization for a group of
nodes.
3918
Displays the time difference between

the top (oldest) and bottom (youngest)
packets.
Displays how many bytes are in the

selected packets. This helps you measure the amount of data put onto the network for a particular type of transaction.
You can also display a byte count of the
buffer. This count is divided into bytes of
data and bytes of overhead.
"
To select more than one packet, hold the shift key and use your
mouse to select the additional packet(s).
3919
Examples
Use these examples for additional assistance on configuring the tool.
Example 1
This example shows you how to use the tool to:
S
S
S
S
collect all packets originating from nodes with 02 and 04 MAC IDs
collect 100 KB of data
detect when a fixed tag of Command Read Counters occurs
collect data before and after the fixed tag is detected
1. Start the tool.

3. From Pre-collection Filters, choose Select Filters.
3920
4. Specify that MAC packets with a source ID of 02 or 04 will be passed to

the buffer for data collection.
A. In the MAC ID field, type in 02.
B. Select Add.
C. Repeat A and B, typing in 04 instead of 02.

D. Select Save.
5. To enable filtering, from Pre-collection Filters, choose Turn Filtering On.
3921
6. Set the size of the buffer to100 KB.

A. From Packet Buffer, choose Buffer Size.
B. Type in 100000 for the buffer size
Enter
3922
7. Set a trigger to occur when a packet with a fixed tag of Read Counters is
detected passing through the filter.
A. From Trigger, choose Pattern Seen.
B. In any Tag field, click the left mouse button to select the tag, and
then the right mouse button to access the defined tags.
C. From the defined tags, choose (18) Cmd Read Counters.
3923
D. Select Save.
E. From the center menu, select Add.
F.
From the top menu, select Save.
8. Set the trigger point to the middle of the buffer by clicking with your left
mouse button on the center box in the Trigger Point block.
3924
9. Save this configuration to a file.

A. Choose File, Write Setup to File.
B. Type in a new name for the file
Enter
10. Make these changes active. Choose Exit, Make Setup Changes Active.
11.
To:
Choose:
exit without saving
Exit, Quit & Forget
3925

Exit, Quit & Save
Example 2
This example shows you how to use the tool to view:
S
S
S
S
data as LP packets
all packets
data in ASCII to help find text string
collect data before and after the fixed tag is detected
1. Start the tool.

3. Click with the left mouse button on LLC (LPacket).
3926
4. Set the filter option so that all packets in the buffer pass through to the
display block. From Post-collection Filters, choose Turn Filtering Off.
If you want to specify which filters pass through to the

display, edit the filters as shown in steps 3 and 4 on pages
3919 and 3920.
5. From Display, choose Hex / ASCII.
6. Save this configuration to a file.

A. Choose File, Write Setup to File.
B. Type in a new name for the file
3927
Enter
7. Make these changes active. Choose Exit, Make Setup Changes Active.
8.
To:
Choose:
exit without saving

Exit, Quit & Forget
Exit, Quit & Save
3928
Troubleshooting
If you select Run and no data is displayed you need to reset or

initialize the traffic analyzer tool.
Resetting the Tool

1. Choose Setup, SMAC Configuration, Reset.
2. Choose Run.
Initializing the Tool

1. Choose, Setup, SMAC Configuration, Initialize.
2. Change the tools data collection and display configuration as

necessary. For additional information on your options, see page
397.
3929
3. Choose Exit, Make Setup Changes Active.
4. Choose run.
3930
Notes:
Chapter
40
ControlNet Transceiver Hybrid

Data Sheet
This chapter introduces the ControlNet transceiver hybrid (cat. nos.
9904-HYBD, -HYBS). It contains these sections:
Section
Page
Shipping Protection
401
Solvent Resistance
401
Solderability
402
Mechanical Dimensions
402
Package Pinout
404
Block Diagram
406
Circuit Description
406
Truth Table
407
Absolute Maximum Ratings
407
Recommended Operating Conditions
407
Electrical Characteristics
408
AC Characteristics
408
Shipping Protection
Package container shall provide adequate protection for the devices

(including static charge protection when appropriate) to withstand
normal handling and shipping.
Solvent Resistance
The part shall exhibit no immediate or long range deterioration of

electrical or mechanical parameters including finish, coating,
marking or sleeving when subjected to any of the following:
1. Subjected to 1:1:1 Trichloroethane vapor at 165o F for 90 seconds
a total of four times with a minimum time of one hour between
exposures.
2. Immersed in a 10% Alpha 2100 solution (or equivalent aqueous
cleaner) at 180o F for 90 seconds a total of four times with a
minimum time of one hour between exposures.
3. Immersed in Freon-TMC at its boiling point (approximately
97.2o F) for 90 seconds a total of four times with a minimum time
of one hour between exposures.
402
ControlNet Transceiver Hybrid Data Sheet
Solderability
Solderability shall conform to MIL-STD-202 Method 208, latest

revision.
Mechanical Dimensions
The figures below show mechanical dimensions for the transceiver

hybrid.
Figure 40.1
Mechanical Dimensions, Dual Channel Transceiver
(cat. no. 9904-HYBD)
403
Figure 40.2
Mechanical Dimensions, Single Channel Transceiver
(cat. no. 9904-HYBS)
404
Package Pinouts
The following figures show package pinouts for the transceiver

hybrid.
Figure 40.3
Package Pinout, Dual Channel Transceiver
(cat. no. 9904-HYBD)
405
Figure 40.4
Package Pinout, Single Channel Transceiver
(cat. no. 9904-HYBS)
406
Block Diagrams
Important:
Channel B is used only on cat. no. 9904-HYBD

(Dual Channel Transceiver Hybrid).
Figure 40.5
Block Diagram (both cat. nos.)
Channel B used only on cat. no. 9904-HYBD

(Dual Channel Transceiver Hybrid)
Circuit Description
The ControlNet Transceiver Hybrid provides driver abd receiver

circuitry for the ControlNet-based physical layer. Two versions of
the hybrid circuit are available. Cat. no. 9904-HYBD is a
dual-channel circuit with two independent transceivers included for
redundant node or repeater applications. Cat. no. 9904-HYBS is a
single-channel circuit with one transceiver for single-node or
distributed standalone applications.
The receiver uses a RS-422 line receiver with unique high-sensitivity
and wide operating temperature and power supply specifications.
Truth Table
Transmitter
TX In
407
Receiver
eceiver
TX Out
TXEN
TX
TXBAR
XF1
XF3
RX Inputs
RX Outputs
H
H
L
L
L
H
Z
Z
Z
L
XF3-XF1
3- 1 > Vthh
thh
R =H
RX
XF3-XF1 < Vthh
RX = L
X
X
X
X
X
X
X
X
L
Z
Z
Z
Z
Vth < XF3-XF1 <Vthh; RX = Undefined
L
L
L
L
L
Z
Z
Z
Z
XF11 > Vcdl

cdl
CD
D=L
XF11 < Vcdh

cdh
CD
D=H
This combination is not supported in ControlNet applications and should be avoided.
Absolute Maximum
Ratings
(All voltages are referenced to ground.)

No.
Recommended Operating
Conditions
Item
Symbol
Rating
Unit
Remarks
DC Supply Voltage
Vcc
0.0 to 7.0
TX Input Voltage
Vin, TX
-0.5 to Vcc+0.5
RX Input Voltage
Vin, RX
-12.0 to +12.0
TX Input Current (per pin)
Iin, TX
-20 to +20
mA
TX Output Current
Iol, TX
500
mA
Operating Temperature
Range
Topr
0 to +85
oC
Storage Temperature
Tstg
-65 to +150
oC
Input Capacitance
Cin
11
pF
Relative Humidity
Hstg
90
% R.H.
The input capacitance between pins XF1 and XF3 is a very sensitive point on the hybrid. This
parameter is sample tested on five pieces/production lot (minimum) to verify that Cin < 11pf. Test
conditions are 10mHz AC test frequency, 1V p-p amplitude using an HP4194A or equivalent
impedance analyzer.
No.
Rating
Symbol
Min
DC Supply Voltage
Vcc
4.5
TX Input Voltage
Vin, TX
RX Input Common Mode Voltage
Vin, RX
4.5
TX Peak Output Current
Iin, TX
RX High Level Output Current
Ioh, RX
Rx Low Level Output Current
Iol, RX
Operating Temperature Range
Topr
Typ
5
110
Max
Unit
5.5
Vcc
5.5
V
mA
-440
mA
85
oC
408
(Over recommended operating conditions.)
No.
AC Characteristics
Rating
Min
Typ
4.5
5.5
4.5
5.5
Vcc
3.15
3.85
2.25
2.75
2.25
2.75
110
Max
Unit
1.35
1.65
V
V
V
V
+/-0.1
4.5
1.00
Vol, RX
4.5
0.45
RX Output High Voltage

Iol = 44A
Voh, RX
4.5
RX High Level Output Current
Ioh, RX
-440
RX Low Level Output Current
Iol, RX
mA
RX Short Circuit Output Current

(one output for < 1 second)
Ios, RX
-85
mA
10
Quiescent Supply Current

Vin, TX = Gnd (TX Off)
Iccq
5.5
54
74
mA
11
Positive Zener Breakdown
Vz+, XFx
5.5
11.8
54
13.2
Vdc
12
Negative Zener Breakdown
VZ-, XFx
5.5
-13.2
54
-11.8
Vdc
Tx Input High
igh Voltage
oltage
Vih,
ih, TX
T
T Input Low
TX
Lo Voltage
oltage
Vil,
il, TX
T
TX Input Leakage Current

(Vin, TX = Vcc, Gnd)
Iin, TX
5.5
TX Output Low Voltage

Iol = 100mA (XF1, XF3)
Vol, TX
RX Output Low Voltage

Iol = 8mA
2.7
-15
(Over recommended operating conditions.) AC characteristics are

verified by the supplier using specific tests for data transmit
voltages, and data receive and carrier detect threshold voltages.
These test require a specific transformer, cat. no. 9904-XFMR.
No.
Symbol
Parameter
Symbol
Min
Typ
Max
Manchester Data Rate
fd
Differential Input High

Threshold (Vcm = 5V)
Vthh
Differential Input Low

Threshold (Vcm = 5V)
Vthl
Hysteresis
Vhyst
Carrier Detect Low

Threshold
Vcdl
Carrier Detect High

Threshold
Vcdh
Vcc - 255
mV
Receiver Input
Resistance (XF3 input
to AC ground)
Rin, XF3
12k
Ohms
Receiver Input
Resistance (XF1 input
to AC ground)
Rin, XF1
6k
Ohms
Unit
Mbaud
120
-120
mV
mV
50
mV
Vcc - 23
mV
Chapter
41

This chapter introduces the ControlNet crystal (cat. no. 9904-XTAL).

It contains these sections:
Section
Page
Allen-Bradley Manufacturing Notes
411
Solderability
411
Shelf Life
411
Solvent Resistance
411
Connections
412
Package Dimensions
412
413
413
Environmental Characteristics
413
Allen-Bradley
Manufacturing Notes
This component is fragile. Rough handling in storage or

manufacturing will damage the part. Parts are procured taped and
reeled for automatic insertion.
Solderability
Solderability shall conform to #ANSI/J-STD-001, latest revision.
Shelf Life
Maximum age before usage is 30 months by date code. Maximum

age when received by Allen-Bradley is 12 months by date code.
Solvent Resistance

electrical parameters or damage to the part, its finish, coating,
marking or sleeving, when subjected to any of the following
procedures:
1. Subjected to water wash system at 160o F for 120 seconds, a total
of three times, with a minimum time of one hour between
exposures.
3. Exposed to standard industrial flux compounds, both washable
and non-washable.
412
Crystal Data Sheet
Connections
Part Number
Rev
Description
CI
R1
(max)
943649-02
Crystal, SMT 60.00 MHz, 85o C,

3rd overtone
15 pF
80
The figure below shows internal connections:
Package Dimensions
Min
Max
0.530 (13.46)
0.508 (12.90)
0.200 (5.08)
D, E
0.102 (2.58)
0.169 (4.30)
G
H
0.180 (4.57)
0.007 (0.2)
I, J
0.045 (1.15)
0.134 (3.40)
The figure below shows the package dimensions listed in the table
above.
Crystal Data Sheet
Absolute Maximum
Ratings
Environmental
Characteristics
413
Limits
Parameter
0oC to +85oC
Storage Temperature Range
-55oC to +125oC
Drive Level
1.0 mW
Parameter
Specifications
Frequency
See Tabulation.
Frequency Tolerance
$0.005% (50 PPM) @25oC
Temperature Stability
$0.01% (100 PPM) from 0oC to 85oC
Mode of Operation
Parallel with CI = See Tabulation $0.1 pf
Maximum Equivalent Series Resistance

(R1)
See Tabulation.
Cut
AT equivalent
Mode of Oscillation
Third overtone
Drive Level (operating)
100
Holder
MA -506
Maximum Shunt Capacitance (C0)
5.0 pf
Aging
5 PPM max./yr.
Parameter
Conditions
Frequency Change
Thermal Shock
Per Method 107 of MIL-STD

202, Condition B1, 25 Cycles
$5 PPM max.
Mechanical Shock

202, Condition A
$10 PPM max.
High Frequency Vibration

202, Condition A
$5 PPM max.
Random Vibration

202, Test Condition IA,
Duration 1 1/2 hours
$5 PPM max.
Seal

202, Condition C, Procedure
III
1 EE -8 atm cc/sec
Resistance to Soldering Heat

202, Condition B, 0.025 from
the base
$5 PPM max.
414
Crystal Data Sheet
Notes:
Chapter
42

This chapter introduces the ControlNet crystal oscillator(cat. no.
9904-OSC). It contains these sections:
Section
Page
Package Marking And Shipping Protection
421
A-B Manufacturing Notes
421
Supplier Source
421
Solvent Resistance
422
Solderability
422
Wave Solderable
422
Shelf Life
422
Figures
423
Package Dimensions
424
Truth Table
424
Pin Description
424
425
425
Environmental Characteristics
426
Package Marking And

Shipping Protection
Parts shall be tape-and-reeled per Allen-Bradley specifications for

automated assembly. Package containers shall provide adequate
protection for the devices (including static charge protection when
appropriate) to withstand normal handling and shipping, and shall be
legibly marked with both the manufacturers name and part number
and the Allen-Bradley part number and purchase order number.
Packaging shall meet Allen-Bradley requirements for automatic
placement.
A-B Manufacturing Notes
This component is fragile. Rough handling in storage or

manufacturing will damage the part.
Supplier Source
Approved supplier source controlled by ASL. Purchase per

Allen-Bradley drawing specification.
422
Solvent Resistance

electrical or mechanical parameters or damage to the part, its finish,
coating, markings, or sleeving, when subjected to any of the
following procedures:
1. Subjected to water wash system at 160o F for 120 seconds, a total
of three (3) times, with a minimum time of one (1) hour between
exposures.
2. Immersed in Freon-TMC at its boiling point for 90 seconds a total
of four times with a minimum time of one hour between
exposures.
3. Exposure to standard industrial flux compounds, both washable
and non-washable.
Solderability
Solderability shall conform to #ANSI/J-STD-002, Category 3, latest

revision.
Wave Solderable
The part shall maintain its hermiticity when subjected to wave solder
temperature of 260o C +/-5o C for 10 seconds maximum to a
distance of 0.025 inches from the oscillator body.
Shelf Life
Maximum age before usage is 30 months by date code.

Maximum age when received by Allen-Bradley is 12 months by
date code.
Part Number
Rev
Description
Startup Time
(msec)
943749-21
OSC/HYB 60.0000 MHz, 85o C
10
Figures
423
The figures below show various views of the crystal oscillator. All
dimensions are in inches, unless noted otherwise. Unless otherwise
specified:
Material:
Housing Ceramic
Lid Kovar metal
Contacts Tungsten
Finish:
3.81 micron (150 micro-inches) minimum Tin-lead over
1.27 microns (50 micro-inches) minimum Nickel
Figure 42.1
Bottom View
Figure 42.2
Top View
Figure 42.3
Side View
424
Figure 42.4
Suggested Solder Pad Layout
Place decoupling capacitor

as close to oscillator as
possible.
Package Dimensions
Truth Table
Min.
A
0.295
0.205
0.102
0.045
0.055
0.210
0.084
0.020
0.040
0.020
0.030
Enable
Disable
H= Logic 1 or Vih or Open

L= Logic 0 or Vil
Output becomes high impedance when disabled.
Pin Description
Max.
Enable/Disable
Ground
Output
+5 VDC
Absolute Maximum
Ratings
425
Parameter
Max.
0 to 85
Units
oC
Storage Temperature Range
-55 to 125
oC
Input Voltage
5.5
Supply Voltage
7.0
Parameter
Conditions
Min.
Max.
Units
Supply Voltage
4.5
5.5
Breakdown Voltage
-0.5
50
mA
Output Load Capacitance, Cl
<50 MHz
50
pf
Output Load Capacitance, Cl
<50 MHz
15
pf
Short Circuit Output Current
1 minute maximum @
25o C
50
mA
Frequency Stability
+/-100
PPM
Symmetry
@ 1/2 VDD
60/40
Logic 0 (Vol)
@ Cl = 50 pf
0.5
Logic 1 (Voh)
@ Cl = 50 pf
Logic 0Sink Current (lol)
@ 0.4 V
16.0
Logic 1Source Current (loh)
@ 3.7V
-16.0
Rise Time (tr)
10-90% VDD, 50 pf
10
ns
Fall Time (tr)
10-90% VDD, 50 pf
10
ns
Startup Time (ts)
Enable/Disable Time
@ VDD = 5.0V and

25o C
100
ns
Enable Input High Voltage

(Vih)
@ VDD = 5.0V
Enable Input Low Voltage (Vil)
@ VDD = 5.0V
0.8
Enable Input High Current
@ VDD = 5.25V
50
Enable Input Low Current
@ VDD = 5.25V
-2
mA
Supply Current
40/60
VDD -0.5V
2.2
V
V
Drives both TTL/C-MOS devices.
Frequency Stability is inclusive of calibration tolerance at 25 o C, operating temperature range,

input voltage change, load change, aging, shock and vibration.
Startup time is the time measurement from the instantaneous application of VDD to an oscillating
output. The specification applies over the operating temperature range and voltage range of the
device.
Output becomes high impedance when disabled.
426
Environmental
Characteristics
Parameter
Conditions
Frequency Change
Temperature Cycle (Non-operating)
25 cycles minimum, -55o C to +125o C per method 1010 of MIL-STD-883
+/- 15 PPM maximum
Mechanical Shock (Non-operating)
1500 G, 0.5 mS, 3 shocks per direction per method 2002 of MIL-STD-883
+/- 10 PPM maximum
Sinusoidal Vibration
0.06 Double Amplitude, 10 to 55 Hz and 30 G, 55 to 2000 Hz, 3 cycles per

direction per method 2007 of MIL-STD-883
+/- 10 PPM maximum
Random Vibration
20 G (rms), 20 to 2000 Hz per method 2026 of MIL-STD-883
+/- 10 PPM maximum
Per conditions A and C in method 210 of MIL-STD-202
+/- 10 PPM maximum
Electrostatic Discharge Sensitivity
2.0 kV minimum
Aging
Per method 3015 of MIL-STD-883

@ 85o C
1000 hours @ 125o C per method 1005 of MIL-STD-883
+/- 50 PPM maximum
Figure 42.5
Output Waveform
+/- 10 PPM/yr.
maximum
Chapter
43

This chapter introduces the ControlNet transformer (cat. no.
9904-XFMR). It contains these sections:
Section
Page
Shipping Protection
431
Solvent Resistance
431
Solderability
432
Industry Standards Requirements
432
Approved Vendors
432
Mechanical Information
432
Construction Information
434
435
Shipping Protection
Package containers shall provide adequate protection for the device

to withstand normal handling and shipping. The shipping material
shall be legibly marked with the manufacturers name,
Allen-Bradleys part number and purchase order number.
Solvent Resistance

electrical or mechanical parameters including finish, coating,
marking or sleeving when subjected to any of the following:
1. Subjected to 1:1:1 Trichloroethane vapor at 165o F for 90 seconds
a total of four times with a minimum time of one hour between
exposures.
2. Immersed in a 10% Alpha 2100 solution (or equivalent aqueous
cleaner) at 180o F for 90 seconds a total of four times with a
minimum time of one hour between exposures.
432
ControlNet Transformer Data Sheet
Solderability
Solderability shall conform to MIL-STD-202 Method 208, latest

revision.
Industry Standards
Requirements
This item is specified by an investigating agency (e.g., UL, CSA).

Changes to this item require engineering/industry standards
approval.
Approved Vendors
Approved vendors controlled by ASL.
Mechanical Information
Core Information:
Size Industry standard type EP-7 Ungapped
Material Magnetics, Inc. F minimum AI value =
1100mH/turn
Bobbin Information:
Size 6-pin single-section PCB mount (must use Siemens
B65840-A1000-D1)
Pin Notes Cross-section maximum diameter or diagonal
0.028
Cross-section minimum diameter or diagonal
0.018
Length Must extend at least 0.100 but no more than
0.156 below mounting surface line
Solderability Shall conform to MIL-STD-202, Method
208, latest revision
Clip Information:
Size Must use Magnetics, Inc. EP7 clips
Use clips to hold the core halves together. Do not use glue
Clip Pin Notes Cross-section maximum diameter or
diagonal 0.020
Cross-section minimum diameter or
diagonal 0.012
Wire Information:
36 AWG solid copper magnet wire with double (1 Mil)
insulation
Insulation System:
All materials must be compatible with UL Class A (105o
C) or better
Flammability:
All materials must be compatible with UL-94V-0, V-1 or
V-2
433
Figure 43.1
Top View
Figure 43.2
Side View
Figure 43.3
Required PCB Hole Pattern
434
Construction Information
The figures below show package pinouts for the transceiver hybrid.
Figure 43.4
Construction Schematic
Figure 43.5
Schematic Symbol
435
Electrical Specifications
All specifications are rated at 25o C.
Table 43.A
DC Resistance
Winding Pins
Maximum Resistance
1 to 2
500 mOhms
2 to 3
430 mOhms
4 to 6
475 mOhms
Measurements conducted between pins 4 and 6 with pin 2 connected

to ground:
Min.
Typ.
Inductance
350 uH
750 uH
Winding Capacitance
16.0 pf
24.8 pf
29.5 pf
8.0 K
9.1 K
11.2 K
Parallel Resistance (Core Loss)

Leakage
Inductance
Resonant Frequency
Max.
255 nH
441 nH
625 nH
1.0 MHz
1.4 MHz
1.8 MHz
@ 40 KHz 100mV
@ 10 MHz
Short pins 4 and 6; measure from 1 to 2
Dielectric Test
Each transformer must be subjected to the following dielectric test.
Failure is defined as a current flow greater than 1.0 mA AC. All
tests may be conducted at room temperature. The AC waveform
used shall be essentially sinusoidal, 47-63 Hz. Any of the following
combinations of test voltage and time are acceptable:
500 Vac rms for 1 minute
or
600 Vac rms for 1 second
STRAP PINS: 1, 2, 3;
4,6.
TEST FROM: 1, 2, 3 to 4, 6;
1, 2, 3 to CORE;
4, 6 to CORE.
436
Notes:
Chapter
44
CNA10 ControlNet ASIC Data Sheet

This data sheet contains information on the CNA10 ControlNet
ASIC, catalog numbers 9904-CNA10T (TQFP) and 9904-CNA10M
(MQFP). This chapter contains these sections:
Section
Page
Features
442
Overview
443
Description
446
CNA10 Pins
447
Network Configurations
4432
Package Dimensions
4445
Maximum Ratings
4447
4449
Oscillator and Crystal Specifications
4450
Host Interface Timing
4451
LEDs
4461
System Considerations
4467
External Comm Processor ROM
4470
Errata
4471
442
Features
Easily interfaces to microprocessors

Supports redundancy and NAP connections
Supports repeater operation
8 and 16 bit interface to a 3072 byte dual port RAM
All received data is fully quarantined
Provides 31 multicast connections
Relieves Application Processor of buffer management in
accordance of the channel configuration
Supports Transport Class 1 & 3
Thin package for PCMCIA applications (TQFP only)
Executes Comm Processor code externally.
Temperature Range:
MQFP 0o C to 85o C
TQFP 0o C to 75o C
Clock isolation for board testing

Network Address port
443
Figure 44.1
CNA10 with Redundancy and NAP Connection
Vdd
ALE or
/AS
Address Bus
CPU
Data Bus
/CE
TxDataOut
ALE/AS
TxDataBar
NetEnb_A
Addr[11:0]
G_NetEnb
NetEnb_B
Data[7:0]
/Rd or /DS
/Rd_/DS
/Wr or R/W
/Wr_R/W
Interrupt
Irq0
Ready or
/Dtack
Ready
or /Dtack
RxData_A
RxCarrier_A
RxData_B
RxCarrier_B
/TxPTC
/RxPTC
Tx_A
Tx_B LANXCVR
TxBar_A
TxBar_B
TxEnA Hybrid
XF1_A
TxEnB
Rx_A
Cd_A
Rx_B
Cd_B
Xtal_In
Xtal_Out
XF1_B
NAP
Rcvr/Drvr
CH B
NAP Tx
NAPRx
Channel A LED
LED_B_Red &
LED_B_Green
Channel B LED
ROM_Data[7:0]
Xfmr
XF3_B
LED_A_Red &
LED_A_Green
ROM_Addr[15:0]
CH A
XF3_A
CNA10
MacID[7:0]
Xfmr
ROM
RAM
or FLASH
Memory
Vss
Overview
The ControlNet CNA10 is a Standard Cell based ASIC (Application

Specific Integrated Circuit) that allows price sensitive products to
connect to ControlNet.
The ASIC is intended to allow the application processor of a product
to connect directly to it via a 3072 byte dual port RAM. Since most
of the communication processing is handled by the CNA10, this
allows a less of a burden on the application processor.
Figure 44.1 represents a connection diagram using the CNA10 in a
redundancy and NAP (Network Access Port) connection application.
Figures 44.2 and 44.3 depict the pin configurations of the TQFP
(Thin Quad Flat Pack) and MQFP (Metric Quad Flat Pack).
444
75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
60
59
58
57
56
55
54
53
52
51
Tone
/Irq0
ROM_Addr[1]
/Irq1
Data[0]
ROM_Addr[2]
Data[1]
Data[2]
ROM_Addr[3]
Data[3]
ROM_Addr[4]
Vss
Vdd
ROM_Addr[5]
Data[4]
Data[5]
ROM_Addr[6]
Data[6]
Data[7]
ROM_Addr[7]
Ready
/Dtack
Vss
ALE/AS
/CE
Figure 44.2
TQFP CNA10 Pin Placements
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
VLSI
(Date) (Assy) (Fab) (Die) (Lot)
50
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
/Rd_/DS
/Wr_R/W
ROM_Addr[8]
MacID[0]
MacID[1]
ROM_Addr[9]
MacID[2]
MacID[3]
Vss
ROM_Addr[10]
n/c
Vdd
ROM_Addr[11]
MacID[4]
MacID[5]
ROM_addr[12]
MacID[6]
MacID[7]
ROM_Addr[13]
/HBE
Addr[0]
ROM_Addr[14]
Addr[1]
Addr[2]
Addr[3]
/Sys_Reset
/TME
ROM_Data[4]
/Test_Clk
ROM_Bypass
Vss
ROM_Data[3]
Vdd
ROM_Data[2]
Xtal_Out
/Xtal_In
ROM_Data[1]
Clock_Out
ROM_Data[0]
Vss
Addr[11]
Addr[10]
Addr[9]
Vdd
Addr[8]
Addr[7]
Addr[6]
ROM_Addr[15]
Addr[5]
Addr[4]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
LED_B_Green
LED_B_Red
ROM_Addr[0]
LED_A_Green
LED_A_Red
G_NetEnb
/Reset_Out
n/c
Vdd
Monitor
Vss
NetEnb_B
NetEnb_A
n/c
ROM_Data[7]
/RxPTC
/TxPTC
TxDataBar
ROM_Data[6]
TxDataOut
RxMisc_B
RxData_B
ROM_Data[5]
RxMisc_A
RxData_A
/ indicates active low
445
100
99
98
97
96
95
94
93
92
91
90
89
88
87
86
85
84
83
82
81
ROM_Addr[0]
Led_A_Green
Led_A_Red
G_NetEnb
/Reset_Out
n/c
Vdd
Monitor
Vss
NetEnb_B
NetEnb_A
ROM_Data[7]
/RxPTC
/TxPTC
TxDataBar
ROM_Data[6]
TxDataOut
RxMisc_B
RxData_B
ROM_Data[5]
Figure 44.3
MQFP CNA10 Pin Placements
80
79
78
77
76
75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
60
59
58
57
56
55
54
53
52
51
RxMisc_A
RxData_A
/Sys_Reset
/TME
ROM_Data[4]
/Test_Clk
ROM_Bypass
Vss
ROM_Data[3]
Vdd
ROM_Data[2]
Xtal_Out
/Xtal_In
ROM_Data[1]
Clock_Out
ROM_Data[0]
Vss
Addr[11]
Addr[10]
Diag_Int
Addr[9]
Vdd
Addr[8]
Addr[7]
Addr[6]
ROM_Addr[15]
Addr[5]
Addr[4]
Addr[3]
Addr[2]
ROM_Addr[8]
MacID[0]
MacID[1]
ROM_Addr[9]
MacID[2]
MacID[3]
Vss
ROM_Addr[10]
Vdd
ROM_Addr[11]
MacID[4]
MacID[5]
ROM_Addr[12]
MacID[6]
MacID[7]
ROM_Addr[13]
/HBE
Addr[0]
ROM_Addr[14]
Addr[1]
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
VLSI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
(Date) (Assy) (Fab) (Die) (Lot)
Led_B_Red
Led_B_Green
Tone
/Irq0
ROM_Addr[1]
/Irq1
Data[0]
ROM_Addr[2]
Data[1]
Data[2]
ROM_Addr[3]
Data[3]
ROM_Addr[4]
Vss
MS/Mio
Vdd
ROM_Addr[5]
Data[4]
Data[5]
ROM_Addr[6]
Data[6]
Data[7]
ROM_Addr[7]
Ready
/Dtack
Vss
ALE/AS
/CE
/RD_/DS
/WR_R/W
/ indicates active low
446
Description
A block diagram of the CNA10 ASIC is represented in Figure 44.3

Communications on ControlNet are handled by two internal RISC
processors. The MAC processor implements the MAC layer, transmit
scheduler, station management functions, fixed tag screening and
diagnostics. The Comm processor implements ControlNet functions
that sit above the MAC processor. These functions are the producer
and consumer objects, link layer, station and buffer management
functions, quarantining of received data and screener tag sorting.
The Comm processor is also responsible for the upkeep of the
screener Connection IDs (CIDs). The screener is divided into two
tables, an active table and an inactive table. Each table can hold up to
31 CIDs. The screener uses the active table to compare with the
incoming packets. The Comm processor uses the inactive table for
tag manipulation and setup. The screener CIDs are updated when the
tables are swapped
A simplistic explanation of how the CNA10 receives data is that the
received data enters one of the Rx ports (Channel A, Channel B or
NAP) of the High_Speed data and clock recovery block. Data and
clock are recovered from the bit stream and passed onto the Modem.
The Modem will remove the start and end delimiters and perform the
CRC checking while passing the serial packet onto the RxBlock. If
the Modem detects an error (Manchester violation or CRC), the error
is logged and the appropriate LED indication is flashed. The
RxBlock performs the serial to parallel conversion and the Lpacket
tag screening. If the Lpacket is accepted by the screener or if the
MAC processor accepted it as a fixed tag, then the Lpacket is loaded
into the Rx FIFO. The Comm processor transfers the Lpacket to a
dual port RAM buffer and quarantines it until the entire MAC packet
is received without any errors. When the MAC packet is received
without any errors, the host is notified by an interrupt. The host will
not be notified of the Lpacket if the MAC packet was received with
an error.
When the host wants to transmit, a Lpacket is loaded into a dual port
RAM buffer and the Comm processor is interrupted. The Comm
processor organizes a Lpacket data queue according with the
network configuration parameters. It then transfers the queued
Lpacket to the Tx FIFO. When it is the nodes turn to transmit, the
MAC processor will give the command to transmit the FIFO. The
Tx_Assm in the modem will assemble the MAC packet (start
delimiters, Lpacket(s), CRC and the end delimiters) and route it out
to the transmit pins.
The CNA10 has provided the capability to bypass the crystal by
activating the /TME input. This feature can be useful for
manufacturing test when the tester needs to clock the ASIC at a
frequency other than 60 MHz.
447
Figure 44.4
CNA10 Block Diagram
Clock_Out
Host
Interface
ROM ROM
Bypass Addr
ROM
Data
Comm
Processor
Dual Port
16 bit RISC
3k x8 RAM
Double Buffered Dual

Port Screener Table
Tx
FIFOs
Rx
FIFO
1k x 16 RAM
Test_Clk
Clock
Modem
Tx
Assm
RxBlock
Jabber
Rx
Sys
Host_Stuff
LED
Cntrl
Registers
M
U
X
LEDs
Fixed Timer
Parallel MacID port
Padring, etc.
TxDataOut
Tx_PTC
High_Speed
Clock &
Data Rcvry
Ch A
RxData_A
Ch B
RxData_B
PTC
Rx_PTC
MAC
Processor
8 bit RISC
6k x 8 ROM
Tone
NetEnb_A
NetEnb_B
G_NetEnb
256 x 8 RAM
/TME
Network Address
NUT timer
Slot Timer
CNA10 Pins
This section will define the pin configurations for the CNA10. The
slash character (/) preceding a signal name denotes active low.
Signals with one name, a slash, and a second name are dual function
with a high to activate the first function and a low to activate the
second.
Pins which are used as inputs must never be allowed to float for any
significant period of time. All output pins that autoconfigure, any
inputs that are unused, and any inputs not driven by an active driver
at all times, must have a pullup or pulldown. This is to prevent the
significant power dissipation which occurs when the inputs float to
the switching point which puts the ASIC input buffer transistors in
the active region.
The /Sys_Reset and ALE/AS inputs will use schmitt
trigger TTL level shifters (due to potentially slow rise/fall times).
All other inputs use TTL level shifters. This allows the ASICs to be
compatible within the widest variety of applications.
All outputs are actually tristate drivers. This allows a product to
support an in-circuit-test fixture. The conditions in which each
output is driven to the output state is distributed throughout the
ASIC.
448
All outputs use slew limited pads. This offers several advantages in
radiated noise reduction simultaneous switching outputs noise
reduction, less ASIC power and ground pads, etc. As none of the
outputs required very fast rise and fall times, no disadvantage exists.
Listed below is the pin definition for the 100 TQFP CNA10 ASIC by
categories.
TQFP Pin Definitions

TQFP Power
Pin Names(s)
Pin No.
Max Drive Rating
Description
Vdd
8, 19, 39
63
84
power
Pin Type
n/a
n/a
+5 volt supply: 5 Vdd pins total.
Vss
6 15, 42,
53,64
86
ground
n/a
n/a
Ground: 6 Vss pins total.
Max Output Load
TQFP Clock and Reset Functions

Pin Names(s)
Pin No.
Pin Type
/Xtal_In
11
Input
Max Output Load

n/a
Max Drive Rating

n/a
449
Description
60 Mhz crystal circuit input connection.
This input can also be used for a 60 Mhz clock input
from an external source. This input pad is a CMOS
characterized pad.
Xtal_Out
10
Output
n/a
n/a
60 Mhz crystal circuit output connection.

This output should be unconnected when the /Xtal_In
input is being driven by an external source.
/TME
Input
n/a
n/a
Clock multiplexer source signal. When this input is

active, the clock source for the ASIC becomes the
/TestClk input pin.
This input pin is used for board testing when the
tester is required to clock the CNA10 at a frequency
other than the 60 Mhz generated by the oscillator
circuit at the /Xtal_In input.
For normal operation, this input should tied high
through a resistor
/TestClk
Input
n/a
n/a
Clock from tester, used in place of /Xtal_In when the

/TME pin is activated.
For normal operation, this input should tied high or
low through a resistor
Clock_Out
13
Output
50 pF
4 mA
An output clock (10 MHz) which is used for

synchronous transmit media. This clock is enabled
and disabled through the Host Interface
Configuration Object. Clock_Out is disabled at
powerup and by a reset.
This clock is an INVERTED version of the TxClock
provided on the SMAC ASIC.
/Sys_Reset
Input
n/a
n/a
The CNA10 system reset input. The CNA10 ASIC will

process the input through a schmitt input and a digital
glitch filter.
/Reset_Out
82
Output
50 pF
24 mA
Buffered reset output. This signal is activated by

either the /Sys_Reset input or by a remote reset
packet (if enabled).
/Reset_Out is deactivated after the CNA10
calculates the internal ROM LFSR signatures. This
deactivation is approximately 1.7 milliseconds after
the deactivation of the /Sys_Reset input.
4410
TQFP LEDS
Pin Names(s)
Led_A_Red
Pin No.
80
Pin Type
Output
Max Output Load

50 pF
Max Drive Rating

8 mA
Description
The red connection to the channel A bicolor LED.
Led_A_Green
79
Output
50 pF
8 mA
The green connection to the channel A bicolor

LED.
Led_B_Red
77
Output
50 pF
8 mA
The red connection to the channel B bicolor LED.
Led_B_Green
76
Output
50 pF
8 mA
The green connection to the channel B bicolor

LED.
TQFP Host Interface

Pin Names(s)
Addr[11:0]
OR
Addr[11:1], /LBE
Pin No.
16
17
18
20
21
22
24
25
26
27
28
30
Pin Type
Input
Max Output Load

n/a
Max Drive Rating
Description
n/a
If configured for BYTE access mode, these inputs

function as Address pins [11:0]. These inputs are
used to select the dual port addressed RAM
location for memory reads and writes.
Addr[11:1] will remain functionally equivalent
regardless of addressing mode.
If configured for WORD access mode, Addr[0] is
redefined as a Low Byte Enable (/LBE) for
memory reads and writes to Data[7:0]. If
/RD_/DS is tied low, this signal will act as a lower
data strobe.
If configured for REPEATER operation, these pins
become unused and should be tied high or low
through a resistor.
4411
TQFP Host Interface (cont.)

Pin Names(s)
Data[7:0]
Pin No.
57
58
60
61
66
68
69
71
Pin Type
I/O
Max Output Load

150 pF
Max Drive Rating
Description
8 mA
This is the eight bit data bus to the internal Dual

Port RAM.
If configured for WORD access mode, these pins
function as the Dual Port RAMs lower data byte.
If configured for REPEATER operation, these pins
become unused and should be tied high or low
through a resistor.
NOTE: These are CMOS characterized pads.
MacID[7:0]
OR
Data[15:8]
/Irq0
33
34
36
37
43
44
46
47
I/O
74
Output
n/a
n/a
If configured for BYTE access mode, these pins

can be used to set the Network Address (or
MacID).
If configured for WORD access mode, these pins
function as the Dual Port RAMs high data byte
(Data[15:8]).
If these pins are not used for the Network
Address in BYTE access mode or if configured for
REPEATER operation, these pins should be tied
high using a pullup resistor
50 pF
4 mA
/Irq0 is the interrupt request of the Comm

Processor to the Host, via the Dual Port RAM. It is
cleared by a Host read to Dual Port RAM byte 2.
If configured for REPEATER operation, this pin is
not used and should be left unconnected.
/Irq1
72
Output
50 pF
4 mA
Not used. Reserved for future use.
/HBE
31
Input
n/a
n/a
If configured in a WORD access mode, this signal

functions as High Byte Enable for memory reads
and writes to Data[15:8]. If /RD_/DS is tied low,
this signal will act as an upper data strobe
If configured in a BYTE access mode, this signal
must be permanently tied low through a resistor
and should never be allowed to transition to a
high state.
If configured for REPEATER operation, this pin is
not used and should be tied high through a
resistor.
4412

Pin Names(s)
Pin No.
/WR_R/W
49
Pin Type
Input
Max Output Load

n/a
Max Drive Rating
Description
n/a
This pin can function as a Intel /WR write strobe or a

Motorola R/W data bus direction.
Some Intel processors may use an inverted DT/R
signal as a R/W (where the inserter must be supplied
external to the CNA10). However, if R/W is ever low
at the start of a bus cycle, it must not transition high
after the leading edge of ALE/AS low and /CE low, or
a false write to Dual Port RAM may occur.
If configured for REPEATER operation, this pin is not
used and should be tied high through a resistor.
/RD_/DS
50
Input
n/a
n/a
This pin can function as a Intel /RD read strobe or a

Motorola /DS data strobe.
/CE
51
Input
OR
n/a
n/a
An active low chip enable that will cause a bus cycle

to be generated. Note, that a Ready or /Dtack will
occur for every chip select (in the 4 kbyte
addressable range of Addr[11:0]), even if the
address is invalid.
This signal will be latched by the falling edge of
ALE/AS.
/CS
OR
In processor designs where chip select is guaranteed

glitch free, transitions will occur between back to
back cycles and addresses are not latched, then the
chip select should be tied to this pin and the ALE/AS
pin tied low.
This input is tied low if /CS is tied to the ALE/AS pin.
(tied low)

4413

Pin Names(s)
Pin No.
ALE/AS
52
Pin Type
Input
Max Output Load

n/a
Max Drive Rating
Description
n/a
This pin can function as an address latch enable

(ALE) or address strobe (/AS). This address select
signal is used to control bus cycles. This signal is
high while address, /CE, or R/W, is changing. Its
falling edge latches the address and /CE lines to start
the cycle. Its rising edge will terminate the bus cycle.
This input is a Schmitt triggered input.
OR
In processor designs, where chip select is

guaranteed glitch free, transitions will occur between
back to back cycles, and addresses must be latched
relative to the falling edge, then the chip select
should be tied to this pin and the /CE pin tied low.
/CS
OR
Tying this input low will disable the address select

latching function. This input is tied low when /CS is
tied to /CE.
(tied low)
L This function will run time configure following

reset. Reset initially disables the latching function. If
ALE/AS ever transitions high after reset, the latching
function will be enabled.
Ready
55
Output
50 pF
8 mA
Ready is a Normally Ready signal to control wait

states. This signal drops low at the start of the cycle
and returns high to conclude wait state generation.
Typically used for 80186, 80188, 80196, 80198, and
ISA backplanes.
The Ready output is driven whenever both ALE/AS
and /CE are low. It is tristate if ALE/AS is high. If
ALE/AS is low and /CE is high, the output condition
depends on the internal latched state of /CE. For
maximum speed, this signal is driven in the high and
low states during transitions.
used and should be left unconnected.
4414

Pin Names(s)
Pin No.
/Dtack
54
Pin Type
Output
Max Output Load

50 pF
Max Drive Rating
Description
8 mA
/Dtack is a Normally Not Ready signal to control

wait states. Drops low to conclude wait state
generation and returns high at the end of the cycle.
Typically used for Intel 80286 and above and all
Motorola 68xxx processors. Use of /Dtack is
optional.
The /Dtack output is driven whenever both ALE/AS
and /CE are low. It is tristate if ALE/AS is high. If
ALE/AS is low and /CE is high, the output condition
depends on the internal latched state of /CE. For
maximum speed, this signal is driven in the high and
low states during transitions.
used and should be left unconnected.
TQFP Miscellaneous Functions

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Tone
75
Output
50 pF
4 mA
Output pin providing a 100 ns pulse at every tone

(the start of each NUT).
Monitor
85
Output
50 pF
4 mA
This pin was used for debugging the ASIC during

development and is not available for the general
public. It should be left unconnected.
4415
TQFP Network Interface

Pin Names(s)
TxDataOut
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
95
I/O
50 pF
4 mA
If configured for SINGLE CHANNEL or

REDUNDANT media operations, this pin is the
active high transmit data (+) (TxDataOut)
output. It is the positive polarity signal for
differential drivers. For redundant media
operations, this output is used for both Channel
A and B transmit data.
OR
If configured for REPEATER operation, this pin

is the Channel A active high transmit data
output (TxDataOut_A). Data received on
Channel B (RxData_B) is repeated out on
channel A (TxDataBar_A).
TxDataOut_A
L This pin is used for autoconfigure at reset.

This output requires a pull down resistor to
ground.
TxDataBar
93
I/O
50 pF
4 mA
OR

active low transmit data () (TxDataBar) output.
It is the negative polarity signal for differential
drivers. For REDUNDANT media operations,
this output is used for both Channel A and B
transmit data.
is the Channel A active low transmit data output
(TxDataBar_A). Data received on Channel B
(RxData_B) is repeated out on channel A
(TxDataBar_A).
TxDataBar_A
OR
For all modes of media operation (SINGLE

CHANNEL, REDUNDANT and REPEATER),
this pin can be configured as a transmit enable
(/TxEnable_A) rather than an active low
transmit data. This type of configuration is
typically used for fiber optics modems. To
configure this output to become a transmit
enable signal, this pin must be tied high with a
pull up resistor.
/TxEnable_A
L The function will autoconfigure at reset.

For coax media, the TxDataBar output is
configured by a pull down resistor to ground.
Fiber optic media output (/TxEnable_A) is
configured by a pull up resistor to +5v.
4416
TQFP Network Interface (cont.)

Pin Names(s)
/TxPTC
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
92
I/O
50 pF
4 mA

active low transmit data output (/TxPTC) for the
NAP connection.
OR

is the Channel B active high transmit data
output (TxDataOut_B). Data received on
Channel A (RxData_A) is repeated out on
channel B (TxDataOut_B).
TxDataOut_B

This pin at reset, determines if the CNA10 will
be configured for REDUNDANT media or
REPEATER operation. REDUNDANCY is
configured by using a pull up resistor to Vdd
(+5v). REPEATER mode is configured by using
a pull down resistor to Vss (gnd).
/RxPTC
91
I/O
OR
TxDataBar_B
OR
/TxEnable_B
50 pF
4 mA

active low receive data input (/RxPTC) for the
NAP connection.
is the Channel B active low transmit data output
(TxDataBar_B). Data received on Channel A
(RxData_A) is repeated out on channel B
(TxDataBar_B).
For REPEATER operations, this pin can be
configured as a channel B transmit enable
(/TxEnable_B) rather than an active low
typically used for fiber optics modems.
L The function will autoconfigure at reset. If
configured for SINGLE CHANNEL or
REDUNDANT media operations, this pin will
become the /RxPTC input and no resistor is
required. If configured for SINGLE CHANNEL
or REDUNDANT media operations and the
NAP port is not used, then the user must tie this
input to Vdd (+5v) through a resistor. If
configured for REPEATER operation and a
coax media interface (TxDataBar_B) is
required, then this pin should be configured with
a pull down resistor to Vss (gnd). If configured
for REPEATER operation and a fiber optic
media interface (/TxEnable_B) is required, then
this pin should be configured with a pull up
resistor to Vdd (+5v).
4417
TQFP Network Interface (cont.)

Pin Names(s)
RxData_A
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
100
Input
n/a
n/a
Receive data input for channel A.

If unused, as in a NAP only or in a single
channel application, this input should be pulled
to Vss (gnd) with resistor.
RxCarrier_A
99
Input
n/a
n/a
Receive carrier detect signal for channel A.

RxData_B
97
Input
n/a
n/a
Receive data input for channel B.

RxCarrier_B
96
Input
n/a
n/a
Receive carrier detect signal for channel B.

NetEnb_A
88
Output
50 pF
4 mA
This pin is the active high channel A network

transmit enable. For SINGLE CHANNEL and
REDUNDANT coax media operations, this pin
should be logically anded with G_NetEnb and
connected directly to the respective channel
transmit enable (TxEN) of ControlNet coax
hybrid. For SINGLE CHANNEL and
REDUNDANT fiber media operations, this pin
should be logically gated with the transmit data
(TxDataOut), enable (/TxEnable_A), and global
enable (G_NetEnb). For REPEATER operation,
this pin should be left unconnected.
NetEnb_B
87
Output
50 pF
4 mA
This pin is the active high channel B network

(TxDataOut), enable (/TxEnable_B), and global
enable (G_NetEnb). For REPEATER operation,
this pin should be left unconnected.
G_NetEnb
81
Output
50 pF
8 mA
This pin is the active high global network

REDUNDANT coax media operations this pin
should be logically gated (and gate) with
NetEnb_A and tied to TxEn_A of the ControlNet
coax hybrid. It should also be logically gated
(and gate) with NetEnb_B and tied to TxEn_B
of the ControlNet coax hybrid.
For SINGLE CHANNEL and REDUNDANT fiber
media operations, the TxDataOut for the
respective channel must be logically gated also.
For REPEATER operation, this pin should be
left unconnected.
4418
TQFP ROM Interface

Pin Names(s)
ROM_Bypass
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Input
n/a
n/a
This input pin controls whether the ASIC

executes Comm processor firmware externally
or internally. A logic high state on this pin will
select external firmware execution. A logic low
state on this pin will select internal firmware
execution. Currently, executing internal
operational firmware is not supported and is
being reserved for future use. Internal code
does exist to execute power up self test. For
normal operation (nonREPEATER) mode, this
input should be permanently tied high through a
resistor.
In REPEATER mode, the operation of the
COMM processor is not required. In
REPEATER mode, this input can be
permanently tied low through a resistor. Upon
power up in this mode, the Comm processor
will execute internal self test and will then halt
execution. The CNA10 ASIC can execute code
externally in REPEATER mode, but operational
COMM code CAN NOT be used for repeater
operations. Therefore, if the user wants to
execute COMM code externally in REPEATER
mode, they must have special code.
Once /Sys_Reset is deactivated, this input
should never be allowed to transition or glitch.
ROM_Addr[15:0]
ROM_Data[7:0]
23
29
32
35
38
41
45
48
56
59
62
65
67
70
73
78
90
94
98
3
7
9
12
14
Output
50 pF
4 mA
ROM address pins for the Comm Processor

when it is executing external firmware
(ROM_Bypass is pulled high).
These address pins are floated whenever
Comm Processor code is being executed
internally (ROM_Bypass is pulled low).
If configured for REPEATER operation or if
executing COMM processor firmware internally
(ROM_Bypass is pulled low), these pins are
Input
n/a
n/a
If ROM_Bypass is high, the ROM_Data pins

will input external Comm Processor ROM data.
If the external ROM feature is not used, these
inputs should be tied high.
not used and should be tied high using a pullup
resistor
4419
MQFP Pin Definitions

MQFP Power
Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Vdd
16 39 59
71
94
power
n/a
n/a
+5 volt supply: 5 Vdd pins total.
Vss
14 26 37
64 73
92
ground
n/a
n/a
Ground: 6 Vss pins total.
MQFP Clock and Reset Functions

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
/Xtal_In
68
Input
n/a
n/a
60 Mhz crystal circuit input connection.

This input can also be used for a 60 Mhz clock
input from an external source. This input pad is
a CMOS characterized pad.
Xtal_Out
69
Output
n/a
n/a
60 Mhz crystal circuit output connection.

This output should be unconnected when the
/Xtal_In input is being driven by an external
source.
/TME
77
Input
n/a
n/a
Clock multiplexer source signal. When this input

is active, the clock source for the ASIC
becomes the /TestClk input pin.
This input pin is used for board testing when the
tester is required to clock the CNA 10 at a
frequency other than the 60 Mhz generated by
the oscillator circuit at the /Xtal_In input.
through a resistor
/TestClk
75
Input
n/a
n/a
Clock from tester, used in place of /Xtal_In

when the /TME pin is activated.
or low through a resistor
Clock_Out
66
Output
50 pF
4 mA
An output clock (10 MHz) which is used for

synchronous transmit media. This clock is
enabled and disabled through the Host
Interface Configuration Object. Clock_Out is
disabled at powerup and by a reset.
This clock is an INVERTED version of the
TxClock provided on the SMAC ASIC.
/Sys_Reset
78
Input
n/a
n/a
The CNA 10 system reset input. The CNA 10

ASIC will process the input through a schmitt
input and a digital glitch filter.
/Reset_Out
96
Output
50 pF
24 mA
Buffered reset output. This signal is activated

by either the /Sys_Reset input or by a remote
reset packet (if enabled).
/Reset_Out is deactivated after the CNA 10
calculates the internal ROM LFSR signatures.
This deactivation is approximately 1.7
milliseconds after the deactivation of the
/Sys_Reset input.
4420
MQFP LEDS
Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Led_A_Red
98
Output
50 pF
8 mA
The red connection to the channel A bicolor

LED.
Led_A_Green
99
Output
50 pF
8 mA
The green connection to the channel A bicolor

LED.
Led_B_Red
Output
50 pF
8 mA
The red connection to the channel B bicolor

LED.
Led_B_Green
Output
50 pF
8 mA
The green connection to the channel B bicolor

LED.
4421
MQFP Host Interface

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Addr[11:0]
63
62
60
58
57
56
54
53
52
51
50
48
Input
n/a
n/a
If configured for BYTE access mode, these

inputs function as Address pins [11:0]. These
inputs are used to select the dual port
addressed RAM location for memory reads and
writes. Addr[11:1] will remain functionally
equivalent regardless of addressing mode.
OR
Addr[11:1], /LBE
If configured for WORD access mode, Addr[0]

is redefined as a Low Byte Enable (/LBE) for
/RD_/DS is tied low, this signal will act as a
lower data strobe.
If configured for REPEATER operation, these
pins become unused and should be tied high or
low through a resistor.
Data[7:0]
22
21
19
18
12
10
9,
7
I/O
150 pF
8 mA
This is the eight bit data bus to the internal Dual

Port RAM.
If configured for WORD access mode, these
pins function as the Dual Port RAMs lower data
byte.
If configured for REPEATER operation, these
pins become unused and should be tied high or
low through a resistor.
NOTE: These are CMOS characterized pads.
MacID[7:0]
OR
Data[15:8]
/Irq0
45
44
42
41
36
35
33
32
I/O
Output
n/a
n/a
If configured for BYTE access mode, these pins

can be used to set the Network Address (or
MacID).
If configured for WORD access mode, these
pins function as the Dual Port RAMs high data
byte (Data[15:8]).
If these pins are not used for the Network
Address in BYTE access mode or if configured
for REPEATER operation, these pins should be
tied high using a pullup resistor
50 pF
4 mA
/Irq0 is the interrupt request of the Comm

Processor to the Host, via the Dual Port RAM. It
is cleared by a Host read to Dual Port RAM
byte 2.
is not used and should be left unconnected.
/Irq1
Output
50 pF
4 mA
Not used. Reserved for future use.
/HBE
47
Input
n/a
n/a
If configured in a WORD access mode, this

signal functions as High Byte Enable for
/RD_/DS is tied low, this signal will act as an
upper data strobe
If configured in a BYTE access mode, this
signal must be permanently tied low through a
resistor and should never be allowed to
transition to a high state.
is not used and should be tied high through a
resistor.
4422
MQFP Host Interface (cont.)

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
/WR_R/W
30
Input
n/a
n/a
This pin can function as a Intel /WR write strobe

or a Motorola R/W data bus direction.
Some Intel processors may use an inverted
DT/R signal as a R/W (where the inserter must
be supplied external to the CNA 10). However,
if R/W is ever low at the start of a bus cycle, it
must not transition high after the leading edge
of ALE/AS low and /CE low, or a false write to
Dual Port RAM may occur.
resistor.
/RD_/DS
29
Input
n/a
n/a
This pin can function as a Intel /RD read strobe

or a Motorola /DS data strobe.
resistor.
/CE
28
Input
OR
n/a
n/a
An active low chip enable that will cause a bus

cycle to be generated. Note, that a Ready or
/Dtack will occur for every chip select (in the 4
kbyte addressable range of Addr[11:0]), even if
the address is invalid.
This signal will be latched by the falling edge of
ALE/AS.
OR
In processor designs where chip select is

guaranteed glitch free, transitions will occur
between back to back cycles and addresses
are not latched, then the chip select should be
tied to this pin and the ALE/AS pin tied low.
(tied low)
This input is tied low if /CS is tied to the

ALE/AS pin.
/CS

resistor.
4423
MQFP Host Interface (cont.)

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
ALE/AS
Input
n/a
n/a
This pin can function as an address latch

enable (ALE) or address strobe (/AS). This
address select signal is used to control bus
cycles. This signal is high while address, /CE,
or R/W, is changing. Its falling edge latches the
address and /CE lines to start the cycle. Its
rising edge will terminate the bus cycle. This
input is a Schmitt triggered input.
27
OR
In processor designs, where chip select is

guaranteed glitch free, transitions will occur
between back to back cycles, and addresses
must be latched relative to the falling edge, then
the chip select should be tied to this pin and the
/CE pin tied low.
/CS
OR
Tying this input low will disable the address

select latching function. This input is tied low
when /CS is tied to /CE.
L This function will run time configure
following reset. Reset initially disables the
latching function. If ALE/AS ever transitions
high after reset, the latching function will be
enabled.
(tied low)

resistor.
Ready
24
Output
50 pF
8 mA
Ready is a Normally Ready signal to control

wait states. This signal drops low at the start of
the cycle and returns high to conclude wait
state generation. Typically used for 80186,
80188, 80196, 80198, and ISA backplanes.
The Ready output is driven whenever both
ALE/AS and /CE are low. It is tristate if
ALE/AS is high. If ALE/AS is low and /CE is
high, the output condition depends on the
internal latched state of /CE. For maximum
speed, this signal is driven in the high and low
states during transitions.
/Dtack
25
Output
50 pF
8 mA
/Dtack is a Normally Not Ready signal to

control wait states. Drops low to conclude wait
state generation and returns high at the end of
the cycle. Typically used for Intel 80286 and
above and all Motorola 68xxx processors. Use
of /Dtack is optional.
The /Dtack output is driven whenever both
ALE/AS and /CE are low. It is tristate if
ALE/AS is high. If ALE/AS is low and /CE is
high, the output condition depends on the
internal latched state of /CE. For maximum
speed, this signal is driven in the high and low
states during transitions.
4424
MQFP Miscellaneous Functions

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
Tone
Output
50 pF
4 mA
Output pin providing a 100 ns pulse at every

tone (the start of each NUT).
Monitor
93
Output
50 pF
4 mA
This pin was used for debugging the ASIC

during development and is not available for the
general public. It should be left unconnected.
MS/Mio
15
Input
n/a
n/a
This is an ASIC configuration pin that must be

permanently tied high through a resistor and
should never be allowed to transition to a low
state.
Diag_Int
61
Input
n/a
n/a
This input is a NMI interrupt to the Comm

processor which is used for firmware
development purposes only. The user should
permanently tied this input high through a
resistor.
4425
MQFP Network Interface

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
TxDataOut
84
I/O
50 pF
4 mA

active high transmit data (+) (TxDataOut)
output. It is the positive polarity signal for
differential drivers. For redundant media
operations, this output is used for both Channel
A and B transmit data.
OR

is the Channel A active high transmit data
output (TxDataOut_A). Data received on
Channel B (RxData_B) is repeated out on
channel A (TxDataBar_A).
TxDataOut_A
L This pin is used for autoconfigure at reset.

This output requires a pull down resistor to
ground.
TxDataBar
86
I/O
50 pF
4 mA
OR

active low transmit data () (TxDataBar) output.
It is the negative polarity signal for differential
drivers. For REDUNDANT media operations,
this output is used for both Channel A and B
transmit data.
is the Channel A active low transmit data output
(TxDataBar_A). Data received on Channel B
(RxData_B) is repeated out on channel A
(TxDataBar_A).
TxDataBar_A
OR
For all modes of media operation (SINGLE

CHANNEL, REDUNDANT and REPEATER),
this pin can be configured as a transmit enable
(/TxEnable_A) rather than an active low
typically used for fiber optics modems. To
configure this output to become a transmit
enable signal, this pin must be tied high with a
pull up resistor.
/TxEnable_A

For coax media, the TxDataBar output is
configured by a pull down resistor to ground.
Fiber optic media output (/TxEnable_A) is
configured by a pull up resistor to +5v.
4426
MQFP Network Interface (cont.)

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
/TxPTC
87
I/O
50 pF
4 mA

active low transmit data output (/TxPTC) for the
NAP connection.
OR

is the Channel B active high transmit data
output (TxDataOut_B). Data received on
Channel A (RxData_A) is repeated out on
channel B (TxDataOut_B).
TxDataOut_B

This pin at reset, determines if the CNA 10 will
be configured for REDUNDANT media or
REPEATER operation. REDUNDANCY is
configured by using a pull up resistor to Vdd
(+5v). REPEATER mode is configured by using
a pull down resistor to Vss (gnd).
/RxPTC
88
I/O
50 pF
4 mA
OR

active low receive data input (/RxPTC) for the
NAP connection.
is the Channel B active low transmit data output
(TxDataBar_B). Data received on Channel A
(RxData_A) is repeated out on channel B
(TxDataBar_B).
TxDataBar_B
OR
For REPEATER operations, this pin can be

configured as a channel B transmit enable
(/TxEnable_B) rather than an active low
typically used for fiber optics modems.
/TxEnable_B
L The function will autoconfigure at reset. If

configured for SINGLE CHANNEL or
REDUNDANT media operations, this pin will
become the /RxPTC input and no resistor is
required. If configured for SINGLE CHANNEL
or REDUNDANT media operations and the
NAP port is not used, then the user must tie this
input to Vdd (+5v) through a resistor. If
configured for REPEATER operation and a
coax media interface (TxDataBar_B) is
required, then this pin should be configured with
a pull down resistor to Vss (gnd). If configured
for REPEATER operation and a fiber optic
media interface (/TxEnable_B) is required, then
this pin should be configured with a pull up
resistor to Vdd (+5v).
RxData_A
79
Input
n/a
n/a
Receive data input for channel A.

RxCarrier_A
80
Input
n/a
n/a
Receive carrier detect signal for channel A.

MQFP Network Interface (cont.)

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
RxData_B
n/a
n/a
Receive data input for channel B.
82
Input
4427

RxCarrier_B
83
Input
n/a
n/a
Receive carrier detect signal for channel B.

NetEnb_A
90
Output
50 pF
4 mA
This pin is the active high channel A network

(TxDataOut), enable (/TxEnable_A), and
global enable (G_NetEnb). For REPEATER
operation, this pin should be left unconnected.
NetEnb_B
91
Output
50 pF
4 mA
This pin is the active high channel B network

(TxDataOut), enable (/TxEnable_B), and
global enable (G_NetEnb). For REPEATER
operation, this pin should be left unconnected.
G_NetEnb
97
Output
50 pF
8 mA
This pin is the active high global network

REDUNDANT coax media operations this pin
should be logically gated (and gate) with
NetEnb_A and tied to TxEn_A of the ControlNet
coax hybrid. It should also be logically gated
(and gate) with NetEnb_B and tied to TxEn_B
of the ControlNet coax hybrid.
For SINGLE CHANNEL and REDUNDANT fiber
media operations, the TxDataOut for the
respective channel must be logically gated also.
For REPEATER operation, this pin should be
left unconnected.
4428
MQFP ROM Interface

Pin Names(s)
Pin No.
Pin Type
Max Output Load
Max Drive Rating
Description
ROM_Bypass
74
Input
n/a
n/a
This input pin controls whether the ASIC

executes Comm processor firmware externally
or internally. A logic high state on this pin will
select external firmware execution. A logic low
state on this pin will select internal firmware
execution. Currently, executing internal
operational firmware is not supported and is
being reserved for future use. Internal code
does exist to execute power up self test. For
normal operation (nonREPEATER) mode, this
input should be permanently tied high through a
resistor.
In REPEATER mode, the operation of the
COMM processor is not required. In
REPEATER mode, this input can be
permanently tied low through a resistor. Upon
power up in this mode, the Comm processor
will execute internal self test and will then halt
execution. The CNA 10 ASIC can execute code
externally in REPEATER mode, but operational
COMM code CAN NOT be used for repeater
operations. Therefore, if the user wants to
execute COMM code externally in REPEATER
mode, they must have special code.
Once /Sys_Reset is deactivated, this input
should never be allowed to transition or glitch.
ROM_Addr[15:0]
ROM_Data[7:0]
55
49
46
43
40
38
34
31
23
20
17
13
11
8
5
100
89
85
81
76
72
70
67
65
Output
50 pF
4 mA
ROM address pins for the Comm Processor

when it is executing external firmware
(ROM_Bypass is pulled high).
These address pins are floated whenever
Comm Processor code is being executed
internally (ROM_Bypass is pulled low).
Input
n/a
n/a
If ROM_Bypass is high, the ROM_Data pins

will input external Comm Processor ROM data.
If the external ROM feature is not used, these
inputs should be tied high.
not used and should be tied high using a pullup
resistor
4429
Auto-configured and Run-time Configured Pins

The CNA10 ASIC has the capability of being configured into several
modes during and after reset by use of auto and run time configured
pins. This gives the user the ability to configure the CNA10 for the
required application by using pullup or pulldown resistors on the
configure pins. Auto configured pins are pins that are configured
based on the logic level that is sensed by the ASIC at the release of
the /Sys_Reset pin. After an auto configure pin is configured, it will
stay in that state until the next assertion of /Sys_Reset A run time
configured pin is also configured based on the logic level sensed by
the ASIC at the release of /Sys_Reset, but can be changed by the
first transition to the opposite polarity anytime after reset. Once the
run time configured pin has changed state, it cant be changed back
until the next reset. The designer must design the config pins so that
they reach their proper voltage levels within 400 nsec after the
deactivation of /Sys_Reset to guarantee the correct application state.
There are six config pins, four are auto configured and two are run
time configured. The four auto configured are the network pins
TxDataOut, TxDataBar, /TxPTC, and /RxPTC. These auto
configured pins configure the CNA10 transmit pins for either coax or
fiber applications. The pins can also put the CNA10 ASIC into
repeater mode and provide the capability of floating output pins for
test. The run time configured pins are two host pins, ALE/AS and
/HBE. These two pins are either disabled or actively used. If
disabled, the pin must be permanently tied low.
If the CNA10 is used for the NAP connection only, as for a
programming device, you still need a pullup or pulldown resistor on
TxDataOut and TxDataBar.
4430
Description and Use of the Auto-configured Pins

Listed below is a description of each auto-configured pin and how it
is to be used on the CNA10 ASIC.
TxDataOut This pin is used for test purposes only and
should always be pulled low. When this input is pulled high, the
contents of the MacID[7:0] bus are stored inside the ASIC. This
stored value, depending on the value, can put the CNA10 into a
configuration that can damage the ASIC or other components.
There is one test configuration that may be beneficial to
manufacturing test and that is the global tristate output mode. By
placing a value of 0x80 on the MacID bus while pulling
Tx_DataOut high during reset, the CNA10 will float all output
pins except Xtal_Out, Ready and /Dtack. Ready and /Dtack are
actually tristated by deactivating the ALE/AS or /CE inputs.
This gives manufacturing test the capability of isolating the ASIC
while testing surrounding components that interface to the
CNA10. If a user chooses to use the global tristate output mode,
he/she must only use the value 0x80.
TxDataBar Normally pulled low for a coax transceiver. If
pulled high, this pin will actually output /TxEnable for fiber
operations.
/TxPTC Always pulled high for single or redundant channel
media with NAP connections. If this input is pulled low, the
CNA10 will be configured for repeater operation.
/RxPTC For single or redundant channel media with NAP
connections (/TxPTC pulled high), this pin becomes the /RxPTC
input and no pullup or pulldown is required for configuration. If
the repeater configuration was chosen (/TxPTC pulled low), then
this pin is used to select either coax (pulled low) or fiber (pulled
high) mode.
Description and Use of the Run-time Configured Pins
ALE/AS The input pin is disabled if it is tied low. In this

disabled mode, the CNA10 internal hardware will bypass its
Addr[11:0] and /CE demultiplexing latches and thereby
becoming transparent. If this input ever transitions to a high state,
then the CNA10 will interpret the input as being used and will
enable the internal Addr[11:0] and /CE latches. From then on
and until the next reset, the address demultiplexers are transparent
when ALE/AS is high and latched when ALE/AS is low.
/HBE This pin must be permanently tied low if the CNA10 is
to function as an 8Bit (BYTE) wide interface to the DualPort
RAM. If a 16Bit (WORD) wide interface is desired, then this
pin will function as a High Byte Enable.
4431
NOTE: If /HBE ever transitions high after reset, the Dual Port RAM
will switch to WORD access mode permanently until the next reset
is asserted. This will cause the Host interface not to become operable
with a Byte wide interface.
Tristated Pins
Listed in the table below, are the CNA10 pins that can float.
Pin Names(s)
Description
/Reset_Out
Normally always active. May only be tristated via the global

tristate autoconfig.
/Irq0
/Irq1
Tone
Clock_Out
NetEnb_A
NetEnb_B
Monitor
Led_A_Red
Led_A_Green
Tristated during internal reset. Normally active after reset. Will

also be permanently tristated via the global tristate.
Led_B_Red
Led_B_Green
G_NetEnb
/RxPTC
Tristated during internal or external reset. If /TxPTC was pulled

high at autoconfig time, this signal will remain tristated. If /TxPTC
was pulled low at autoconfig time, this signal will go active after
reset. Will also be permanently tristated via the global tristate
autoconfig.
TxDataOut
These three outputs are tristated during internal or external reset.

Normally active after reset. Will also be permanently tristated via
the global tristate autoconfig.
TxDataBar
/TxPTC
Ready
/Dtack
These outputs are driven whenever both ALE/AS low and /CE low.
They are tristated if ALE/AS is high. If ALE/AS is low and /CE is
high, condition depends on internal latched state of /CE. Both
driven high and driven low transitions exists, for maximum speed.
Data[7:0]
Normally always tristated. Will be driven by Dual Port RAM read

accesses and if the global tristate autoconfig was not made.
ROM_Addr[15:0]
Tristated if ROM_Bypass input is low. Driven if ROM_Bypass

input is high.
4432
Network Configurations
In this section, several network configurations using the CNA10

ASIC will be outlined. Not all permutations will be listed, but
enough to provide an essential understanding of how the CNA10
ASIC can be used in several applications.
NAP Only
In this mode, the CNA10 must be configured for Redundancy
operation. REDUNDANT mode is configured by using a pull up
resistor to Vdd (+5v) on the /TxPTC pin. Once in the
REDUNDANT mode, only the NAP connections (/TxPTC and
/RxPTC) are used. The unused Network inputs (RxData_A,
RxCarrier_A, RxData_B and RxCarrier_B) must be tied to Vss
(gnd) using a resistor so that the carrier detection is never triggered.
Since the redundancy transmit pins (TxDataOut and TxDataBar)
are not used, the autoconfig for the TxDataBar can be tied high or
low. It is the responsibility of the programming device on a
NAPtoNAP connection to provide isolation.
Figure 44.5
NAP Only Configuration
Host Processor
CNA10 ASIC
Address,
Data, and
Control
Signals
TxDataOut
TxDataBar
NetEnb_A
RxData_A
RxCarrier_A
NetEnb_B
RxData_B
RxCarrier_B
/TxPTC
/RxPTC
NAP
Transceiver
NAP CABLE
CNA10 Pin
Autoconfig Setting
Connection
TxDataOut
Requires pull down resistor.
None
TxDataBar
Requires either pull down or pull

up resistor.
None
/TxPTC
Requires pull up resistor for

Redundancy mode
Connect to NAP driver.
/RxPTC
None required
Connect to NAP receiver.
4433
RxData_A
None required
Set to an inactive state by using a

pull down resistor.
RxCarrier_A
None required

pull down resistor.
RxData_B
None required

pull down resistor.
RxCarrier_B
None required

pull down resistor.
NetEnb_A
None required
None
NetEnb_B
None required
None
Single Channel with No NAP in Coax Mode

For the SINGLE CHANNEL mode, the CNA10 must be configured
for Redundancy operation even though the redundant channel is not
used. REDUNDANT mode is configured by using a pull up resistor
to Vdd (+5v) on the /TxPTC pin. The unused Network inputs for
channel B (RxData_B and RxCarrier_B) must be tied to Vss (gnd)
using a resistor. The unused received data port for the NAP
connection must be set to an inactive state by using a pull up resistor
to Vdd (+5v). The channel A connections are connected to the
ControlNet single channel hybrid (cat. no. 9904-HYBS).
Figure 44.6
Single Channel with no NAP
Host Processor
Address,
Data, and
Control
Signals
CNA10 ASIC
TxDataOut
Coax Transceiver
TxDataBar
Network
Drop Cable
NetEnb_A
G_NetEnb
RxData_A
RxCarrier_A
NetEnb_B
9904-HYBS
RxData_B
RxCarrier_B
/TxPTC
/RxPTC
4434
CNA10 Pin
Autoconfig Setting
Connection
TxDataOut
Requires pull down resistor. If the

Connect to active high transmit
ControlNet hybrid is used, then no data input (Tx_A) of the ControlNet
resistor is required because the
hybrid.
pull down resistor is built internal to
the hybrid.
TxDataBar
Requires pull down resistor for

coax mode. If the ControlNet
hybrid is used, then no resistor is
required because the pull down
resistor is built internal to the
hybrid.
Connect to active low transmit data

input (TxBar_A) of the ControlNet
hybrid.
/TxPTC

Redundancy mode.
None
/RxPTC
None required

pull up resistor.
RxData_A
None required
Connect to received data output

pin (Rx_A) of the ControlNet
hybrid.
RxCarrier_A
None required
Connect to received carrier output

pin (CD_A) of the ControlNet
hybrid.
RxData_B
None required

pull down resistor.
RxCarrier_B
None required

pull down resistor.
NetEnb_A
None required
Gate with G_NetEnb and

connect to transmit enable pin
(TxEn_A) of the ControlNet hybrid.
NetEnb_B
None required
None
Single Channel with NAP in Coax Mode

For the SINGLE CHANNEL mode, the CNA10 must be configured
for Redundancy operation even though the redundant channel is not
used. REDUNDANT mode is configured by using a pull up resistor
to Vdd (+5v) on the /TxPTC pin. The unused Network inputs for
channel B (RxData_B and RxCarrier_B) must be tied to Vss (gnd)
using a resistor. The channel A connections are connected to the
ControlNet single channel hybrid.
4435
Figure 44.7
Single Channel with NAP
Host Processor
CNA10 ASIC TxDataOut
Coax Transceiver
TxDataBar
Address,
Data, and
Control
Signals
Drop Cable
Network
NetEnb_A
G_NetEnb
9904-HYBS
RxData_A
RxCarrier_A
NetEnb_B
RxData_B
RxCarrier_B
NAP Transceiver
NAP Cable
/TxPTC
/RxPTC
CNA10 Pin
Autoconfig Setting
Connection
TxDataOut

ControlNet hybrid is used, then no
resistor is required because the pull
down resistor is built internal to the
hybrid.
Connect to active high transmit data

input (Tx_A) of the ControlNet hybrid.
TxDataBar
Requires pull down resistor for coax

mode. If the ControlNet hybrid is used,
then no resistor is required because the
pull down resistor is built internal to the
hybrid.

input (TxBar_A) of the ControlNet
hybrid.
/TxPTC

Redundancy mode.
/RxPTC
None required
RxData_A
None required
Connect to received data output pin

(Rx_A) of the ControlNet hybrid.
RxCarrier_A
None required
Connect to received carrier output pin

(CD_A) of the ControlNet hybrid.
RxData_B
None required
Set to an inactive state by using a pull

down resistor.
RxCarrier_B
None required
Set to an inactive state by using a pull

down resistor.
NetEnb_A
None required
Gate with G_NetEnb and connect to

transmit enable pin (TxEn_A) of the
ControlNet hybrid.
NetEnb_B
None required
None
4436
Redundant with No NAP in Coax Mode

The REDUNDANT mode is configured by using a pull up resistor to
Vdd (+5v) on the /TxPTC pin. The unused received data port for the
NAP connection must be set to an inactive state by using a pull up
resistor to Vdd (+5v). The channel A and B connections are
connected to the ControlNet dual channel hybrid (cat. no.
9904-HYBD).
Figure 44.8
Redundant with no NAP
Host Processor
Address,
Data, and
Control
Signals
CNA10
TxDataOut
TxDataBar
Coax Transceiver
Drop Cable
Network
9904-HYBD
NetEnb_A
G_NetEnb
NetEnb_B
Drop Cable
RxData_A
RxCarrier_A
RxData_B
RxCarrier_B
/TxPTC
/RxPTC
Network
CNA10 Pin
Autoconfig Setting
4437
Connection
TxDataOut

ControlNet hybrid is used, then no data inputs (Tx_A and Tx_B) of the
ControlNet hybrid.
the hybrid.
TxDataBar

hybrid.

inputs (TxBar_A and TxBar_B) of
the ControlNet hybrid.
/TxPTC

Redundancy mode.
None
/RxPTC
None required

pull up resistor.
RxData_A
None required

hybrid.
RxCarrier_A
None required

hybrid.
RxData_B
None required

pin (Rx_B) of the ControlNet
hybrid.
RxCarrier_B
None required

pin (CD_B) of the ControlNet
hybrid.
NetEnb_A
None required
Gate with G_NetEnb and connect

to transmit enable pin (TxEn_A) of
NetEnb_B
None required

to transmit enable pin (TxEn_B) of
Redundant with NAP in Coax Mode

Vdd (+5v) on the /TxPTC pin. The channel A and B connections are
connected to the ControlNet dual channel hybrid.
4438
Figure 44.9
Redundant with NAP
Host Processor
Address,
Data, and
Control
Signals
CNA10 ASIC
Coax Transceiver
TxDataOut
TxDataBar
Drop Cable
Network
9904-HYBD
NetEnb_A
G_NetEnb
NetEnb_B
Drop Cable
Network
RxData_A
RxCarrier_A
RxData_B
RxCarrier_B
NAP Transceiver
/TxPTC
/RxPTC
NAP Cable
CNA10 Pin
Autoconfig Setting
4439
Connection
TxDataOut

ControlNet hybrid is used, then no data inputs (Tx_A and Tx_B) of the
ControlNet hybrid.
the hybrid.
TxDataBar

hybrid.

inputs (TxBar_A and TxBar_B) of
/TxPTC

Redundancy mode.
/RxPTC
None required
RxData_A
None required

hybrid.
RxCarrier_A
None required

hybrid.
RxData_B
None required

hybrid.
RxCarrier_B
None required

hybrid.
NetEnb_A
None required

to transmit enable pin (TxEn_A) of
NetEnb_B
None required

to transmit enable pin (TxEn_B) of
Redundant with NAP in Fiber Mode

Vdd (+5v) on the /TxPTC pin. The channel A and B connections are
connected to the fiber optic modem. The /TxEnable_A output should
be gated with the two network enable signals (NetEnb_A and
NetEnb_B) to generate the two transmit enable signals for channel A
and B.
4440
Figure 44.10
Redundant fiber with NAP
Host Processor
Address,
Data, and
Control
Signals
CNA10 ASIC
Fiber Transceiver
TxDataOut
Fiber Cable
Tx
/TxEnable
Fiber Cable
Rx
NetEnb_A
RxData_A
RxCarrier_A
Fiber Transceiver
Fiber Cable
Tx
G_NetEnb
NetEnb_B
Fiber Cable
Rx
RxData_B
RxCarrier_B
NAP Transceiver
/RxPTC
/RxPTC
NAP Cable
CNA10 Pin
Autoconfig Setting
4441
Connection
TxDataOut
Connect to transmit data input of the

fiber optic modem for both channel A
& B.
TxDataBar
Requires pull up resistor for fiber Gate this signal with NetEnb_A and
mode. This pin now becomes
NetEnb_B to generate transmit
/TxEnable_A.
enable signals for channel A and B
respectfully.
/TxPTC

Redundancy mode.
/RxPTC
None required
RxData_A
None required
Connect to the channel A received

data output of the fiber optic receiver.
RxCarrier_A
None required
Connect to the carrier detection logic

for channel A. If no carrier detection
logic is used, connect this input to
the channel A received data output of
the fiber optic receiver.
RxData_B
None required
Connect to the channel B received

data output of the fiber optic receiver.
RxCarrier_B
None required
Connect to the carrier detection logic

for channel B. If no carrier detection
logic is used, connect this input to
the channel B received data output of
the fiber optic receiver.
NetEnb_A
None required
Gate this output with the

/TxEnable_A and G_NetEnb signals
to generate transmit enable signal for
channel A.
NetEnb_B
None required
Gate this output with the

/TxEnable_A and G_NetEnb signals
to generate transmit enable signal for
channel B.
Repeater in Coax Mode

The REPEATER mode is configured by using a pull down resistor to
Vss (gnd) on the /TxPTC pin. The TxDataOut and TxDataBar pins
become dedicated output pins for channel A (TxDataOut_A and
TxDataBar_A). The pins that were used for the NAP connection
(/TxPTC and /RxPTC) now become dedicated transmit pins for
channel B. The transmit bar pins (TxDataBar and /RxPTC)
determine if the bar pins are configured for coax or fiber media.
Coax media is configured by using a pull down resistors to Vss (gnd)
and fiber media is configured by using pull up resistors to Vdd
(+5v). Note, the user can configure one channel for coax media and
the other for fiber media if so desired.
4442
Figure 44.11
Coax to Coax Repeater
CNA10 ASIC
Coax Transceiver
TxDataOut_A
Drop Cable
TxDataBar_A
Network
NetEnb_A
RxData_A
RxCarrier_A
Coax Transceiver
TxDataOut_B
TxDataBar_B
NetEnb_B
RxData_B
RxCarrier_B
Drop Cable
Network
CNA10 Pin
TxDataOut
(TxDataOut_A)
TxDataBar
Autoconfig Setting
4443
Connection

ControlNet hybrid is used, then no data inputs (Tx_A) of the
ControlNet hybrid.
the hybrid.
hybrid.

inputs (TxBar_A) of the ControlNet
hybrid.

Repeater mode. If the ControlNet
hybrid.

data inputs (Tx_B) of the
ControlNet hybrid.

hybrid.

inputs (TxBar_A) of the ControlNet
hybrid.
RxData_A
None required

hybrid.
RxCarrier_A
None required

hybrid.
RxData_B
None required

hybrid.
RxCarrier_B
None required

hybrid.
NetEnb_A
None required
None
NetEnb_B
None required
None
(TxDataBar_A)
/TxPTC
(TxDataOut_B)
/RxPTC
(TxDataBar_B)
Repeater in Fiber Mode

The REPEATER mode is configured by using a pull down resistor to
Vss (gnd) on the /TxPTC pin. The TxDataOut and TxDataBar pins
become dedicated output pins for channel A (TxDataOut_A and
TxDataBar_A). The pins that were used for the NAP connection
(/TxPTC and /RxPTC) now become dedicated transmit pins for
channel B. The transmit bar pins (TxDataBar and /RxPTC)
determine if the bar pins are configured for coax or fiber media.
Coax media is configured by using a pull down resistors to Vss (gnd)
and fiber media is configured by using pull up resistors to Vdd
(+5v). Note, the user can configure one channel for coax media and
the other for fiber media if so desired.
4444
Figure 44.12
Fiber to Fiber Repeater
CNA10 ASIC
Coax Transceiver
TxDataOut_A
Drop Cable
TxDataBar_A
Network
NetEnb_A
RxData_A
RxCarrier_A
Coax Transceiver
TxDataOut_B
Drop Cable
TxDataBar_B
Network
NetEnb_B
RxData_B
RxCarrier_B
CNA10 Pin
Autoconfig Setting
TxDataOut
Connection
(TxDataOut_A)
TxDataBar
(TxDataBar_A)
/TxPTC
(TxDataOut_B)
/RxPTC
(TxDataBar_B)
Requires pull up resistor for fiber

mode.
Repeat mode.
Requires pull up resistor for fiber
mode.
RxData_A
None required

hybrid.
RxCarrier_A
None required

hybrid.
RxData_B
None required

hybrid.
RxCarrier_B
None required

hybrid.
NetEnb_A
None required
None
NetEnb_B
None required
None
Package Dimensions
4445
Following are package dimensions for the TQFP and MQFP CNA10.
Figure 44.13
TQFP CNA10 Package Dimensions
16.00 +/0.40
14.00 +/0.20
14.00
+/0.20
16.00
+/ 0.4
1.60 MAX
DETAIL A
DETAIL A
1.40
+/0.05
0.15 max
0.22 +/0.05
0.50 typ
Note: 1. DIMENSIONS ARE IN MILLIMETERS

2. Ref VLSI Dwg No. 2590011 rev B
3. The above drawing and dimensions are for reference only.
4446
Figure 44.14
MQFP CNA10 Package Dimensions
23.90 +/0.25
20.00 +/0.10
17.90
+/ 0.25
14.00
+/0.10
3.40 MAX
DETAIL A
DETAIL A
2.80
+/0.25
0.36
0.10
0.30 +/0.08
0.65 typ
Note: 1. DIMENSIONS ARE IN MILLIMETERS

2. Ref VLSI Dwg No. 2590002 rev H
3. The above drawing and dimensions are for reference only.
Maximum Ratings
4447
Following are maximum ratings for the TQFP and MQFP CNA10.
Table 44.A
TQFP CNA10 Absolute Maximum Ratings
Parameter
minimum
maximum
Supply Voltage (VDD)
0.5 V
7.0 V
Power Dissipation @ 5.5 Vdc
536 mW (nonREPEATER)
457 mW (REPEATER)
Latchup triggering current
+100 mA (sink,
VPin = VSS 0.5V)
100 mA (source,
VPin = VDD + 0.5V)
Pin Voltage, steady state (excluding under and overshoot)
VSS 0.3V
VDD + 0.3V
Undershoot (see Figure 5)
1.7 V, 20 nsec
Overshoot (see Figure 5)
1.7 V, 20 nsec
Storage Temperature
40_C
+145_C
Temperature under bias (junction temperature must not

exceed 155_C at 85 % humidity).
25_C
+85_C
Static Protection
2000 V
Thermal Resistance in still air

Junction to Ambient qja (100 pin TQFP)
75.5_C per Watt
Junction to Case qjc
20_C per Watt
Notes:
In all cases, VSS = 0V. All voltages are with respect to VSS.
Latchup triggering current is defined as the current flow required through a pin protection diode before an SCR type latchup is triggered.
Overshoot and undershoot are defined by specifying a box, per Figure 44.15, defined by the specd voltage and duration, within which the pin
voltage waveform must be contained on any excursion beyond VSS300mV and VDD+300mV. Pin voltages contained within this box will cause
neither latchup, nor reliability problems.
Figure 44.15
Overshoot/Undershoot Definition
Voltage
VDD+0.3V
Overshoot
Duration
Duration
Undershoot
VSS 0.3V
Voltage
The device will withstand an electrostatic discharge of 2000 Volts, measured per MILSTD883C, Method 3015.3, Category B.
4448
Table 44.B
MQFP CNA10 Absolute Maximum Ratings
Parameter
minimum
maximum
0.5 V
7.0 V
Power Dissipation @ 5.5 Vdc
536 mW (nonREPEATER)
457 mW (REPEATER)
Latchup triggering current
+100 mA (sink,
VPin = VSS 0.5V)
100 mA (source,
VPin = VDD + 0.5V)
Pin Voltage, steady state (excluding under and overshoot)
VSS 0.3V
VDD + 0.3V
Undershoot (see Figure 5)
1.7 V, 20 nsec
Overshoot (see Figure 5)
1.7 V, 20 nsec
Storage Temperature
40_C
+145_C
Temperature under bias (junction temperature must not

exceed 155_C at 85 % humidity).
25_C
+85_C
Static Protection
2000 V
Thermal Resistance in still air

Junction to Ambient qja (100 pin TQFP)
60.4_C per Watt
Junction to Case qjc
20_C per Watt
Notes:
Latchup triggering current is defined as the current flow required through a pin protection diode before an SCR type latchup is triggered.
Overshoot and undershoot are defined by specifying a box, per Figure 44.15, defined by the specd voltage and duration, within which the pin
voltage waveform must be contained on any excursion beyond VSS300mV and VDD+300mV. Pin voltages contained within this box will cause
neither latchup, nor reliability problems.
Figure 44.16
Overshoot/Undershoot Definition
Voltage
VDD+0.3V
Overshoot
Duration
Duration
Undershoot
VSS 0.3V
Voltage
The device will withstand an electrostatic discharge of 2000 Volts, measured per MILSTD883C, Method 3015.3, Category B.
4449
Below are electrical characteristics for the CNA10.

Table 44.C
CNA10 Electrical Characteristics
Parameter
minimum
maximum
4.5 V
5.5 V
Ambient Temperature, still air (junction

temperature should not exceed 115_C per
AB guidelines).
0_C
TQFP:
75_C
(nonREPEATER)
80_C (REPEATER)
MQFP: 85_C
Humidity
5%
95% noncondensing
Input high voltage for /Xtal_In and

Data[7:0], VIH3
0.7 x VDD
VDD + 0.5 V
Input low voltage for /Xtal_In and Data[7:0],

VIL3
0.5 V
0.3 x VDD
Input high voltage all other pins, VIH
2.0 V
VDD + 0.5 V
Input low voltage all other pins, VIL
0.5 V
0.8V
Output high voltage, VOH
2.4 V
Output low voltage, VOL
0.4V
Pullup Resistor value
35K ohm
150K ohm
Leakage Current, inputs and tristated

outputs without pullup/pulldown resistors
10 microamp
10 microamp
Pin Capacitance, /Xtal_In and Xtal_Out
16 pF
Pin Capacitance, all other pins
10 pF
/Sys_Reset low input pulse width.

(Total required following initial power
up.)
20 milliseconds
/Sys_Reset required input pulse width.

(Secondary resets)
55 nsec75
Rising and falling edge time of /Sys_Reset

input
Unlimited
Rising and falling edge time, all other inputs
20 ns
Oscillator pads, gain
6.8 @ 60 MHz
Oscillator pads, transconductance
23.5 mA/V
Notes:
This spec applies only if the clock source is externally supplied (as opposed to using the specified
crystal oscillator circuit).
CMOS inputs
4450
Oscillator and Crystal

Specifications
The oscillator is shown schematically below. Component

specifications are included in Table 44.D. Use of components or
specifications other than those listed may violate the design
requirements.
Figure 44.17
Crystal Oscillator Circuit
PC6X03
ASIC
/Xtal_In
/Xtal_Out
R 1M
C1
10 pF
L
1 uH
C3
180 pF
C2
12 pF
Table 44.D
CNA10 Oscillator Circuit Characteristics
Parameter
Specification
Frequency
Duty Cycle
Startup time
Drive
Architecture
Resistor
Capacitors
Inductor
Frequency and Accuracy
Make Tolerance (@ 25_C)
Temperature Tolerance (0 to 85_C)
Aging for the first year
Aging for ten years
Total Frequency Accuracy
Load Capacitance
Overtone
Q
ESR (fundamental)
ESR (3rd overtone)
ESR (5th overtone)
Crystal
60.000 Mhz
50 +/ 10% max (40 to 60%)
20 milliseconds max
100 uW max
Miller Overtone
chip 1/8 W metal film
chip 5% NPO
chip 10%
60.000 Mhz
+/ 50 ppm max
+/ 50 ppm max
+/ 5 ppm max
+/ 20 ppm max
+/ 120 ppm max
21 pF
3rd
50,000 typ
10 ohms min
100 ohms max
150 ohms min
9904-XTAL
Host Interface Timing
4451
The Host Interface is defined to be the 3KB of Dual Port RAM

accessible by both the Host Processor and the CNA10s own internal
processor (Comm. Processor). This interface is designed to operate
in either BYTE access mode (for 8 bit host processors) or WORD
access mode (for 16 bit host processors). The mode is selected by
tying /HBE low for byte access mode or using it as a high byte select
for WORD access mode.
Most of the parameters for the read and write cycles are relative to
three instances of time within each bus cycle. They are:
startofcycle
endofcycle
cyclereset
The CNA10 has two timing modes for Ready or /Dtack. They are
Normal and Early. The ASIC powers up in Normal mode timing,
but gives the user the option of selecting Early timing through the
MSA_Operating_Modes configuration command. For hardware
timing consideration, be aware that all parameters relative to the
active true edge of Ready or /Dtack will change (by ~50 ns earlier)
when the user changes from Normal to Early. If your board design
will support the Early timing mode, you should inform your
programmer to enable said mode for increased product performance.
StartofCycle and CycleReset

Normal Operation Definition
A normal bus cycle to the Dual Port RAM is started at the falling
edge of /AS while /CE is low, as shown in Figure 44.18. A read or a
write will always begin at this point, and will not wait for any data
strobes. This corresponds to conventional RAM behavior. If the
/WR_R/W is stable while /AS is low, no spurious reads or writes
will occur.
Once a bus cycle is completed (defined as the endofcycle), the
Dual Port RAM latches up into a controlled state, to prevent spurious
operations, until the cyclereset occurs. A normal bus cycle is reset
at the rising edge of ALE/AS, as shown in figure 44.19. If ALE/AS
is tied low, then the cycle is reset at the rising edge of /CE, as shown
in Figure 44.20.
Note that processors which use an active high ALE behaves the same
as an active low /AS. They are high while address is changing and
transition low while address is guaranteed stable.
4452
It is required that any Dual Port RAM interface design guarantee a

startofcycle and cyclereset for EACH and EVERY bus cycle, even
if the bus cycles are back to back. If this requirement is not met,
circuit behavior is not guaranteed.
Secondary read cycles (those that follow any other cycle without
an intervening cyclereset) will not work. They will continue to
return the same data read earlier (or from a write cycles spurious
read). This is the disadvantage of ignoring data strobes for
internal read cycles. The advantage was significantly faster read
access times as they are relative only to the startofcycle.
When a write cycle begins, the read logic must shut down until a
cyclereset, to prevent spurious reads at the tail end of a write.
When a read cycle concludes, the read logic must shut down until
a cyclereset. Again, by ignoring data strobes for internal read
cycles, the Dual Port RAM would otherwise repeat internal read
cycles until a cyclereset occurs.
A write cycle normally ignores data strobes at the startofcycle,
but must reference the data strobes to define the endofcycle.
The result is that secondary write cycles (those that follow any
another cycle without an intervening cyclereset) will not begin
until a data strobe is seen.
Intel mode designs (using /RD and /WR) will never see a data
strobe (ie. /RD_/DS) during a write. In this case the write will
never occur and (if /Dtack is used) the bus will lock up.
Motorola mode designs, or Intel designs that create /DS and R/W,
should perform the secondary write properly. However, /Dtack
will be delayed until after /DS true, resulting in extra wait states.
A readmodifywrite bus cycles (no cyclereset between the read
and the write), in Motorola mode designs, should behave
correctly. However, the Dual Port RAMs design does not
implement an indivisible RMW cycle.
The Ready signal goes low at the startofcycle and returns high
at the completion of a normal read or write. To prevent glitches
on Ready, the high condition is then latched until the cyclereset.
Therefore secondary write cycles will not activate Ready. For a
write following a read, this is a moot point since the write is so
fast that Ready is not required.
Alternate Operation Definition
One other mode of operation, defining the startofcycle and
cyclereset also exists:
/CE may be tied low, and the /AS pin used as the chip select
function. In this case, the chip select must be guaranteed glitch
free and meet timing parameter tSD between back to back bus
cycles.
4453
Spurious Internal Cycles

If /WR_R/W is high at the falling edge of /AS and drops low at a
later time, an internal spurious read can occur followed by the actual
write cycle. For processors that use generic /WR and /RD style
strobes, this timing condition is expected and must be tolerated by
the Dual Port RAM design. The impact of this spurious read is to
lower the performance of the internal processor due to extra Dual
Port RAM contention.
Certain RAM locations are reserved for interrupt processing. Any
read to these addresses (including spurious reads) can trigger
hardware state changes. However each of the addresses are defined
as read only, so a spurious read on an actual write cant occur.
If /WR_R/W is low at the falling edge of /AS and goes high at a
later time, an internal spurious write can occur followed by the actual
read cycle. A spurious write cant be tolerated as the data will be
garbage. This places a special timing constraint on /WR_R/W.
Motorola mode interfaces use the R/W signal, which is driven high
at the end of every bus cycle, so the problem doesnt exist.
Some Intel mode interfaces may use an inverted DT/R signal. The
falling edge of DT/R, for a read cycle, plus the inverter time delay,
must meet setup time to the falling edge of ALE/AS.
The rising edge of DT/R, for a write cycle, plus the inverter time
delay, must also meet hold time relative to a previous reads
endofcycle. It is not necessary to meet a hold time relative to the
rising edge of ALE/AS (cyclereset), as this would be an impossible
condition for Intel 801xx. At first glance, this would appear to be a
spurious secondary write following a read cycle. However, the latch
mechanism that requires a data strobe for secondary writes will
prevent a spurious write.
4454
Table 44.E
Timing Parameters
Code
Type
tAS
tAH
tCS
tCH
tUSr
tUSw
tUHrn
Setup
Hold
Setup
Hold
Setup
Setup
Hold
tUHre
Hold
tUHw
Hold
tSHx
Hold
tSHg
Hold
Parameters
Min
Addr[11:0] stable before startofcycle. Normal latch mode.

Addr[11:0] stable after startofcycle. Normal latch mode.
/CE stable before startofcycle. Normal latch mode.
/CE stable after startofcycle. Normal latch mode.
Read cycle Addr[11:0] stable before /CE true. Disabled /AS.
Write cycle Addr[11:0] stable before /CE true. Disabled /AS.
Read cycle Addr[11:0] stable after rising edge of Ready or falling edge of /Dtack. Disabled /AS
mode (normal ready/dtack timing).
Read cycle Addr[11:0] stable after rising edge of Ready or falling edge of /Dtack. Disabled /AS
mode (early ready/dtack timing).
Write cycle Addr[11:0] stable after endofcycle.
Disabled /AS mode.
Minimum width of signal inactive until signal active again.
Special case of read following a write to the same address.
Minimum width of signal inactive until signal active again.
General case when write/read of same address doesnt occur.
Figure 44.18
Normal StartOfCycle Definition
Addr[11:0]
Addr Valid
tAS
tAH
/AS
tSH
tCS
tCH
/CE
startofcycle
cyclereset
Figure 44.19
Disabled /CE: /AS pin functions as chip select:
StartOfCycle Definition
Addr[11:0]
Addr Valid
tUS
tUH
/CE (tied low)

tSH
/AS
Ready
/Dtack
cyclereset
startofcycle
endofcycle
Max
Units
0
9
0
7
69
0
5
ns
ns
ns
ns
ns
ns
ns
45
ns
ns
50
ns
ns
4455
Startofcycle timing notes:

Parameters tUS and tUH have different values for read and write
cycles. They are split into tUSr, tUSw, tUHrn (Normal Ready,
/DTack), tUHre (Early Ready, /DTack), and tUHw.
For simplicity, parameters tUHr and tUHw are shown relative to
signals not on the timing diagram. Also, the relationships for
tUHr and tUHw are different.
EndofCycle
A normal bus cycle, for the Dual Port RAM, is terminated by the
first rising edge within the set of signals:
/AS Possible for any cycle when normal /AS mode is used
(also causes cyclereset).
/CE Possible for any cycle when /AS disabled mode is used
(also causes cyclereset).
Both /HBE and /LBE Possible for read cycles and /DS
controlled write cycles, and only if WORD access mode. Note
that the endofcycle is created by these signals only if both
signals go high before all else, not by either going high. In BYTE
access mode, /HBE is tied low so both going high is impossible.
/RD_/DS Possible for read cycles and /DS controlled write
cycles.
Note that for /WR controlled writes, /RD_/DS does not go low, so
rising edges on it, will not define the endofcycle.
/WR_R/W Possible for any write cycle.
Each possible cause of endofcycle is demonstrated in figures
44.20, 44.21, 44.22, 44.23, and 44.24, respectively.
A bus cycle will always terminate at the endofcycle. No other bus
activity should be attempted until a cyclereset (the rising edge of
/AS or /CE if in /AS disabled mode) occurs.
Figure 44.20
/AS Based EndOfCycle (Only if Normal /AS Mode)
/AS
/CE
/HBE, /LBE
/RD_/DS,
/WR_R/W
Stable
endofcycle
4456
Figure 44.21
/AS Based EndOfCycle (Only if /CE Disabled Mode)
/CE (tied low)
/AS
/HBE, /LBE
/RD_/DS,
/WR_R/W
Stable
endofcycle
Figure 44.22
/HBE and /LBE Based EndOfCycle (WORD Mode Only)
/AS
/CE
/HBE
Stable
/LBE
Stable
/RD_/DS
/WR_R/W
Stable
endofcycle
Figure 44.23
/RD_/DS Based EndOfCycle (Reads or /DS Controlled Writes)
/AS
/CE
/WR_R/W
Stable
/RD_/DS
endofcycle
4457
Figure 44.24
/WR_R/W Based EndOfCycle (Writes Only)
/AS
/CE
/RD_/DS
Stable
/WR_R/W
endofcycle
Read Cycles
Table 44.F
Timing Parameters for Read Cycles
Code
Type
tWS
tWH
tSV
tSD
tRD
tSZ
tSR
Setup
Hold
Delay
Delay
Delay
Delay
Delay
tSYn
Delay
tSYe
Delay
tRY
Delay
tEHn
Hold
tEHe
Hold
tEY
tEZ
tLBE
Delay
Delay
Delay
Parameters
Read cycle /WR_R/W goes high before startofcycle.
Read cycle /WR_R/W remains high after endofcycle.
Startofcycle until Data[n:0] valid.
Startofcycle until Data[n:0] driven.
/RD_/DS true until Data[n:0] driven
Cyclereset until Ready and /Dtack float tristate.
Startofcycle until Ready driven false or
Startofcycle until /Dtack driven false.
Read cycle startofcycle until Ready true (rising edge) or
Read cycle startofcycle until /Dtack true (falling edge).
Normal ready/dtack timing mode.
Read cycle startofcycle until Ready true (rising edge) or
Read cycle startofcycle until /Dtack true (falling edge).
Early ready/dtack timing mode.
/RD_/DS true until Ready or /Dtack true
Either normal or early ready/dtack timing mode.
Endofcycle after Ready true (rising edge) or
Endofcycle after /Dtack true (falling edge).
Endofcycle after Ready true (rising edge) or
Endofcycle after /Dtack true (falling edge).
Endofcycle until /Dtack false (rising edge).
Endofcycle until Data[7:0] floats tristate.
Startofcycle until /LBE true (WORD access mode ONLY)
Min
Max
Units
180
33
26
11
21
ns
ns
ns
ns
ns
ns
ns
165
ns
117
ns
24
ns
0
0
ns
52
ns
21
14
80
ns
ns
ns
4458
Figure 44.25
Timing Diagram for Read Cycles
Addr[11:0]
Addr Valid
/AS
/CE
tSV
/HBE,
/LBE,
/RD_/DS
tLBE
/WR_R/W
tWS
tRD
tWH
tSD
tEZ
Data[n:0]
Data Valid
tSZ
tSY
tSR
tRY
tEH
tEY
Ready
/Dtack
cyclereset
startofcycle
endofcycle
Read cycle timing notes:

The time when the Data[n:0] bus is driven is determined by the
worst case effect of tSD and tRD.
The time when the Data[n:0] bus has valid data is determined by
the access time, tSV, and assumes the bus is already driven due to
tSD and tRD (as shown above).
The rising edge of Ready or falling edge of /Dtack is determined
by the worst case effect of tSY and tRY.
The endofcycle is defined as when the first read cycle control
signal goes false. The signals are ALE/AS, both /HBE and
/LBE (WORD access mode only) or /RD_/DS. When a signal
goes false, it must remain false for an implied hold time of tSH
for the endofcycle to be latched internally.
In general, the critical timing parameter for read cycles is (tSY +
tEH). A slow processor interface is defined when the
startofcycle to endofcycle period exceeds said time under all
possible processor read bus cycles. Such designs may ignore
signals Ready or /Dtack.
4459
Write Cycles
Table 44.G
Timing Parameters for Write Cycles
Code
Type
Parameters
Min
tRS
tW1
Setup
Setup
0
0
ns
ns
tW2
Setup
ns
tDS
tDH
tSZ
tSR
tPYn
Setup
Hold
Delay
Delay
Delay
5
0
11
17
210
ns
ns
ns
ns
ns
tPYe
Delay
164
ns
tTY
Delay
24
ns
tWY
Delay
22
ns
tEHn
Hold
tEHe
Hold
tTH
Hold
tEY
Delay
/RD_/DS false before startofcycle.

Write cycle /WR_R/W stable low before startofcycle.
Optional parameter. If violated, spurious internal read cycles, with Dual Port RAM contention, can
be generated. This will lower internal processor performance.
Write cycle R/W stable low before /DS true. Parameter applies only if /DS is generated during write
cycles. /WR based write cycles do not drive /RD low.
Data[n:0] stable before endofcycle.
Data[n:0] remains stable after endofcycle.
Cyclereset until Ready and /Dtack float tristate.
Startofcycle until Ready false (falling edge).
Previous writes endofcycle until Ready true (rising edge) or
Previous writes endofcycle until /Dtack true (falling edge).
Previous writes endofcycle until Ready true (rising edge) or
Previous writes endofcycle until /Dtack true (falling edge).
Write cycle startofcycle until Ready true (rising edge) or
Write cycle startofcycle until /Dtack true (falling edge).
/WR_R/W true until Ready true (rising edge) or
/WR_R/W true until /Dtack true (falling edge).
If Ready true or /Dtack true caused by tPY, then
Endofcycle after Ready true or /Dtack true.
If Ready true or /Dtack true caused by tPY, then
Endofcycle after Ready true or /Dtack true.
If Ready true or /Dtack true caused by either tTY or tWY, then Endofcycle after Ready true or
/Dtack true.
Endofcycle until /Dtack false (rising edge).
Max
Units
ns
47
ns
ns
19
ns
4460
Figure 44.26
Timing Diagram for Write Cycles
Addr[11:0]
Addr Valid
ALE/AS
/CE
tRS
/HBE,
/LBE,
/RD_/DS
tW1
tW2
/WR_R/W
tDS
Data[n:0]
tDH
Data Valid
tPY
tEH
tSZ
tTY
tTH
tSR
tWY
tEY
Ready
/Dtack
cyclereset
startofcycle
endofcycle
Write cycle timing notes:

The rising edge of Ready or the falling edge of /Dtack is
determined by the worst case effect of tWY, tTY, and tPY. The
earliest endofcycle is determined by the worst case effect of
(tWY + tTH), (tTY + tTH), and (tPY + tEH).
The endofcycle is defined as when the first write cycle control
signal goes false. The signals are ALE/AS, both /HBE and /LBE
(WORD access mode only and see note below), /RD_/DS (see
note below) and /WR_R/W. When a signal goes false, it must
remain false for an implied hold time of tSH for the endofcycle
to be latched internally.
The condition of /RD_/DS low and either /HBE low or /LBE low
is optional and latched internally. If the condition does not occur
(/WR controlled writes), none of these three signals generates an
endofcycle, and parameter tW2 does not apply.
In general, the critical timing parameter for write cycles is (tPY +
tEH). A slow processor interface is defined when a write
endofcycle to the next write endofcycle period exceeds said
time under all possible processor bus cycles. Such designs may
ignore signals Ready or /Dtack.
LEDs
4461
The CNA10 ASIC provides output pins to drive two bicolor LEDs
in one of three states. Table 9 depicts the three supported LED states
Each LED output pin can drive 8 mA. External drivers are required
for nodes demanding more LED current than that supplied by the
CNA10 LED driver pins. An example LED connection for LEDs
requiring less than 8ma operating current is shown below in Figure
44.27. If external drivers are used, pullups on the CNA10 LED
driver pins are required because the pins will float during reset.
Table 44.H
Bicolor LED States

Green LED ON
logic 0
logic 1
Red LED ON
logic 1
logic 0
LED OFF
logic 0
logic 0
Figure 44.27
Example Bicolor LED Connection
CNA10 ASIC
316 W
LED Red
Bicolor
LED
LED Green
for LEDs requiring
8 ma operating current
LED Request Prioritization

The different LED indications and their meanings are outlined below
in Table 44.I. The table is in descending priority order of the display
requests. The table is also broken down into two sections, one
section for indications that use both LEDs, and one section for
indications that handle each LED independently (one LED per
channel).
4462
Table 44.I
LED Pattern Indications by Priority
Indications that use both LEDs together
Priority
Status
Code
LEDs A & B
Indication
1st
Off
No power or reset (also see the 9th priority)
2nd
Red
Failed unit.
3rd
Railroad RedGreen
Self test.
4th
Railroad RedOff
Bad node configuration. (Duplicate node ID, etc.)
Indications that use each LED independently

Priority
Status
Code
Active / error channel LED
Indication
5th
Flashing RedGreen
Bad network configuration.
6th
Flashing RedOff
Cable fault or lonely. (Broken cable, redundancy

warning, etc.)
7th
Flashing GreenOff
Temporary network errors. (bad MAC frame,

screeners not programmed, modem not online,
etc.)
8th
Green
Channel OK
9th
Off
Channel disabled
In a nonredundant network (e.g. only one channel is selected), the

upper table conditions are displayed on both LEDs, same as in
redundant network. The lower table conditions are only displayed
on the LED of the selected channel, while the LED of the unselected
channel is off. In a redundant network, the flashing conditions in the
lower table will be in phase (both off or both active simultaneously).
By coincidental behavior, the following known anomalies exist
within the priority structure:
A cable fault in a nonredundant network will appear at a higher
priority than a bad network configuration error. Since, if the
cable is missing or bad, data is not received at all.
A modem that is offline will appear at a higher priority than a
cable fault or lonely.
Description of Error Conditions

No Power or Reset This is the highest priority level, it overrides all
other conditions. When power is not supplied to the CNA10 or reset
is held on it, both LEDs will be off. During reset, the LED pins
tristate, allowing the LEDs to turn off.
Failed Unit Is the 2nd priority level, it overrides all lower priority
conditions. When this condition occurs, node repair (or reset) is
required. This condition is the result of the a fault detected by either
the MAC or the Comm Processor. This results from a jabber
condition or failing self test.
4463
Self Test Is the 3rd priority level, it overrides all lower priority
conditions. This condition occurs immediately after reset when either
the Comm or the MAC Processor are in test mode. The LED display
for selftest is stretched to a minimum of 3 seconds even though the
self test does not last that long.
Bad Node Configuration Is the 4th priority level, it overrides all
lower priority conditions. This condition occurs in the case of bad
MAC configuration (duplicate MAC ID or rogue condition, either is
mismatch between moderator and net config) or in the case of
configuration timeout (corrupted or missing configuration file, as
determined by the Comm Processor). The indication for duplicate
MAC ID is shut off when the node leaves the rogue/dupnode state.
The CNA10 will not automatically indicate bad node configuration
when it sees another node at its MAC ID if the hotbackup bit is set
in the Host Interface Config Object. The ASIC will force the
LEDs to indicate bad node config only when the CNA10 is in the
rogue or dupnode states, unless otherwise instructed by the host.
Setting the no rogue/dupnode LEDs bit in the host config object also
prevents the CNA10 from automatically flashing this state.
Bad Network Configuration Is the 5th priority level, it overrides
all lower priority conditions. The Comm Processor firmware has
total control over this LED condition. This condition is activated if
the internal FIFOs overflows or underflows, if that event indicates
that the network data flow sequencing needs adjustment. Also, if a
timeout problem is detected (producer or consumer failure). This
condition should have a software timer routine to deactivate and
stretch the indication to 4 seconds.
Bad Network Configuration is displayed on both LEDs
simultaneously in a redundant network, and on the LED of the
selected channel in a nonredundant network.
Cable Fault or Lonely Is the 6th priority level, it overrides all
lower priority conditions. Cable errors include missing or faulty
(broken or noisy) cables. By hardware design, a CNA10 with its
modem shut off never gets lonely, and is oblivious to its cables.
This indication (flashing red) can occur on both channels
simultaneously only if either
both drop cables are completely disconnected; or
no other nodes are present (the CNA10 is lonely).
If excessive errors are occurring on both channels, the LEDs will
seem to be very erratic, jumping between flashing red and flashing
green on the two channels. If media errors are occurring on one
channel only, its LED will be flashing red while the other channels
LED will be flashing green or solid green.
4464
Cable Fault takes time to heal. A large number of data bits, with
proper valid manchester encoding must be received before the LED
will cease flashing red. This can take a long time if the network is
lightly loaded. Users will need to know that plugging in a second
channel in a redundant network will not immediately extinguish the
red light on that second channel, even when the connection is
perfect. A fixed CID (19h) is recognized by the CNA10 for resetting
this redundancy arbiter. This allows field personnel who are
equipped to generate this packet to avoid the delay in extinguishing
the red light.
The value of this indication is informing the field tech which cable
not to disconnect when only one cable is reliable.
Temporary Network Errors Is the 7th priority level, it only
overrides the no errors condition. This condition includes:
Off-line: Indicates that the node is off line (its modem is not
enabled). The modem enable is a bit within the host configuration
packet. This also affects both LEDs in redundant networks and
only one LED in nonredundant networks.
Screeners not programmed: This condition persists until the first
swap complete condition caused by programming the screener
tables following self test. This also affects both LEDs in
redundant networks and only one LED in nonredundant
networks. A dummy screener swap command must be completed
for a node in promiscuous receive mode in order to prevent this
error display condition.
Channel A Packet Error, channel B Packet Error: These are
indications of bad packets received on either channel A or
channel B, due to manchester violations or bad end delimiters.
(A bad start delimiter is only detectable in a redundant network,
with one good channel.) This is a temporary event that does not
require user intervention, unless too many bad packets are
received in a short period of time, which would be considered a
cable problem and indicated at a higher priority level. The LED
display for this condition will be stretched to 3 or 4 seconds.
Channel OK Is the lowest priority level. This condition indicates
that the node and network is operating without errors.
4465
LED Reflection of NAP Operation, Normal Network

Under normal operation, there are no LED indications showing the
presence or absence of a device connected through the CNA10s
NAP. Figure 44.28 shows an example of a connection between an
HHT (Hand Held Terminal) and a CNA10 with nothing connected to
its network inputs. The CNA10s LEDs will indicate flashing red
(lonely), as though the HHT did not exist, despite the fact that the
CNA10 and the HHT establish a fully functional connection between
them. grout
Figure 44.28
Example, no LED indication for NAP activity
normal
communication
HHT
FLASHING RED
NAP
CNA10
Network Connections
LEDs
Even though the HHT sends good packets,

the CNA10 will display Cable Fault or Lonely
on its LEDs, because it hears only silence
from its network connection.
While the CNA10 repeats the NAP data onto
the Network connections, it cant hear them
from the network side because its receiver is
blanked during its transmission.
OPEN
Figure 44.29 shows another example, where an HHT is connected to

a node which is also connected to other nodes, and has built a
network with them. Even if the HHT sources a bad packet, the LEDs
will still display green, as though the bad packet was never heard.
Note though, that the other nodes on the network will flash
temporary error when they see that packet.
Figure 44.29
Example, no LED indication for NAP activity
a bad packet
HHT
SOLID GREEN
NAP
CNA10
Because there is a network established including

nodes on the network side, the CNA10 will operate
with green LEDs. Should the HHT generate a bad
packet, the CNA10 LEDs will not reflect it, instead
remaining solid green.
Network Connections
LEDs
Node
Node
4466
LED Reflection of NAP Operation, NAP Only Mode

A NAP Only function has been added to the CNA10. There are two
CNA10 Network Configuration bits for enabling the network
channel for redundancy. They are interpreted as:
0
0
1
1
0
1
0
1
NAP Only Mode

Enable channel B only
Enable channel A only
Activate redundancy.
A CNA10 which maintains a network connection via the NAP only

instead of a normal network connection, must clear both network
channel enable bits within the Network Configuration Packet, to get
the LEDs to indicate NAP operation. These two bits are directly
outputs from the CNA10 as the pins Net_Enb_A and Net_Enb_B.
When both bits are shut off within the Modem, for NAP Only mode,
several behavior changes will occur.
Both outputs, Net_Enb_A and Net_Enb_B, are disabled,
preventing any transmission on the network.
The clock recovery selection of NAP cables is permanently
forced, preventing any reception from the network.
The modem block treats it as if both channels are enabled, as in
redundancy mode. No matter which channel is active, the NAP
data will be heard. Both LEDs will be on and always indicating
the same thing.
The hardware block, that prevents the broken cables logic from
hearing the NAP, is removed. A broken NAP cable will cause
flashing red on both LEDs.
The hardware block, that prevents the bad packet detection from
indicating bad NAP packets, is removed. Bad packets on the NAP
will cause flashing green on both LEDs.
In a redundant network, if a cable fault occurs on one channel and
a network error occurs on the other channel, then different
indications will be displayed on the two LEDs. This situation
occurs only in a redundant network, and it is the only situation
where two distinct LED indications will occur. Following are the
two scenarios where this can happen:
A cable fault exists on one channel, and the screeners are not
programmed. One channel will display the cable fault, since it
is the higher priority error. On the other LED, the temporary
network error will be displayed, since it is the only error
affecting that LED.
A cable fault exists on one channel, and a bad packet is
received on the other channel. Each channels error will be
displayed on its LED.
System Considerations
4467
Blanking
The holdoff timer is used to implement both the blanking time and
the holdoff time. These times are interrelated, as described below.
The CNA10 always blanks its receive channel while transmitting. In
certain cases, the blanking must be continued after the transmission
completes.
The Blanking time is defined as the length of time required after
transmitting a frame, before the node is allowed to receive. Blanking
is specified as a number of bytes. The blanking time (number of
bytetimes) is supplied in the Network Configuration Packet. All
receive channels are blanked after this nodes transmissions. This is
required to blank echoed transmissions for fiber optic star networks.
The blanking time is also used to blank the receive channels after
receiving a message. This is necessary because the CNA10 functions
as a repeater for those received messages. Messages received on the
network are forwarded out the NAP port. Messages received from
the NAP are forwarded out onto the network. Hence, the blanking
time must be applied on the side that the CNA10 is transmitting on.
While data received during the blanking time on the active receive
channel is not blanked (it is fed up to the MAC), it will not be
repeated onto the other channels as long as the blanking timer has
not expired. This has a beneficial effect for operation in repeater
mode. The effects of noise will be eliminated between {the end
delimiter of repeated frames} and {the expiration of the blanking
timer}. This may make it desirable to set the blanking time longer
than the required minimum.
Rx or Tx
Receiving Rx Channel
Mode, Repeater or
Non
Blanked Rx Channels
Transmit
either
all
Receive
A or B
nonRepeater
NAP
Receive
NAP
nonRepeater
A and B
Receive
Repeater
Receive
Repeater
Whenever the modem is receiving or transmitting a message, a signal

is used to preload a blanking value into an 8 bit down counter. At
the conclusion of the message, the counter counts down until it
reaches zero. A feedback in the counter prevents it from
overflowing beyond zero. The nonzero state of the counter is used
to control the packet assembler and the repeater state machines, to
blank the specified receive channels. The blanking time is circulated
in the moderator packet.
4468
Holdoff
The Holdoff time is defined as the length of time required after
completion of receiving or transmitting a frame, before the node is
allowed to transmit. Holdoff is calculated as the maximum of:
{blanking plus 1 bytetime} or {the MicroRISC turn around time}.
The MicroRISC turn around time is currently approximately 6
bytetimes. Refer to the protocol spec ER# CD0110 for information
on this parameter. Therefore, any blanking time less than or equal to
5 can still result in an effective holdoff time of 6 bytetimes (or more
if the firmware changes) under some conditions.
The Gen screeners require a minimum MAC frame spacing of 2
bytes to do CRC related updates. Therefore, it dictates a minimum
blanking time of 1 bytetime, independent of the minimums that are
required for the various media types, as follows.
In a redundant network, holdoff (blanking plus one) must exceed the
worst case skew between the reception of two channels, which is less
than four bytes. For networks with remote echo of transmitted
packets (ie., a fiber optic star that echos to all channels), the value of
the blanking timer must also exceed the worst case echo of the
message through the remote device back to the originating node.
The minimum required blanking times for different media types are:
Coax Bus, Single Channel 0* bytes
Coax bus, Redundant 3 bytes
Fiber Star w/o echo in the star, Single Channel 0* bytes
Fiber Star w/o echo in the star, Redundant 3 bytes
Fiber Star w/ echo in the star Worst case echo delay 13 bytes
Fiber Ring Greater than the total ring delay and less than max
slot time 158 bytes
Head End Broadband or RF Wireless Greater than the total
turnaround delay, and less than max slot time 158 bytes
* 1 bytetime is still required for the Gen screener change field
update.
The difference in performance in a Fiber Star system, between a star
with and without echo, is not as great as the blanking time suggest.
The total delay through the star is the earliest possible turnaround,
whether blanking is set to this value or not. In one case, the delay
matches the installation. In the other, the delay will always be the
blanking time.
4469
Jabber
The jabber timeout delay is a function of the source of the data being
transmitted. With the NAP used, every node is a repeater, since every
node transmits each message it receives somewhere. Using multiple
delay values prevents every node from faulting (detecting jabber, and
tripping its fault line) when any one node jabbers. It allows the
original jabbering transmit device to timeout first. Only if it does not
timeout, does the local CNA10 (and any other node at the same
timing level) fault.
The following list is four scenarios, in order of increasing protection.
Ideally, each entry should have different and progressively higher
detection levels. The following were implemented:
1. From CNA10 transmit to anywhere 1024 bytes
2. From NAP to network 2048 bytes
3. From network to network (repeater) 2048 bytes
4. From network to NAP (jabber here will not be detected)
Several anomalies may result:
If a node jabbers while repeating a network message to the NAP,
it will continuously transmit to the programming terminal that
may be attached. It does not fault.
If a programming terminal jabbers, but does not fault itself due to
its severity, the node it is attached to and every repeater on the
network will fault.
If any node jabbers, but does not fault itself due to its severity,
every repeater on the network will fault.
If any repeater jabbers, any other repeater in the transmit
direction, at the time of the jabber, will also fault.
Note that anything that causes a repeater to fault will sever the
network. In a single channel nonredundant system, a repeater is a
single point of failure. In terms of time at 5 Mbps, 1024 bytes is 1.64
msec and 2048 bytes is 3.28 msec.
Repeater Operations
The repeater design allows for an indefinite number of series
repeaters in a system. The practical limit to the number is network
performance related. A delay is incurred moving through the
CNA10s Clock Recovery and Elastic buffer circuits. Each
networktonetwork repeater and each networktoNAP connection
in a signal path introduces 3.5 bits (700 ns at 5 Mbps) of delay,
which must be considered in the slot time and throughput
calculations.
4470
External Comm Processor

ROM
An option is provided on the CNA10 package to have the Comm

processor execute code from an external memory device. This
memory device could be ROM, dualported RAM or even Flash
Memory. External memory is required for all products except a
repeater.
The external ROM execution is enabled by activating the
ROM_Bypass pin. This pin must only be switched when the CNA10
ASIC is in a powereddown or reset state. While the ROM_Bypass
pin is deactivated, the ROM_Addr[15:0] are floated. The
ROM_Addr[15:0] pins are only driven when the ROM_Bypass pin
is activated.
Unless it is held in a wait state, the Comm processor fetches code
every 100 nsec. When valid ROM address appears at the address
pins, the external device has 60 nsec. to apply valid data at the
ROM_Data[7:0] pins.
Since the internal ROM is a 16k device, the two most significant bits
of ROM_Addr[15:0] are not used. The designer may choose not to
connect these address pins.
Figure 44.30
Comm Processors External ROM Timing
Comm Processor Cycle = 100 nsec.
ROM_Addr[15:0]
Valid ROM Address

tAC
ROM_Data[7:0]
Valid ROM Data
Table 44.J
External ROM Timing Parameters
Code
Type
tAC
Access
Parameters
Valid ROM_Addr[15:0] to valid
ROM_Data[7:0]
Min
Max
Units
60
ns
Errata
4471
Data[7:0] Pins are CMOS
ATTENTION: CMOS levels are used on the Data[7:0]

I/O pads. The designer must be sure to guarantee VIH
levels from TTL outputs.
Ready and /Dtack Stay Inactive During Reset

If a user relies on the Ready or /Dtack signal to terminate a processor
read or write cycle, he/she must not perform a access to the CNA10
dual port interface while it is in a reset state. During reset, the
CNA10 will activate the Ready and /Dtack pins but will never
deactivate them, thus hanging up the processor indefinitely.
Gate /CE external with reset so that /CE to the CNA10 doesnt
activate during reset. Note, you will read garbage but the
processor will not get hung up.
LBE must be active within 80ns for correct 16bit mode

operation
In 16bit mode, if /LBE is not activated within 80ns after
StartOfCycle, incorrect data will be read from the dualport.
Host processor must ensure that /LBE timing parameters are not
violated.
Generic Screener is not disabled when transmitting

If programmed to do so, it is possible for the CNA10 ASIC to
receive its own transmitted packet. This is only possible if producer
and consumer CIDs are programmed to be equal.
Connection manager assures that the producer and consumer
CIDs are unique for each node.
4472
Notes:
Chapter
45

This chapter contains schematics that show example ControlNet

hardware implementation. It contains these schematics:
Schematic
Page
Read-only Flash Interface
452
ROM Interface
453
TTL Oscillator And LED Interfaces
454
Crystal Oscillator And LED Interfaces
455
Isolated NAP Port Interface
456
Non-isolated NAP Port Interface
457
Redundant Coax Interface
458
PCB Layout
459
Coax Repeater Interface
4515
452
Example Hardware Implementation
Read-only Flash Interface
453
ROM Interface
454
TTL Oscillator And LED

Interfaces
455
Crystal Oscillator And LED

Interfaces
456
Isolated NAP Port

Interface
457
Non-isolated NAP Port

Interface
458
Redundant Coax Interface
PCB Layout
459
PCB Layout Figure 1
4510
PCB Layout Figure 2
4511
PCB Layout Figure 3
4512
PCB Layout Figure 4
4513
PCB Layout Figure 5
4514
PCB Layout Figure 6
4515
Coax Repeater Interface
4516
Notes:
Chapter
46

The ControlNet Example Code is a fully functional implementation
of the communications layers and the support services needed to
connect a device to the ControlNet network using a CNA10 ASIC.
It provides the following functionality:
General use foundation services
Example Multitasking Kernel
Unconnected Message Manager Object (UCMM)
Device Object
PCCC messaging and CIP messaging API
1771 Rack Object
Section
Page
General Architecture
The Food Chain And Its Components
Porting Guide
Coding Standards
462
464
4612
4612
462
General Design Overview/Porting Guide
General Architecture
A ControlNet device based on the ControlNet Example Code

consists of four major layers of code as shown in the diagram below.
Target Application
Application
BASIC
Services
API
(AB)
Messaging
API
(AM)
Adapter
API
(AA)
CNEC
ControlNet Core Code (CNCC)

Kernel
Kernel
The ControlNet Example Code runs on top of a realtime
multitasking kernel. The kernel may be preemptive or
nonpreemptive. A fully functional but unsupported example kernel
for Intel 80x86 processors is included in the Example Code. It is
intended that this example kernel be replaced by a commercial kernel
or an internally written kernel.
463
The ControlNet Example Code is designed using a

Task/Queue/Object model. Each object in the code is executed in the
context of a task with a single request/response queue through which
it receives service requests and responses. This provides code that
partitions cleanly along the object boundaries. Each object can exist
independently of others. Objects communicate across clean, well
defined interfaces (the request/response queues). The code is cleanly
partitioned. Only the objects required for a product need be
included. All others are easily excluded.
Response
Tribble
Object
Task 0
Q
Object
Task 1
Request
Tribble
Request
Tribble
Q
Object
Task 2
Object
Task 3
Response
Tribble
464
The Food Chain And Its

Components
The ControlNet Example Code consists of a food chain built out of

a number of individual components. A component is a grouping of
interrelated definitions and routines. Each component implements
one logical portion of functionality or one object. Upper-level
components in the food chain use and build upon the services
provided by lower-level components.
Components are identified by a two-letter prefix. The prefix for a
component is used to start the file names of the source files for the
component, the names of services (functions or macros) within the
component, and the names of the global data elements within the
component.
The individual components of the example code are collected into 6
major groups:
Foundation Services
ControNet Specifics
ControlNet ASIC Support
CIP Messaging Support
Application Program Interfaces (APIs)
Applications
Each of these groups is detailed in the following sections.
Foundation Services
The Foundation Services portion of the example code provide a base
set of data definitions and services upon which the remainder of the
example code is built. The set of components that make up the
Foundation Services are:
FD Fundamental Definitions
BU Bit Manipulation Utilities
OS Operating System
OE Operating Environment (Porting interface only)
UC Utilities Collection
LQ Linked Queues
GS Global Services
FD Fundamental Definitions
The Fundamental Definitions component provides the definitions of
the basic data types used throughout the example code. This
component contains definitions and macros only. There are no .c
files.
465
BU Bit Manipulation Utilities

The Bit Utilities component provides fast table lookup conversions
of bit numbers into bit masks. The table lookups are much faster
than a shift operation to build a bit mask from a bit number. These
services are used primarily by routines that interface with the
ControlNet ASIC.
OS Operating System
The Operating System component contains the realtime
multitasking kernel that all of the example code and application code
runs on top of. The example code contains a sample kernel written
for Intel 80x86 processors running large model code. This sample
kernel is provided as an unsupported example of the functionality
required for the kernel. It is an exact implementation of all of the
services defined in the OE kernel porting interface. It is intended to
be replaced by a commercial or homegrown kernel in your
product.
OE Operating Environment
The Operating Environment component is a porting interface for the
realtime multitasking kernel. It contains definitions only. If
required, interface code to map the OE service definitions to the
actual kernel services is contained here. For most kernels, it should
be possible to map the operations using macros.
Rather than attempting to code to a specific kernel, the Example
Code is written to a simple Operating Environment (OE) interface.
The OE interface consists of exactly one dozen services. It is these
services that need to be ported to the specific kernel being used on
the product.
To maximize portability and minimize the porting effort, the number
of services has been kept to an absolute minimum. Only 12 services
are defined. Services for task creation and scheduling and event
handling are defined.
Task support is defined for creating tasks at unique priorities and for
scheduling the execution of those tasks.
Event support is defined for events (essentially a binary semaphore)
that provide for a single task to wait on an event and multiple tasks
to set an event.
Higher-level services such as queuing, timers, and memory
management are provided by the Global Services (GS) component of
the Example Code and need not be ported.
466
There are two user interface files provided to simplify the mapping
of the OE data types and services to the appropriate kernel data types
and services. The remappings of data types are to be placed in the
file OE_LTYPE.H and the remapping macros are to be placed in the
file OE_LSERV.H.
UC Utilities Collection
The Utilities Collection component contains replacement code for
commonly used services that are normally contained in C libraries.
By providing these services, it is not necessary to include library
code in the final product code. This avoids possible licensing and
royalty issues. It also provides visibility into these services and the
ability to optimize these services.
LQ Linked Queues
The Linked Queues component contains services to support the
creation and management of singly and doubly linked queues. It
consists primarily of a series of macros to optimize the performance
of the operations. These services are not to be confused with the
Global Services intertask queue operations (although those services
are built using these services.)
GS Global Services
The Global Services component contains a number of services:
Remapped OE services
Memory (heap) Management
Fault Assertion and Generation
Intertask Message Queues
Tribble management
Task Delay and General Use Timers
Remapped OE services
To provide a consistent interface, all of the OE services are
remapped to GS services of the same name via simple macros. This
is done to keep developers from having to remember whether a
particular low level service is in the OE component or the GS
component.
Memory (heap) Management
The Memory Management services provide for the initialization and
maintenance of a memory heap for dynamic memory usage. Unlike
a traditional general use heap which can uncontrollably fragment
over time, this heap is fragmented in a controlled way when it is
initialized.
467
The heap consists of a number of pools of fixed size memory

chunks. The number of pools, the sizes of the chunks in each pool,
and the number of chunks in each pool are configurable. The sizes
of the chunks are definable as any multiple of 16 bytes.
Fault Assertion and Generation
The Fault Assertion and Generation services provide a way to log
both warning and fatal faults. The Fault Assertion services mimic
the standard C assert function and log a fault only if a certain
condition is true and the DEBUG compile switch is defined. The
Fault Generation services log a fault whether the DEBUG compile
switch is defined or not.
Warning faults are placed in a fixed depth FIFO to be processed by a
fault handling task. The depth of the FIFO is configurable. Fatal
faults are passed directly to a fatal fault processing subroutine for
immediate processing.
Intertask Message Queues
Intertask message queues are built from a combination of linked
queues and an event. Only one task may wait for messages on a
queue while any number of tasks may put a message on a queue.
The queues themselves are singly linked lists used as a FIFO without
a fixed size.
These are the queues that are at the heart of the TaskQueueObject
model used throughout the example code.
Tribble management
Tribbles are a common Task Request Response BLock (TRRBL)
used to pass requests and responses between tasks. They are passed
between tasks via message queues. They contain the following
information:
Request/response code
Completion Status/Error code
Return address (message queue identifier)
Parameters (data and/or pointers)
When a tribble is processed by a task, the task doing the processing
need not be aware of which task generated the tribble. This is
possible because the identity of the message queue to which the
tribble is to be returned after processing is included in the tribble
itself.
468
Task Delay and General Use Timers

The timer support services consist of task delay timers and general
use timers. The task delay timers are used to simply delay the
execution of a task a given amount of time. The general use timers
are dynamically allocated from the heap when needed for any use.
General use timers come in three flavors:
Continuous running
One shot
One use
Continuous timers automatically retrigger themselves when they
time out. One shot timers stop running when they time out and must
be explicitly retriggered to start timing again. One use timers free
themselves back to the heap when they time out.
A general use timer may be set up to do one of four things when it
times out:
Do nothing
Set an event
Queue a Tribble on a message queue
Run a short subroutine (Phase 1.5)
ControlNet Specifics
The ControlNet Specifics portion of the example code provide data
definitions and services for handling message buffers and parsing the
messages within those buffers. The set of components that make up
the ControlNet Specifics are:
CB Communication Buffers
CN ControlNet Specifics
CB Communications Buffers
Communications buffers (Combufs) are a data buffer with an
attached data structure for managing that buffer. Combufs are
designed to allow the appending and stripping of headers from data
packets without having to move the remainder of the data packet.
CN ControlNet Specifics
The ControlNet Specifics component provides the definitions and
services to handle and parse ControlNet packets.
469
ControlNet ASIC Support

The ControlNet ASIC Support portion of the example code provide
data definitions and services for interfacing with the ASIC. The set
of components that make up ControlNet ASIC Support are:
CA CNA10 ASIC Specifics
CS Communication Services
CA CNA10 ASIC Specifics
This component provides the collection of low level services that
isolates the developer from having to directly access the CNA10
ASIC. All services required for ASIC setup, configuration, and
operation are provided in an extensive suite.
CS Communication Services
This component presents an abstracted Communications Device
which is somewhat more device independent that the CNA10 ASIC.
Most of the remainder of the food chain above communicates with
CS, which in turn communicates with CA.
CIP Support
The Control and Information Protocol (CIP) portion of the example
code provides data definitions and services for handling CIP
message. It also includes the Diagnostic Monitor object, which is
used to gain visibility into all portions of the example code for debug
purposes. The set of components that make up CIP Support are:
DM Diagnostic Monitor
MR Message Router
UM Unconnected Message Manager
DO Device Object
CM Connection Manager
RO Rack Object
DM Diagnostic Monitor
The Diagnostic Monitor component provides device independent
visibility into the example code for diagnostic and debug purposes.
It is an optional component, but it is strongly recommended that it be
included in any port of the CNEC.
MR Message Router
The Message Router component implements the functionality
defined for the CIP Message Router object.
4610
UM Unconnected Message Manager

The Unconnected Message Manager component implements the
functionality defined for the CIP UCMM object.
DO Device Object
The Device Object component implements the functionality defined
for the CIP Device Object.
CM Connection Manager
The Connection Manager component implements the functionality
defined for the CIP Connection Manager Object.
RO Rack Object
The Rack Object component emulates the behavior of a 1771 I/O
rack.
Application Program Interface (API)

The Application Program Interface portion of the example code
provide data definitions and services for the high-level interfaces
between the example code and the application code in a product.
The set of components that make up the APIs are:
AB Basic Services
AM Messaging Services
AA Adapter Services
AB Basic Services
The Basic Services API provides initialization and other basic
services for the example code.
AM Messaging Services
The Messaging Services API provides PCCC message processing
and CIP native message processing services.
AA Adapter Services
The Adapter Services API provides support for various methods of
real time data transfer.
4611
Example Application
The Example Application portion of the example code provides an
example of how an application initializes and interfaces with the
remainder of the example code. This example is useful for
debugging and examination of the CNEC. The set of components
that make up the Applications portion of the example code is:
EA Example Application
PC PC Specific Support Utilities
PD PC Display Services (Multitasked)
TS Test Script Processor
DC Data Coordinator
EA Example Application
This is the main for the DOS example application.
PC PC Specific Support Utilities
Isolates all support routines that touch PC hardware or firmware.
Does not include display routines.
PD PC Display Routines
Provides multitasked version of PC display routines.
TS Test Script Processor
This component contains a tiny command line interpreter that can be
used to interactively exercise the CNEC.
DC Data Coordinator
This component isolates TS from acquisition of examined CNEC
data so that whatever commands can be executed locally can also be
executed remotely to another CNEC device on ControlNet.
4612
Porting Guide
Every effort has been made to minimize the portions of the example
code that need to be modified when porting the code to a specific
platform. The relative amount of changes required to port each
source file has been identified by simple gas gauge indications in
the header of each file as shown below:
*****************************************************
*****************************************************
**
** Source Change Indices
**
**
** Porting Changes
**
** None X Major
**
**
* Specific note 1
**
**
* Specific note 2
**
**
** Customization Changes
**
** None X Major
**
***************************************************
***************************************************
*/
The Porting Changes gas gauge indicates the amount of changes

expected to port this file to your specific product hardware. The
Customization Changes gas gauge indicates the expected changes
required to customize the operation of this file to fit your specific
application software.
Porting is best accomplished in stages:

Port to your Real Time OS (to OE interface level)
Port to your ControlNet ASIC hardware (CA interface level)
Port the remainder of the CNEC Core Code Verify with the
ControlNet Compliance test.
Port your Application code. (Provide your own specific testing).
Coding Standards
To provide a degree of consistency to the ControlNet Example Code

and make it easier to read and understand, a number of coding
standards have been adopted. While many of them may seem trivial
or overly nitpicky, when taken as a whole, they produce consistent,
easy to follow code.
Details of the coding standards are outlined in the following sections
of this document.
4613
Files
File names consist of one to eight characters followed by a dot (.)
and an extension of up to three characters. This is consistent with
the standard MSDOS 6.22 file format.
A file is named after the component module it comprises. For
example, the files containing the Diagnostic Monitor components
each retain the prefix DM as in dm_xxxx.y, where xxx is a
descriptive name and y is the file type (.h, .c, etc.).
Identifiers
The length of an identifier is limited only by the compiler. For the
current CNEC, the limit has been set at 32 characters.
The names of most identifiers are preceded by a common component
prefix. This aids in determining the component level relation of each
identifier in a file. Variables of scope limited to a single function or
code block do not require the component prefix. An underscore
character is used exclusively to separate the component prefix from
the remainder of the identifier name. The only exception is in
reference to specific compiler library identifiers (i.e., __FILE__ ).
Function Names
The name of each function in a component is preceded by a common
component prefix. This aids in determining the component level
relation of each function in a file. The remainder of the function
name is comprised of a descriptive label in verb first order. Any
words or abbreviations exhibit capitalization of the first letter as in:
DM_GetAttributesAll(). Functions that are accessed from other
components (public functions) have a name formed by the
component name prefix in upper case, followed by an underscore
then concatenated to the descriptive label. Functions that are
accessed exclusively within the component (private functions) have a
name formed by the component name prefix in lower case followed
by an underscore then concatenated to the descriptive label. This
notation provides a visual cue to the scope of the function.
4614
Variable and Member Names

A Hungarianstyle notation is utilized for variable and structure
member names. For example, to denote an integer type named
Foo you would use the notation iFoo. The notation is additive,
that is, for a pointer to an array of integers named Foo you would
use paiFoo. The following table summarizes the Hungarianstyle
notation prefixes.
Prefix
Type
array of ...
byte
ch
character
enumeration
flag
integer (16 bit)
long integer (32 bit)
integer (long or short)
pointer
structure
user defined primitive type
interrupt vector contents
dont know / dont care
Variables accessed from other components (public variables) have a

name formed by the component name prefix in upper case, followed
by an underscore then concatenated to a Hungarianstyle label for
the variable. Variables accessed exclusively within the component
(private variables) have a name formed by the component name
prefix in lower case followed by an underscore then concatenated to
the Hungarian style label. Structure members and variables of scope
limited to a single functional code block do not require a component
prefix. This notation provides a visual cue to the variables scope.
Since certain individual objects may be reset without resetting the
device, variables are not initialized at compile time.
Compiler Directives
Symbolic constants (#define) names are uppercase. For example:
#define SOMECONSTANT
0x42
All symbolic constants are defined in the appropriate header file.

An optional comment may be placed after the #endif keyword of
long conditionally compiled blocks.
4615
Typedefs
When defining structures, unions, enumerations, or other types,
braces are vertically aligned with the typedef keyword. Member
names are indented by three spaces. The identifier name will end
with the string Type and is vertically aligned with the brackets.
For example:
typedef enum
{
ONE,
TWO,
THREE,
FOUR
}
NumberType;
Static Storage Class

Static declarations are not utilized in the CNEC code except for
variables local to a function that have a lifetime greater than the
function call.
Macro Definition
The are two standard formats for defining a macro based on whether
the macro code fits on a single or multiple lines. Only one statement
is listed per line. If the code will fit on a single line, two spaces
separate the parameter list from the macro definition. If the code
requires multiple lines the format will be in the following style:
#define FooBar( x, y )
{
(x) = (y) * Foo;
(y) = Bar * ( (x) + (y) ) * (y);
}
\
\
\
\
The continuation bar (\) is located somewhere beyond the longest

line and vertically aligned. All regular spacing rules apply. If for
compilation reasons braces can not be used in a particular macro
definition, a blank line will be substituted.
4616
Format Rules
Format rules for the following are included in this section:
listing
spacing
parentheses
increment and decrement operators
branch directives
labels
braces
tabs
parameter lists
conditional blocks
code blocks
critical sections
Listing Rules
Service prototypes and functions are listed alphabetically in their
respective files. All functions possess a prototype in the header file.
For commenting purposes, service prototypes are listed in
alphalogical order in the banner comment ( see Comment Styles
below). Variable names are alphalogical using the label portion of
the name. The component prefix and Hungarian notation portions of
the name are ignored.
Spacing
Following is a list of the spacing rules:
Single space around the parameters in a macro prototypes and
calls.
Single space around the parameters in a function prototypes and
calls.
Single space around operators and variables
Single space around parameters inside square brackets
Single space before and after parenthesis except when used for
protection of macro parameters, typecasts and immediately
following a conditional keyword or function declaration. For
example:
#define FooBar( x, y ) (x) = (y);
while( foobar ) ...
(USINT*)foobar
(char*)( FooBar( x, y ) )
for( i = 1; i < ( FooBar( x, y ) * 3 ); i++ );
4617
When defining a pointer the star is placed against the type

keyword. For example:
char* pachFoo;
When dereferencing a pointer the star is placed against the

variable or function name. For example:
iBar = *pFoo;
Indentation is three spaces per level.

Lines with braces are considered to be blank for spacing
purposes.
Use a blank line to visually separate blocks of code. Two blank
lines may be utilized to separate major code blocks.
Use a blank line before and after all return, continue, goto, and
break keywords.
Use a blank line before and after conditional statement blocks
(i.e., if..else, for, do..while).
On long parameter lists, vertically align variable types and
variable names as follows:
UINT
iFoo;
FooBarType*
pFooBar;
SomeTypeWithAReallyLongName* pLongName;
Parenthesis
Parenthesis are used around all expressions within conditional
statements. This includes case expressions. A set of protective
parenthesis surrounds all parameters in macro definitions.
Parenthesis enclose expressions if there exists any chance for
multiple interpretations between compilers (or programmers!).
Order of precedence is not assumed. Vertical alignment is observed
if multiple lines are required for a parameter list.
Increment and Decrement Operators
Wherever an increment (++) or decrement () operator is used and
no value is wanted, a postfix operator format is maintained. For
example:
... code ...
pFoo++;
... code ...
Branch Directive
The goto keyword is used only in forward branches to common error
handling sequences. gotos for normal processing cases are avoided.
gotos with backward branches are not used.
Labels
Labels are left justified to provide high visibility in code listings.
4618
Braces
ALL pairs of open and close braces are vertically aligned. Braces
enclose all macro definitions unless disallowed due to compiler
restrictions. Braces may be used in situations where sections of code
require special attention (i.e. around critical sections). All code
blocks within conditional expressions are enclosed with braces even
if empty (see Conditional Blocks below).
Tabs
Production source files do not contain any tabs. An indentation of
three spaces is used.
Parameter Lists
On long parameter lists, variable types and names are vertically
aligned as follows:
UINT
iFoo;
FooBarType*
pFooBar;
SomeTypeWithAReallyLongName*
pLongName;
Conditional Blocks
Code blocks within the context of conditional statements and loop
structures are enclosed by braces. This includes single lines of code.
Braces are aligned vertically with the conditional. Indentation is
three spaces. For example:
if( something )
{
. . . code segment . . .
}
else
{
} /* end if */
An optional comment may be placed after the closing bracket of long

conditionals. For complex evaluations that requiring multiple lines,
operators are spaced to vertically align with the appropriate level of
parenthesis in the expression. For example:
if( ( ( pUtr>iTransRecNo & CN_UCMM_TRANS_REC_MASK ) ==
( iTransRecNo & CN_UCMM_TRANS_REC_MASK ) ) &&
( pUtr>bSrc == bSrc ) )
{
} /* end if */
4619
Code blocks
Blank lines are used to separate functional blocks of code. Two
blank lines may be used to visually separate major code blocks.
Critical Sections
Code that resides within a critical section is enclosed in braces. The
braces are vertically aligned with the OE_EnterCritical() and
OE_ExitCritical() services which define a critical section. A blank
line immediately precedes and follows the critical section block to
visually separate it in the code.
example code . . .
OE_EnterCritical();
{
. . . more code . . .
}
OE_ExitCritical();
example code . . .
An exception exists within certain conditional structures. These are

clearly noted in the code.
Comment Styles
There are a number of comment styles utilized in the CNEC. The
following list documents the use of each style.
File Banner comments
Each file is headed and terminated with a file banner comment. The
head banner provides a location for the name, description, version
and build number of the file. The termination banner marks the
absolute end of the file. The following formats are utilized.
/**************************************************
***************************************************
**
** File Name
**
**
** FooBar.C
**
***************************************************
***************************************************
**
** Description
**
**
** Description text ...
**
4620
***************************************************
***************************************************
**
** Service List
**
**
** Services NOTE: Service list section is
**
included only in the header
**
files
**
***************************************************
***************************************************
**
** Copyright Notification
**
***************************************************
***************************************************
*/
/**************************************************
***************************************************
**
** Change Log
**
**
** Log records
**
***************************************************
***************************************************
*/
. . . . . . . . . . . . Program Code . . . . . . . . .
/*************************************************
**
**
End of FooBar.C
**
***************************************************
*/
Note that the service list section is only included in header files. The
service list is arranged in an alphalogical order. The change log
section has been separated due to compiler limitations on comment
block length. In released source code, the log will only contain the
program version and revision number.
Major block comment
In major block comments, the title starts in column seven. For all
other comment types text will start in column three.
4621
/**************************************************
**
**
Title....
**
***************************************************
*/
Minor block comment

/*
**
** Title....
**
**
*/
Service prototype (.h file) comment

/*
**
** ServiceName()
**
** Description text....
**
**
**
** Inputs:
**
Input list....
**
** Outputs:
**
Output list....
**
** Usage:
**
Usage example code....
**
**
*/
Data declaration (.h file) comment

/*
**
** ServiceName()
**
** Description text....
**
**
*/
Service code (.c file) comment

/*
** ServiceName()
**
*/
4622
Note that the description and usage text for service prototypes are
located in the header (.h) file only. This is to eliminate maintaining
duplicate sets of comments in the code. End of line comments are
not used.
Code block comment
/*
** Text....
*/
Function Block comment

Comment line on closing brace of functions
} /* end of XX_FooBar() */
Conditional Block comment

For lengthy conditional blocks include a comment line on the closing
brace. Blocks consisting of a few lines need not be commented.
This is an aid to readability.
if( condition )
{
... code ...
} /* end if */
for( condition )
{
... code ...
} /* end for */
Chapter
47

This chapter explains how to port the ControlNet Example Code
(CNEC) to a target real-time operating system (RTOS). The CNEC
requires an RTOS in order to provide multi-tasking execution of its
individual components. The requirements of the RTOS are also
identified. This chapter contains these sections:
Why An RTOS?
Section
Page
Why An RTOS?
Description Of RTOS
Detailed Requirements Of The RTOS
OE Defined Data Types
OE Defined Services
RTOS Porting Procedure
471
472
476
476
477
4714
The CNEC provides a number of communications services that

require concurrency of operations. Some examples are:
multiple outstanding transactions of a given type
multiple active communication timers
multiple channels of I/O data
Experience has shown that a singlethreaded approach to
implementing these types of services produces a very unsatisfactory
body of code that does not meet all concurrency requirements and is
extremely difficult to maintain. The current implementation of the
CNEC assumes the presence of an RTOS as the foundation upon
which all the individual CNEC services are built. The RTOS is not a
part of the CNEC and must be supplied separately by the application
developer.
472
Operating Environment (OE) Porting Guide
Description Of RTOS
The RTOS required by the CNEC must provide the capability to

execute multiple tasks at unique priorities and also to synchronize
tasks using events. All other higher-level kernel services such as
timers, memory management, intertask messaging, and so forth are
provided internally within the CNEC. These higher-level services
are implemented solely by the use of tasks and events. This
approach was selected to maximize CNEC portability. The CNEC
has been successfully ported to both commercially purchased,
fullfeatured kernels as well as homegrown minimal functionality
kernels.
RTOS Tasks
An RTOS task is a single unit of execution having a unique,
unchanging priority, assigned at the time the task was created, and
also having its own private stack area. Support for multiple tasks at
the same priority is not a requirement of the RTOS. Neither is the
capability to dynamically modify the assigned task priority during
execution. This limited scope definition of task maximizes the
range of RTOS environments to which the CNEC can be ported. The
figure below is a state transition diagram the defines task operational
behavior.
473
Figure 47.1
Task State Transition Diagram
Create
Reschedule
(not highest priority)
READY
Reschedule
(highest priority)
Set Event
Reschedule
RUNNING
Reschedule
(highest priority)
Wait Event
BLOCKED
Set Event
(highest priority)
Tasks are always in one of three states: READY, BLOCKED, or

RUNNING. At any given instant in time, there is exactly one task in
the entire RTOS environment which is in the RUNNING state. All
other tasks are either in the READY or BLOCKED state. Tasks in
the READY state are potential candidates to enter the RUNNING
state the next time the RTOS performs its reschedule operation.
Reschedule is the sequence of operations which saves the context
of the currently RUNNING task, changes the state of the RUNNING
task to READY, determines which task now has the highest priority,
changes the state of that task to RUNNING, restores the context of
the new RUNNING task, and resumes execution of the RUNNING
task. If at the time reschedule is invoked the RUNNING task has
the highest priority, then no task state transitions occur and execution
of the same task resumes.
474
When a task requires a resource that it does not have, or a

notification from some other task that something in particular has
occurred, then the task will transition from the RUNNING to the
BLOCKED state. When the notification is obtained, the task will
transition from BLOCKED to READY (or possibly back to
RUNNING). These behaviors represent the interaction of tasks with
events and are described in the next section.
RTOS Events
An RTOS event, as required by the CNEC, is a task blocking and
wakeup primitive that can block and wakeup one and only one task,
and which can independently preserve one bit of status information.
An event is always in one of three states: IDLE, PENDING, or
BLOCKED. There are two synchronization operations that can be
performed on an event: SET and WAIT (CLEAR is not a defined or
required service). All of these event state transitions are illustrated
in the figure below:
475
Figure 47.2
Event State Transition Diagram
Create
IDLE
Wait
Set
Wait
Set
PENDING
BLOCKED
Set
Wait
ERROR
When an event is first created, it is in the IDLE state. This means
that there is no task blocked on the event and the bit of status is
cleared (zero). The PENDING state represents the situation where
the event has occurred, but no task has yet seen it. The
BLOCKED state represents the situation where the event has not yet
occurred, but some task is waiting for it to occur.
476
If the SET event operation is performed and the event is in the IDLE
state, then the event transitions to the PENDING state and the status
bit is set.. If, on the other hand, the WAIT event operation is
performed from the IDLE state, the transition is to the BLOCKED
state. In this state, the status bit remains cleared, but the task which
performed the WAIT transitions from the RUNNING task state to the
BLOCKED task state. This task will remain BLOCKED until some
other task performs a SET on the same event.
Several other transitions are significant. If the event is in the
BLOCKED state and a SET event operation is performed, then the
task which was blocked on the event transitions to READY (or
possibly RUNNING) and the event state transitions back to IDLE. If
the event is in the BLOCKED state and a WAIT event operation is
performed, this represents an error since only one task is permitted to
WAIT (i.e. block) on a given event.
Finally, if the event is in the PENDING state and a WAIT event
operation is performed, the event transitions to IDLE and the task
which executed the WAIT simply continues executing in the
RUNNING state. If the event is in the PENDING state and a SET
event operation is performed, then the event remains in the
PENDING state and the condition of multiple SETs is not recorded.
Detailed Requirements Of
The RTOS
The CNEC utilizes a set of twelve services that define its interface to
the RTOS. These twelve services constitute the example code
component called Operating Environment (OE). The OE component
produces no compiled code it contains no .C files, only .H
files. The RTOS required by the CNEC must provide a set of
services that are equivalent to those defined by the public interfaces
of OE.H. A procedure for mapping the RTOS services to OE.H is
presented in the final section of this chapter.
OE Defined Data Types
The OE component defines three data types that must be mapped to

equivalent data types in the local RTOS. These data types provide
abstracted representations of Task Identifier, Task Priority, and Event
Identifier. The mapping is established by the user in the included
header file OE_LTYPE.H.
OE_PriorityType
OE_TaskType
OE_EventType
/* typedef for task priority */

/* typedef for task identifier */
/* typedef for event identifier */
OE Defined Services
477
The OE.H services are broken down into five separate groups:
OE Initialization
Creation Services
Task Control Services
Event Control Services
Interrupt Entry/Exit Services
Each of these groups contains one or more related services that must
be provided by the RTOS.
OE Initialization
There is only one RTOS service in this group and it is the service
which initializes the entire OE environment. This service returns a
status indicating whether the initialization operation succeeded.
/*
**
** OE_Init()
**
** Basic OE initialization.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
Return:
SUCCESS if everything OK
**
Nonzero error status code if
**
an error occurred.
** Usage:
**
eStatus = OE_Init();
**
**
*/
Creation Services
Two creation services must be provided: one to create tasks and
another to create events.
478
/*
**
** OE_CreateTask()
**
** Create a new task and return its task ID.
**
**
**
** Inputs:
**
pRoutine
pointer to task function
**
pParameter param to pass task function
**
pStack
pointer to task stack area
**
iStackSize Size in bytes of task stack area
**
nPrio
Task priority
**
pStatus
pointer to return status
**
** Outputs:
**
Return
ID of newly created task
**
pStatus
completion status via a pointer
**
** Usage:
**
xTask = OE_CreateTask( pRoutine,
**
pParameter,
**
pStack,
**
iStackSize,
**
nPrio
**
pStatus
**
);
**
**
*/
/*
**
** OE_CreateEvent()
**
** Create a new event.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
Return:
ID of newly created event
**
** Usage:
**
xEvent = OE_CreateEvent();
**
**
*/
479
Task Control Services

Four task control services are required in the RTOS kernel. Services
are required to enter a critical section, to exit a critical section, to
return the ID of the running task, and to explicitly execute the
reschedule sequence.
/*
**
** OE_EnterCritical()
**
** Enter a critical section.
**
** Ensure that only ONE task is inside the critical
** section at point in time.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
None
**
** Usage:
**
OE_EnterCritical();
**
**
*/
/*
**
** OE_ExitCritical()
**
** Exit a critical code section.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
None
**
** Usage:
**
OE_ExitCritical();
**
**
*/
4710
/*
**
** OE_IdentifyTask()
**
** Identifies the currently executing task.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
Return:
ID of currently executing task
**
** Usage:
**
xTaskId = OE_IdentifyTask();
**
**
*/
/*
**
** OE_Reschedule()
**
** Perform the reschedule operation.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
None
**
** Usage:
**
OE_Reschedule();
**
**
*/
Event Control Services

Events are controlled via three services: Set Event, Set Event from
inside an interrupt service routine (ISR), and Wait on a event.
4711
/*
**
** OE_SetEvent()
**
** Set the specified event. If a task is waiting on
** the event, unblock it and make it ready to run, then
** execute OE_Reschedule().
**
**
**
** Inputs:
**
xEvent
Event identifier of event to set
**
** Outputs:
**
None
**
** Usage:
**
OE_SetEvent();
**
**
*/
/*
**
** OE_SetEventIsr()
**
** Set the specified event from inside of an ISR. If
** a task is waiting on the event, unblock it and make
** it ready to run, but do not execute OE_Reschedule().
**
**
**
** Inputs:
**
xEvent
Event identifier of event to set
**
** Outputs:
**
None
**
** Usage:
**
OE_SetEventIsr();
**
**
*/
4712
/*
**
** OE_WaitEvent()
**
** Wait for the specified event. If the event is
** already set, then clear it and continue executing.
** If the event is not set, then block and wait for the
** event to be set. When the event is finally set,
** clear it and continue executing.
**
**
**
** Inputs:
**
xEvent
Event identifier for event to wait
**
** Outputs:
**
None
**
** Usage:
**
OE_WaitEvent();
**
**
*/
Interrupt Entry/Exit Services

This final set of RTOS services provides for required entry and exit
actions when executing an ISR. The two services are for entry and
exit. These services are primarily for hiding developer RTOS details
regarding ISR entry and exit.
/*
**
** OE_EnterIsr()
**
** Perform OE required entry sequence when starting
** execution of an ISR.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
None
**
** Usage:
**
OE_EnterIsr();
**
**
*/
4713
/*
**
** OE_ExitIsr()
**
** Perform OE required exit sequence when completing
** execution of an ISR.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
None
**
** Usage:
**
OE_ExitIsr();
**
**
*/
4714
RTOS Porting Procedure
In order to port the CNEC to a given RTOS, the developer must

provide a customized version of the two interface files
OE_LTYPE.H and OE_LSERV.H. The OE_LTYPE.H file maps the
developers RTOS data types into the three standard data types of the
OE.H. The OE.H cannot presume any particular mapping although
defaults to unsigned short integer and an enumeration type are
provided.
The developer must also provide #define macros in the
OE_LSERV.H to map the twelve OE services to equivalents in the
developers RTOS. These files are then used to modify the behavior
of OE.H by nested inclusion.
The figure below illustrates the inclusion order and relationship
between the three include files OE.H, OE_LTYPE.H, and
OE_LSERV.H.
4715
Figure 47.3
Structure and Content of OE.H
#include oe_ltype.h
User Redefined
OE Data Types
OE Data Type
Definitions
Data Types
Defined by OE
#include oe_lserv.h
OE Services
Definitions
User Redefined
OE Services
Services Defined
by OE
4716
Notes:
Chapter
48

This chapter explains the Basic Services API (AB) component of the
ControlNet Example Code (CNEC). This component provides for
compiletime configuration of the CNEC as well as runtime
initialization of the CNEC. This chapter contains these sections:
AB Component Files
Section
Page
AB Component Files
481
AB Component Services
482
Five files make up the entire AB component:

AB_OPTS.H
compile time options
AB_STAT.H
error status enumeration
AB_TRRBL.H
tribble request response codes
AB_INIT.C
primary initialization module
AB_SETUP.C
secondary initialization module
482
API for Basic Services (AB)
AB Component Services
The AB component isolates the application developer from the

details of the key initialization steps required to launch and run the
CNEC. Two services are provided in the AB component. These
services are discussed below:
/*
**
** AB_Init()
**
** Perform CNEC initialization. Return completion
** status indicating if successful.
**
**
**
** Inputs:
**
None
**
** Outputs:
**
Returns
Completion Status.
**
** Usage:
**
eStatus = AB_Init();
**
**
*/
/*
**
** AB_SetMacId()
**
** Set MAC ID of the device hosting the CNEC.
** Return completion status indicating if successful.
**
**
**
** Inputs:
**
MacId
The MAC ID to set in the device.
**
** Outputs:
**
Returns
Completion status (zero means OK).
**
** Usage:
**
eStatus = AB_SetMacId( iMacId );
**
**
*/
Chapter
49
The ControlNet Example Code

AM API
This chapter defines the AM (API Messaging) Application Program
Interface (API) for accessing PCCC services using the ControlNet
ASIC in conjunction with the ControlNet Example Code (CNEC).
About The AM API
Section
Page
About The AM API
491
AM API Service Definitions
493
PCCC API Design Detail Description
4910
AM API Header Files
4912
The AM API will be required by developers of ControlNet

ASIC-based products that need backward-compatible messaging
communications to existing products such as PLC5 processors and
software tools running on Data Highway Plus. This API is
subdivided into two classes or levels of service:
AM Server Provides PCCC Object functionality (the PCCC
Object generates PCCC responses)
AM Client Provides ControlNet ASIC services for PCCC
Clients (not currently defined)
The API services defined here are provided as a ControlNet ASIC
Software Package. They are built upon the foundation services
that are present in the CNEC. The CNEC is a separate Software
Package that is a prerequisite for execution of the AM API Software
Package.
Figure 49.1
ControlNet ASIC Software Packages
AM
API
OTHER
API
OTHER
API
ControlNet Example Code (CNEC)

RealTime Multitasking Kernel
492
The ControlNet Example Code AM API
Several different APIs are defined for ControlNet ASIC products in

order to effectively support a broad range of expected applications.
All of the APIs depend upon the foundation services that are present
in the ControlNet Example Code (CNEC). The AM API is a
messaging only interface intended to provide backward compatibility
with existing AllenBradley products.
What is supported by this API?

The current AM API supports server PCCC messaging which is
addressed using ControlNet Native messaging. This allows PCCC
responses to be returned to PCCC clients that have sent PCCC
requests to a ControlNet ASIC based module. The PCCC commands
that are supported by the AM API are as follows:
PLC2 Unprotected Typed Read
PLC2 Unprotected Typed Write
PLC5 Typed Read
PLC5 Typed Write
ID Host and Status
What is not supported by this API?

Future versions of this specification may define services that support
client PCCC messaging. The currently defined support is for PCCC
server only.
Also, the current PCCC API for the ControlNet ASIC DOES NOT
support Data Highway (DH) or Data Highway Plus (DH+) routing
over ControlNet. For instance, a device resident on the DH+
network cannot send PCCC traffic through a bridge (or a PLC
processor) to a ControlNet ASIC. Conversely, a ControlNet ASIC
cannot direct encapsulated PCCC traffic out onto a DH+ subnet. All
PCCC traffic coming from or going to a ControlNet ASIC must be
addressed using ControlNet native messaging. Various
encapsulation formats currently in use to support ControlNet
nonnative messaging (such as DH+ onto ControlNet) will not be
supported.
493
Other Requirements
The CNEC requires a RealTime Multitasking Kernel (RTMK) in
order to efficiently sequence and coordinate the various lowlevel
functions that it must carry out concurrently. The CNEC contains a
primary interface file called OE.H which defines the interface and
services required from the RTMK. A ControlNet ASIC application
developer may either purchase a commercially available
offtheshelf RTMK or use (and adapt) the one that is provided as
unsupported example code along with the CNEC.
AM API Service Definitions
CNEC Preliminaries
The AM API uses several basic data structures that are defined in
the CNEC. These must be understood by the user since the public
interfaces of the AM API include references to these data structures.
The AM API also references several services that are available in the
CNEC. These must also be understood by the user so that a
compliant implementation can be developed.
CS_ComBufType Data Type
All messaging services in the CNEC utilize a fundamental data type
called the CB_ComBufType:
This:
Is:
CB_
the component of the example code where the

definition is contained. The prefix CB stands for
Communication Buffer. An example code
component is a collection of related source files that
compose one identifiable group of services
ComBuf
Communication Buffer. The common name for

CB_ComBufType is just combuf. All messaging
services in the CNEC are based on a combuf
representation of messages to be received or sent.
Type
used for all datatype definitions that have public

scope outside of the component in which they are
defined.
The CB_ComBufType is defined in the include file CB.H which is

part of the CB component of the CNEC. The format of a combuf
header is illustrated in Figure 49.2.
494
Figure 49.2
Combuf Header DataType
typedef struct
{
USINT* pData;
UINT iReqSize;
UINT iBufSize;
UINT iDataSize
/* Pointer to current front of

data packet */
/* Requested allocation size */
/* Total capacity of attached packet
buffer */
/* Size of packet data currently in
buffer */
}
CB_ComBufType;
Some parts of the AM API are defined in terms of combufs.

A combuf consists of both a header and an attached packet buffer.
The actual space for the packet buffer is contiguously allocated
following the combuf header at the time the combuf is created:
The field iReqSize is the requested allocation size.
The field iDataSize is the size of the packet data currently in the
buffer.
The field iBufSize is the allocated size in bytes of the
contiguously allocated packet buffer.
The field pData is a working pointer that points, at any given
time, to the front of the packet that is resident in the buffer.
When a new combuf is allocated by a call to CB_NewComBuf(),
the pData field is set pointing to the byte past the end of the
packet buffer area and iDataSize is set to zero. This indicates that
there is no packet data in the buffer.
Normally, when layered communication protocols are processed in
the context of a communication stack, headers are prepended at the
front of each existing packet by the next succeeding layer of the
stack. In the combuf representation of this type of packet data,
before each new header is prepended, the pData field is adjusted
backward (towards the beginning of the structure). In this way, no
layer needs to physically slide the packet data around in memory
as a communications stack is traversed.
While traversing down a communications stack, as each new header
segment is prepended, the value of iDataSize is incremented to
reflect the new packet data length and the value of pData is normally
adjusted (to a lower address) to point to the front of the new header
segment. Conversely, when traversing back up a communications
stack, as headers are stripped, the value of iDataSize is decremented
to reflect the new packet data length and pData is adjusted upward in
memory. The value of iBufSize is always invariant over the lifetime
of the combuf. The amount of free buffer space available in the
combuf at any instant in time is always the difference:
495
free space = iBufSize iDataSize

The amount of free space available for prepending of headers is
called the front space and it is calculated by the difference:
front space = pData &BufferArea
The front space can be maximized by removing the free tail space
and adding it to the front space. This can be done with the function
CB_NormalizeComBuf(), where it is passed a combuf, the tail space
is removed, the active data is moved to the end of the buffer, and the
combuf data pointer is adjusted.
Figure 49.3
ComBuf Illustration
iBufSize
pData
pData
Free
Front
Space
iReqSize iBufSize iDataSize
Buffered Data
Free
Tail
Space
Task/Queue Object Model (TQOM)

In the CNEC, and its various APIs, a simple paradigm is followed
for the implementation of Objects which maximizes the utility of
having an RTMK executing underneath everything. Each instance of
an object is initiated as an executable task with an associated
message queue for reception of object service requests.
This implementation of objects is called the Task/Queue Object
Model, or simply the TQOM.
496
AM Server (i.e., AM Object)

AM Server API Requirements
The AM Server API enables ControlNet ASIC based devices to
receive, execute, and respond to PCCC requests embedded in
ControlNet Packets. ControlNet ASIC based devices must contain a
AM (Server) Object to execute the PCCC requests and generate the
PCCC responses. The AM Server API exists as a task called
AM_PcccObjectTask() which exists in the file AM_Pccc.c. This task
is called from the file PJ_Init.c with no passed parameters and
nothing is returned. As AM_PcccObjectTask() receives requests, it is
woken up from an idle state (blocked on its request queue) so that
it may process the incoming requests. As it generates responses, it
passes them back to the original requester objects via their dedicated
object service request queues. When the object has processed all
outstanding object service requests, it simply goes back to sleep
again.
AM Server API Support
The AM Server API support consists of a PCCC parsing and
execution function AM_ExecutePccc() which is defined in
AM_Appl.c. This function will be invoked by the AM (Server)
Object each time an Execute PCCC service is request is received
by the AM Object. The actual support for execution of individual
PCCC requests is performed by the C function provided by the
application for the AM Object to invoke each time an encapsulated
PCCC message is received by the object.
Figure 49.4
AM Server Object
AM
API
Server
Object
Internals
Application
PCCC
Processing
Function
497
The services provided by the AM Server Object are:

Dequeue next PCCC Request Message (block task on PCCC
Request Queue if none available)
Deencapsulate the next PCCC Request Message (including
offlink header if present)
Invoke the Application supplied PCCC processing function and
wait for control to be returned
If Response was nonnull, then perform PCCC Response
Message Encapsulation
Queue the PCCC Response Message in the response queue
indicated in the tribble.
The overall behavior of the AM Server Object has already been
defined in the AM Object definition, and the object currently exists
in other products. The class specific service that is accepted by the
ControlNet ASIC supported AM Object is class code 0x4B which is
Execute PCCC.
498
Figure 49.5
AM Server Object Main Loop
DeQueue next
PCCC Request
Deencapsulate
PCCC Request
Process PCCC
Request (AM_Appl.c)
If Response, then
Encapsulate
Queue tribble
back to Requestor
Tribbles for InterTask Object Communication

The PCCC (Server) Object, as do all other objects in the ControlNet
ASIC example code, uses tribbles for intertask communication.
Tribbles are Task Request Response Blocks, which are a control
structure that contains Request, Response, and QueueID
information enabling one task to pass messages to another task using
a uniform format regardless of the format of the actual application
data being passed. Tribbles are NOT part of the visible user
interface specified by the PCCC API. They appear ONLY in the
implementation of the interface.
499
Tribbles contain six fields: Trrbl Link (forming the queue), Trrbl
Request Code, Trrbl Response Code, Trrbl Response QueueID, Trrbl
Param (a UINT), and Trrbl DataPtr. The COMBUF used for
containing PCCC Requests and Responses is attached (via pointer) to
the DataPtr field. Storage space for Tribbles is ALWAYS
allocated from (and deallocated to) the heap via GS_Malloc() and
GS_Free(). Each Trrbl consumes one 16byte heap block for storage
space (one minimum size block). Tribbles are often reused by the
server task to minimize dynamic memory management overhead. It
is perfectly possible for the lifetime of a Tribble to extend over a
number of queuing and dequeuing operations.
AM Server API Interface Definition
The AM Server API Service Interface definition consists of a single
C function prototype which represents the service provided by the
application to execute deencapsulated PCCC requests (received by
the PCCC Server Object) and generate the PCCC responses. The
function prototype is detailed below:
Figure 49.6
PCCC Server API Definition
C Function Prototype:
CS_ComBufType *AM_ExecutePCCC( CS_ComBufType *pCB );
The application provided function will be passed a pointer to a

combuf that contains a PCCC Request packet. The combuf pData
field will be pointing to the PCCC Command Code and the
iDataSize field will equal the physical length of the PCCC Request
(in bytes). The applications function must parse the PCCC Request,
execute it (by application specific code), and then build a PCCC
Response which it provides as the return value from its invocation.
The response combuf that is passed back must also have its pData
and iDataSize fields adjusted to point to the PCCC Command Code.
When control is returned to the PCCC (Server) Object, the PCCC
response will be encapsulated and transmitted. Retries, and
communication overhead, will be performed by the API and the
CNEC; the application function need only return a valid PCCC
Response. If no PCCC Response is to be sent, or if an error is
detected by the application, then the application must return a NULL
pointer. Some of the possible error conditions are:
Unsupported PCCC command
Invalid PCCC command parameters
No memory available for PCCC response combuf
4910
PCCC API Design Detail

Description
The five basic operational steps of the PCCC Server Implementation

are discussed in further detail in the subsections which follow.
DeQueue next PCCC Request

The standard service GS_TakeTrrbl() is used to get the next tribble
from the PCCC tasks Request Queue. This is a BLOCKING service
since attempts to take from an empty queue result in a blocked task.
By this method, the PCCC Object is deactivated until a PCCC
Request is received. In this way, no CPU cycles are burnt by the
PCCC Object task until there is actually a PCCC Request to be
processed.
Deencapsulate the PCCC Request

All standard ControlNet messages have a uniform header
prepended to the application data being passed over the wire. This
header is in addition to the conventional PCCC header that is
associated with every PCCC message. The process of parsing
through the ControlNet header and moving the COMBUF data
pointer to the start of the PCCC Request Message is called
Deencapsulation. This operation is very straightforward: the
ControlNet header is stripped off and saved for building a response
message. The stripped header is in the following format:
Variable
bServiceCode
bSizeMoreIOI
bClientIdSize
abClientId
Size
1 byte
1 byte
1 byte
0 .. 9 bytes
Description
IOI header service code
Size of IOI after routing
Size of the client ID
A place to save the ClientID
The header is stripped in the function AM_PcccObjectTask() which

exists in the file AM_Pccc.c. The only complication is that the
PCCC header may contain an additional subfield called the
offlink header. This additional PCCC header information is
present in PCCC packets which have crossed over from DH+ onto
ControlNet. This additional header information is stripped off and
saved in the same way. It is stored separately and is only used to
build the response header before queuing the PCCC Response
Tribble.
4911
Process the PCCC Request via the Application Function

The application is required to provide a PCCC processing function to
the AM API service code. This application function is named
CB_ComBufType*AM_ExecutePCCC( pCombuf ). It executes the
received PCCC request and returns the appropriate PCCC Response.
This function is called by the PCCC Server Object task, that is
AM_PcccObjectTask() which exists in the file AM_Pccc.c, after
deencapsulation is complete. When this function completes its
operation, it returns a pointer to a COMBUF containing the PCCC
Response message to be sent back to the original requester. Control
is returned to the PCCC Server Object Task at that point.
The following table shows the commands that are supported by the
AM API:
Function
ID Host and Status
PLC2 Unprotected Read
PLC2 Unprotected Write
PLC5 Typed Read (Logical ASCII)
PLC5 Typed Write (Logical ASCII)
Command Byte
0x06
0x01
0x08
0x06
0x06
Function Code
0x03
None
None
0x68
0x67
Each command it broken up into a separate function that exists in

AM_Appl.c. When the Object task calls AM_ExecutePccc(), a
COMBUF is passed to it, where the PCCC command and function
are extracted and the proper procedure is called. The following are a
list of the exact function calls:
am_IdentifyHostAndStatus()
am_Plc2UnprotectedRead()
am_Plc2UnprotectedWrite()
am_Plc5TypedRead()
am_Plc5TypedWrite()
Information pertaining to the functions parameter list, command list,
and passed values are defined in the header file, AM_Appl.h.
4912
Encapsulate the PCCC Response

If the COMBUF pointer passed back by AM_ExecutePCCC(
pCombuf ) is NULL, then no encapsulation is performed and a
Tribble with NULL data pointer is returned to the requesting task.
If the COMBUF pointer returned is not NULL then the PCCC
message in the COMBUF is encapsulated. The COMBUF pointer is
reattached to the original tribble that was received in either case.
This process takes place in the function AM_PcccObjectTask() which
exists in the file AM_Pccc.c.
Variable
bClientId
bServiceCode
bSizeMoreIoi
GenStatus
ExtStatus
Size
0 .. 9 bytes
1 byte
1 byte
1 byte
1 byte
Description
Can be up to 9 bytes of data
Value is ored with 0x80 to set the response bit
Value is set to zero
Value is set to zero
Extended error status
QueuePCCC Response via Tribble

The standard service GS_PutTrrbl() is used to put the processed
tribble (with attached COMBUF) into the original requesting
tasks request queue. This service is merely a macro that remaps
(renames) GS_PutMsgQueue(). This is a NONBLOCKING service
that merely puts a message into a request queue. By this method, the
PCCC Object does not perform unnecessary context switches until it
has no further PCCC messages to process. Since the example code
OE is preemptive, if higher priority operations need to be performed
in the interim, the PCCC task will be leave the RUNNING state and
become READY. This queuing operation is the final step in the
PCCC Object task processing loop. This process takes place in the
function AM_PcccObjectTask() which exists in the file AM_Pccc.c.
AM API Header Files
The AM API consists of two header files: AM.h and AM_Appl.h.

AM.h defines all the public interfaces for the PCCC messaging
component. AM_Appl.h defines all of the private definitions
pertaining to AM_Appl.c, which is the application program.
AM.h
AM.h defines all the public interfaces for the PCCC messaging
component. It can be broken down into four different sections:
constants, data types, globals, and public services.
4913
Constants
AM.h contains many different constants (#defines) that are used
throughout the AM API. One group of constants include all PCCC
messaging commands and functions. Another group of constants
include header and buffer sizes of data packets. There is another
section of constants which are bit flags defined in hexadecimal to
help in the decoding of addresses and data types. Another section of
constants define the status codes of possible error responses. Finally,
a group of defines exists for general use throughout the API.
Data Types
There are two data types that are defined in AM.h: AM_AddrType
and AM_PcccHeaderType. The data type AM_AddrType is used to
store the file number, element number, and the status for the
decoding of PCCC message addresses. AM_PcccHeaderType is
used to hold the main portion of the PCCC command header.
Globals
The AM.h header file consists of two groups of variable definitions.
The first group consists of any areas of memory that the user wants
to be mapped into files for the typed read and typed write functions.
These are array definition prototypes and are dimensioned to the
desired size, which are defined in PJ_Opts.h. They are declared as
externs because these arrays are defined privately in AM_Appl.c.
The other variable definition is AM_xQid which is used for the
PCCC object task request queue. It too is declared as an extern and
is defined in AM_Pccc.c.
Public Services
There are three public service functions that are prototyped in AM.h.
The first function prototype is as follows:
USINT* AM_DecodeAddress( USINT* pMsg,
AM_AddrType* pAddr )
It is used to process the PLC5 address in the request message. It is
passed a pointer to the characters to process and a pointer to where
the decoded address should reside. A pointer to the processed
characters is returned.
The second function prototype is as follows:
CB_ComBufType* AM_ExecutePccc(
CB_ComBufType* pCommand
)
4914
This is a routine to actually execute the deencapsulated PCCC

command. It is passed a pointer to a combuf containing a PCCC
command. A pointer to a combuf containing a PCCC response is
returned, or NULL if there is no response to the PCCC command.
The last function prototype is as follows:
void AM_PcccObjectTask( void )
It is a task which receives object requests, generates a response, and
passes the response back to the original requester object. When there
are no objects to process, this task remains idle.
AM_Appl.h
AM_Appl.h defines all of the private definitions pertaining to
AM_Appl.c, which is the application program. It contains only one
section, which is the private services section. The AM_Appl.h
contains eight services, all of which are called from AM_Appl.c, and
are defined as follows.
void am_EchoCommand( CB_ComBufType* pComBuf,
AM_PcccHeaderType* psPcccHeader )
This command executes the PLC5 echo command. It exists in the
code for test purposes. It is passed a pointer to a combuf and a
pointer to the PCCC header structure.
void am_IdentifyHostAndStatus( CB_ComBufType* pComBuf,
AM_PcccHeaderType*
psPcccHeader )
This command executes the PLC5 identify host and status command.
It is passed a pointer to a combuf and a pointer to the PCCC header
structure. This command reads status information about the
processor. The first byte is the operating status. The second byte is
the processor and interface type. The third byte through the end of
the response block is processor and interface module dependent. The
values in the first byte are also processor and interface dependent.
void am_Plc2UnprotectedRead( CB_ComBufType* pComBuf,
AM_PcccHeaderType*
psPcccHeader )
4915
This command executes the PLC2 unprotected read command. It is

passed a pointer to a combuf and a pointer to the PCCC header
structure. This command reads words of data from any area of the
PC data table memory. When the PLC2 unprotected read packet is
received, the PCCC header information is stripped, then following
the header information are two bytes for the PLC2 address to read
from, low byte first. This is followed by a one byte data field which
contains the number of bytes to read.
void am_Plc2UnprotectedWrite( CB_ComBufType* pComBuf,
AM_PcccHeaderType*
psPcccHeader )
This command executes the PLC2 unprotected write command. It is
structure. This command writes words of data into any area of the
PC data table memory. Any protection mechanism is ignored. When
the PLC2 unprotected write packet is received, the PCCC header
information is stripped, then following the header information are
two bytes for the PLC2 address to write to, low byte first. This is
followed by up to 121 words of data, low byte first. The number of
words written are determined by the length of the command block.
void am_Plc5TypedRead( CB_ComBufType* pComBuf,
This command executes the typed read command. It is passed a
pointer to a combuf and a pointer to the PCCC header structure.
This command will read data from the processor starting at the
system address plus the packet offset.
void am_Plc5TypedWrite( CB_ComBufType* pComBuf,
This command executes the PLC5 typed write command. It is
structure. This command will write data into the processor starting
at the system address plus the offset.
void am_PrependPcccReplyHeader( CB_ComBufType* pComBuf,
AM_PcccHeaderType* pH )
This command prepends a PCCC reply header to a packet. It is
passed a pointer to a combuf and a pointer to the PCCC header data
type. The header information contains the PCCC command byte, the
status byte, and the transaction low and high bytes.
void am_UnsupportedCommand( CB_ComBufType* pComBuf,
AM_PcccHeaderType*
psPcccHeader )
4916
This command executes the PLC5 unsupported command. It is

structure. A header is prepended onto the message and the status
field is set with the unsupported command error.
Example of Reading File Data

Declaring Array Storage
If a user wanted to reserve an area of memory for a set of parameter
values, the user would have to declare an array to reserve this
memory. This should be prototyped in AM.h as the following:
extern UINT AM_aiFile7[ AM_MAX_FILE_7 ];
Where extern allows the array to be accessed from other source

files. UINT means AM_aiFile7 is an array of bytes. The array
name AM_aiFile7 is used so that when File 7 is specified, it will
refer to the parameter value data. The actual array is defined in
AM_Appl.c as the following:
/* Public Globals */
UINT AM_aiFile7[ AM_MAX_FILE_7 ];
AM_MAX_FILE_7 is defined in PJ_Opts.h and can be dimensioned

to the size desired by the user.
Accessing the Data
In order to access the data via a Typed Read, the file number,
element number, and size must be specified in the command. For
instance, if using the logical ASCII addressing mode, the address
$N7:10 would refer to file 7, element 10, and the size would be
specified elsewhere. The address $N7:10 can be decoded in
AM_Appl.c by the following function:
USINT* AM_DecodeAddress( USINT* pMsg,
AM_AddrType* pAddr )
A pointer to the data field in the combuf which is set to the system
address must be passed to this function along with the address of
AM_AddrType, which is the structure for the decode of the address.
The results of the decode of the address are passed back in the
structure. Thus if the following call is made:
pMsg = AM_DecodeAddress( pMsg, &sAddr );
where pMsg points to the system address, and sAddr is of type

AM_AddrType, the following values would be returned.
4917
sAddr.iFileNumber = 7
sAddr.iElementNumber = 10
With this, the file number can be used in a switch statement to select
the desired array, and the element number can be used to select the
exact index of the array. The size value is also specified to
determine how many words to read in. The following program code
shows a read of data:
/* Decode address of where to read */
pMsg = AM_DecodeAddress( pMsg, &sAddr );
/* Read in Size, low byte first into a word */
iWordCount = UC_iLeTOi( *(UINT*)pMsg );
switch( sAddr.iFileNumber )
{
case( AM_FILE_7 ):
pData = (UINT*)( &AM_aiFile7[sAddr.iElementNumber]);
break;
/* Insert other case statements for other files */
}
/* Take data pointer and place values on response
header for the number of words specified */
while( iWordCount )
{
iWord
= *pData++;
*pMsg++ = (USINT)( iWord );
*pMsg++ = (USINT)( iWord >> 8 );
}
4918
Notes:
Chapter
50

This chapter provides examples of a number of ControlNet packets

that are generated by common operations. The operations that
generate the packets are given followed by a reasonably detailed
description of the packet(s) generated by the operation. The intent of
these example packets are to provide a quick verification of a port of
the ControlNet Example Code (CNEC). It is by no means intended
as an exhaustive test of the port for full operation or compliance.
The packets shown in this chapter are:
Net and Port Parameter update to the ControlNet Object
Get_Attribute request / reply from the Device Object
Get_Attribute request / reply from the Rack Object
Forward Open request / reply to the Message Router Object
Message and reply from the Message Router
Forward Close request / reply to the Message Router Object
Forward Open request / reply to the Rack Object
RealTime data to / from the Rack Object
Forward Close request / reply to the Rack Object
The setup operations given for each group of packets are assumed to
be executed in the order given in this document. They assume the
test network is in the state left by the previous packet capture
operation.
502
Example Packets
Test Network
The network setup used for generating and capturing the example
packets consists of a PLC5/XXC, a PC containing a KTC card to
run 6200 software, a PC running the ControlNet Traffic Analyzer
(TA), and the device running the ControlNet Example Code that is
being tested. The test system is shown below:
ControlNet
PC Running 6200
Node X
PC Running TA
Node X
PLC5/XXC
Node 1
Device Running CNEC

Node 2
Example Packets
503
Net and Port Parameter Updates

To capture the net and port parameter update packets, perform the
following sequence of operations:
Set up one Traffic Analyzer filter to collect:
From MAC ID 1, Tag 0x83 0x02
Start running the TA
Wait approximately two minutes
Stop the TA
Among other packets captured by the TA, the following one should
be found:
Table 50.A
Net/Port attribute update: Request
Data (hex)
14
General
Detail
ControlNet header
Size
01
Control
83 02
04
Tag
UCMM header
00
Timeout
00 00
10
UCMM Datagram
Transaction ID & Sequence Number
IOI
03
Service code (Set attribute single)

IOI size
20 65
Class (ControlNet Object)
24 01
Instance (1)
30 80
F4 01 08 10
1C 06 08 08
02 00 FF 10
00 00 00 00
8A 52 71 48
07 00 00 00
Attribute (Net attributes)

Attribute Data
504
Example Packets
Get_Attribute request/ reply to/ from the Device Object

To capture the Get_Attribute request and reply packets to / from the
Device Object, perform the following sequence of operations:
Set up two Traffic Analyzer filters to collect:
Go to the Who Active screen in 6200
When node 2 appears on the Who Active screen, stop the TA
Among other packets captured by the TA, the following four should
be found:
Table 50.B
Device Object Get_Attribute: Request
Data (hex)
07
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
0A
Timeout
XX XX
01
Code (Request)
IOI
02

IOI size
20 01
Class (Device Object)
24 01
Instance (1)
Table 50.C
Device Object Get_Attribute: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
XX XX
Code (Request ACK)

Timeout
Example Packets
505
Table 50.D
Device Object Get_Attribute: Reply
Data (hex)
1E
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
Timeout
XX XX
81
Code (Reply)
IOI
00
00
General status
00
01 00

Electronic Key
Vendor ID (Allen Bradley = 01)
0C 00
Product type (1771 Rack)
18 00
Product code (1771 Rack)
01
01
00 00
XX XX XX XX

Device Object
Status
attributes
Serial number
09
Product name length
31 37 37 31
2d 41 43 4E
52 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
Product name in ASCII (1771ACNR)
Table 50.E
Device Object Get_Attribute: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 02
05
Tag
UCMM header
00
XX XX
Code (Reply ACK)

Timeout
506
Example Packets
Get_Attribute request / reply to / from the Rack Object

To capture the Get_Attribute request and reply packets to / from the
Rack Object, perform the following sequence of operations:
In 6200, execute an Auto Net
Stop the TA
be found:
Table 50.F
Rack Object Get_Attribute: Request
Data (hex)
07
General
Detail
ControlNet header
Size
01
Control
83 03
02
Tag
UCMM header
5C
Timeout
XX XX
01
Code (Request)
IOI
02

IOI size
20 7C
Class (Rack Object)
24 01
Instance (1)
Table 50.G
Rack Object Get_Attribute: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 03
05
Tag
UCMM header
00
XX XX
Code (Request ACK)

Timeout
Example Packets
507
Table 50.H
Rack Object Get_Attribute: Reply
Data (hex)
1C
General
Detail
ControlNet header
Size
05
Control
83 01
03
Tag
UCMM header
0A
Timeout
XX XX
81
Code (Reply)
IOI
00
IOI size
00
General status
00
XX XX XX XX
Size of extended status

Attribute data
Serial number
XX XX
Number of slots
XX XX
State
08 00 08 00
08 00 08 00
08 00 08 00
08 00 08 00
Slot sizes
XX XX XX XX
Input mask
Table 50.I
Rack Object Get_Attribute: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 02
05
Tag
UCMM header
00
XX XX
Code (Reply ACK)

Timeout
508
Example Packets
Forward Open Request / Reply to / from Message Router

To capture the Forward_Open request and reply packets to / from the
Message Router, perform the following sequence of operations:
In 6200, add a message rung to the ladder program running on the
PLC5
Turn the keyswitch on the PLC to RUN
Stop the TA
be found:
Table 50.J
Forward Open to Message Router: Request
Data (hex)
16
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
38
Timeout
XX XX
4C

IOI
02

IOI size
20 06
24 01
Instance (1)
01
Forward open
Priority
38
parameters
Timeout
XX XX XX XX
OT connection ID
XX XX XX XX
TO connection ID
XX XX
01 00
Vendor ID (Allen Bradley)
XX XX XX XX
D0 2B
EPR
07 47
OT connection type
07 47
TO connection type
A3
02
Code (Request)
Trigger
Connection Path
Path size
20 02
Class (Message Router)
24 01
Instance (1)
Example Packets
509
Table 50.K
Forward Open Request to Message Router: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
Code (Request ACK)

Timeout
XX XX
Table 50.L
Forward Open to Message Router: Reply
Data (hex)
10
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
Timeout
XX XX
CC
Code (Reply)
IOI
Service code (Forward open reply)
00
IOI size
00
General status
00
XX XX XX XX
Forward open
OT connection ID
XX XX XX XX
parameters
TO connection ID
XX XX
01 00
XX XX XX XX
D0 2B
EPR
00
00
Reserved
Table 50.M
Forward Open Reply to Message Router: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 02
05
Tag
UCMM header
00
XX XX
Code (Reply ACK)

Timeout
5010
Example Packets
Message to / from Message Router Object

To capture message packets to and from the Message Router Object,
perform the following sequence of operations:
Set up the TA to capture scheduled data
Start the TA
Among other packets captured by the TA, the following two should
be found:
Table 50.N
Message to Message Router
Data (hex)
XX
General
Detail
ControlNet header
Size
12
Control
XX
Tag pad
02 XX XX
XX XX
4B
Tag
Transport header
Message ID
IOI
Service code (Execute PCCC Command)
02
IOI size
20 67
Class (PCCC Object)
24 01
XX...
Instance (1)
PCCC Message
Table 50.O
Message to Message Router
Data (hex)
XX
General
Detail
ControlNet header
Size
12
Control
XX
Tag pad
01 XX XX
XX XX
CB
Tag
Transport header
Message ID
IOI
00
IOI size
00
General status
00
XX...

PCCC Reply
Example Packets
5011
Forward Close Request / Reply to / from Message Router

To capture the Forward Close request and reply packets to / from the
Message Router, perform the following sequence of operations:
Turn the keyswitch on the PLC to PROGRAM
Stop the TA
Table 50.P
Forward Close to Message Router: Request
Data (hex)
0F
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
38
Timeout
XX XX
4E
Code (Request)
IOI
02

IOI size
20 06
24 01
Instance (1)
00 00
Forward close
01 00
parameters
XX XX XX XX
02

Connection Path
00
Path size
Pad byte for alignment
20 02
Class (Message Router)
24 01
Instance (1)
Table 50.Q
Forward Close Request to Message Router: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
XX XX
Code (Request ACK)

Timeout
5012
Example Packets
Table 50.R
Forward Close to Message Router: Reply
Data (hex)
0B
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
Timeout
XX XX
CE
Code
IOI
00
IOI size
00
General status
00
XX XX
Forward close
01 00
parameters
XX XX XX XX
00
00
Reserved for data alignment
Table 50.S
Forward Close Reply to Message Router: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 05
05
Tag
UCMM header
00
XX XX
Code
Timeout
Example Packets
5013
Forward Open Request / Reply to the Rack Object

To capture the Forward_Open request and reply packets to / from the
Place PLC5 into program mode
Create a map entry in the 6200 Node Information Edit screen for
node 2 (the CNEC node)
Accept the edits in 6200
Stop the TA
5014
Example Packets
be found:
Table 50.T
Forward Open to the Rack Object: Request
Data (hex)
1E
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
38
Timeout
XX XX
4C
Code (Request)
Message ID
IOI
02

IOI size
20 06
24 01
Instance (1)
01
Forward open
Priority
38
parameters
Timeout
XX XX XX XX
OT connection ID
XX XX XX XX
TO connection ID
XX XX
01 00
XX XX XX XX
XX XX
EPR
XX XX
OT connection type
XX XX
TO connection type
01
0A
Trigger
Connection Path
Path size
20 7C
Class (Rack Object)
24 01
Instance (1)
2C 02
Connection Point (Outputs)
2C 01
Connection Point (Inputs)
80 05
Data segment
01 00
Electronic Key
0C 00
Product type (1771 Rack)
18 00
Product code (1771 Rack)
01
01
XX XX
Logical number of slots
Table 50.U
Forward Open to Rack Object: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
XX XX
Code (Request ACK)

Timeout
Example Packets
5015
Table 50.V
Forward Open to Rack Object: Reply
Data (hex)
10
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
Timeout
XX XX
CC
Code
IOI
00
IOI size
00
General status
00
XX XX XX XX
Forward open
OT connection ID
XX XX XX XX
parameters
TO connection ID
XX XX
01 00
XX XX XX XX
71 0E
EPR
00
00
Table 50.W
Forward Open to Rack Object: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 02
05
Tag
UCMM header
00
XX XX
Code
Timeout
5016
Example Packets
Realtime Data to / from the Rack Object

To capture realtime data packets to and from the Rack Object,
perform the following sequence of operations:
Set up the Traffic Analyzer filters to collect scheduled data
Stop the TA
Among other packets captured by the TA, the following two should
be found:
Table 50.X
Real time Output Data to the Rack Object
Data (hex)
XX
General
Detail
ControlNet header
Size
12
Control
XX
Tag pad
02 XX XX
XX XX
XX 00 00 00
Tag
Transport header
Message ID
Data
PLC Status
XX...
Outputs data
Table 50.Y
Real time Input Data from the Rack Object
Data (hex)
XX
General
Detail
ControlNet header
Size
52
Control
XX
Tag pad
02 XX XX
XX XX
XX 00 00 00
Tag
Transport header
Message ID
Data
Rack status
XX XX XX XX
Input mask
XX...
Inputs data
Example Packets
5017
Forward Close Request / Reply to the Rack Object

To capture the Forward Close request and reply packets to / from the
Place PLC5 into program mode
Delete the map entry in the 6200 Node Information Edit screen
for node 2 (the CNEC node)
Accept the edits in 6200
Stop the TA
be found:
Table 50.Z
Forward Close to the Rack Object: Request
Data (hex)
0F
General
Detail
ControlNet header
Size
01
Control
83 02
02
Tag
UCMM header
38
Timeout
XX XX
4E
Code (Request)
IOI
02

IOI size
20 06
24 01
Instance (1)
01
Priority
38
Timeout
XX XX
Forward close
01 00
parameters
XX XX XX XX
02

Connection Path
00
Path size
Reserved for alignment
20 02
Class (Rack Object)
24 01
Instance (1)
5018
Example Packets
Table 50.AA
Forward Close to the Rack Object: Request ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 01
01
Tag
UCMM header
00
Code (Request ACK)

Timeout
XX XX
Table 50.AB
Forward Close to the Rack Object: Reply
Data (hex)
0B
General
Detail
ControlNet header
Size
01
Control
83 01
03
Tag
UCMM header
00
Timeout
XX XX
CE
Code (Reply)
IOI
00
IOI size
00
General status
00
XX XX
Forward close
01 00
parameters
XX XX XX
00
00
Table 50.AC
Forward Close to the Rack Object: Reply ACK
Data (hex)
04
General
Detail
ControlNet header
Size
01
Control
83 02
05
Tag
UCMM header
00
XX XX
Code (Reply ACK)

Timeout
Chapter
51
CNA30F Dualport Description

Version .9
Section
Dualport Interface
Page
Dualport Interface
511
Dualport Memory Map
512
Memory Field Definitions
513
The interface between a Host processor and the ASIC is

accomplished by memory mapping the ASIC RAM into the Host
memory space. The host sees the ASIC as a linearly addressable 3K
byte address space. As shown below, this space is broken down into
a Control and Interrupt section, Configuration Section,
Network/ASIC Timer Section, UCMM messaging section, and a
Communication Services section. The specific addresses are
presented on page 512.
Figure 51.1
ControlNet CNA10 Dualport Interface
Address 0x0000
Address 0x0078
Control &
Interrupt
Section
Reserved
60 Words
4 Words
Address 0x0080
Configuration
Section
14 Words
Network/ASIC
Timer Section
1 Word
Address 0x009C
Address 0x009E
UCMM
Tx Buffer
33 Words Default
UCMM
Rx Buffer
256 Words Default
Address 0x00E0
Address 0x02E0
Communication
Services
Section
1168 Words
Address 0x0BFF
The first 6 locations of the dualport (addresses 0x0000 0x0005)

must be Byte readable and writeable. This is due to the hardware
generated interrupts that occur as a result of accessing those
locations.
512
CNA30F Dualport Description Version .9
Dualport Memory Map
The following table lists and describes dualport memory map

parameters.
Offset
Size
R/W
Name
Description
0x0000
BYTE
ASIC_Fault_Flag
Indicates the presence or lack of a fault
0x0001
BYTE
R/W
ASIC_to_HOST_Mask
Interrupt mask
0x0002
BYTE
ASIC_to_HOST_Request
Interrupt request
0x0003
BYTE
R/W
ASIC_to_HOST_Ack
Interrupt acknowledgement
0x0004
BYTE
R/W
HOST_to_ASIC_Request
Host interrupt request to ASIC
0x0005
BYTE
HOST_to_ASIC_Ack
Interrupt acknowledgement
0x0006
WORD
ASIC_Selftest
ASIC revision and selftest/runtime errors
0x0008
BYTE
ASIC_WD_Count
Watchdog register
0x0009
BYTE
HOST_WD_Count
Watchdog register
0x000A
LWORD
Start_Stop_Actual
Channel operation state indication
0x000E
LWORD
Channel_Configured
Channel configuration state indication
0x0012
LWORD
Buffer_A_ASIC
A Buffers owned by the ASIC firmware
0x0016
LWORD
Buffer_B_ASIC
B Buffers owned by the ASIC firmware
0x001A
LWORD
Buffer_A_HOST
A Buffers owned by the Host
0x001E
LWORD
Buffer_B_HOST
B Buffers owned by the Host
0x0022
LWORD
Buffer_RX_Notify
Host buffer notification configuration
0x0026
LWORD
TX_Buffer_A_Mask
A Buffers configured for transmit
0x002A
LWORD
TX_Buffer_B_Mask
B Buffers configured for transmit
0x002E
LWORD
RX_Buffer_A_Mask
A Buffers configured for receive
0x0032
LWORD
RX_Buffer_B_Mask
B Buffers configured for receive
0x0036
BYTE
Event_Queue_Write_Index
Points to the next event to be written by the firmware
0x0037
BYTE
Event_Queue_Read_Index
Next event to be read by the Host
0x0038
WORD
Event_Queue[32]
Ring queue of events
0x0078
WORD
Reserved[4]
0x0080
BYTE
Node_Address
Configuration node address
0x0081
BYTE
Config_Type
Configuration request type
0x0082
BYTE
Current_Net_Mode
Configuration current network mode
0x0083
BYTE
Config_Result
Configuration result of configuration request
0x0084
WORD
R/W
Config_Data[12]
Configuration data fields
0x009C
BYTE
Interval_Count
Current NUT interval counter
0x009D
BYTE
Comm_Timer
Communication timer interrupt counter
0x009E
WORD
UCMM_Tx_Status
Transmit status of UCMM message
0x00A0
WORD
R/W
UCMM_Tx_Buffer[UCMM_TX_SIZE]
Transmit buffer for UCMM message configurable size
0x00E0
WORD
UCMM_Rx_Source_MAC_TAG_Index
Source and TAG index of received UCMM message
0x00E20x02A0
0x01220x049E
xxxx
xxxx
xxxx
xxxx
WORD
BYTE
BYTE
WORD
BYTE
R/W
R
W
R
R
R/W
W
UCMM_Rx_Buffer[UCMM_RX_SIZE]
U
_Rx_Buffer[U
_R _SI E]
DP_Buf_Start
Rx_Channel_Buffer_Size
Rx_Channel_Buffer_Status
Rx_Channel_Buffer[CHANNEL_SIZE]
Tx_Channel_Buffer_Size
Receivee buffer for U

Recei
UCMM me
messages
age configurable size
ize
Start of channel data area
xxxx
BYTE
R/W
Tx_Channel_Buffer_Status
xxxx
WORD
R/W
Tx_Channel_Buffer[CHANNEL_SIZE]
0x029E
Channels can be located anywhere in the dualport

buffer area whose starting location must be at or beyond
the DP_Buf_Start location. The addre
address depend
depends on
the UCMM_TX_SIZE
U
_T _SI E & UCMM_RX_SIZE
U
_R _SI E
Memory Field Definitions

0x0000
513
ASIC_Fault_Flag
ASIC_Fault_Flag
ff7
ff6
ff5
ff4
ff3
ff2
ff1
ff0
The firmware provides self test results to the host CPU via the
ASIC_Selftest register in the dual port memory map. The firmware
does not execute self test at any time other than coming out of reset.
As a default out of reset, dual port reads of ASIC_Fault_Flag will be
clamped to 0xFF. The firmware will clear this condition after
completion of self test. The host can detect completion of self test
by reading something other than 0xFF from the ASIC_Fault_Flag.
If a runtime fault is detected the ASIC_Fault_Flag will change back
to 0xFF and a fault code will be placed into the ASIC_Selftest
register in dual port. (See ASIC_Selftest, on page 515.)
ASIC_to_HOST_Mask, ASIC_to_HOST_Request, and

ASIC_to_HOST_Ack
0x0001
R/W
0x0002
0x0003
R/W
ASIC_to_HOST_Mask
timer
event
config
retur
n
ucmr
x
rxrdy
txdn
ASIC_to_HOST_Request
timer
event
config
retur
n
ucmr
x
rxrdy
txdn
ASIC_to_HOST_Ack
timer
event
config
retur
n
ucmr
x
rxrdy
txdn
Reserved
Milisecond Timer expired
New Event in Event Queue
Configuration Done
Return UCMM Transmit buffer
New UCMM Message Received
Rx_Rdy (New Receive buffer ready)
Tx_Done (Done with Transmit buffer)
Pending interrupts requests are represented by the corresponding bits

in the Request and Ack registers being different. It should be noted
that even if an interrupt source is masked off, a pending interrupt
from that source will still be indicated in the ASIC_to_Host_Request
register. This will allow the host to poll for active interrupts from
masked sources if desired.
514
The basic algorithm for interrupt control (for either ASIC to Host or
Host to ASIC interrupts) is as follows:
Assume the Request and Ack registers are initially as follows:
Request
Ack
= 0001 0101
= 0001 0101
Assume a request must be made which requires the least significant

bit to generate an interrupt (farthest right).
For either side to request service from the other side, the following
steps are performed:
1. XOR the Request byte with the Ack byte and save the results.
Request
Ack
Temp reg.
= 0001 0101
= 0001 0101
= 0000 0000
2. Test the result for a 1 in the desired bit position.

3. If it is a 1, then that request is still pending from a previous
request and no further action is required.
4. If its a 0, then complement the desired bit in the Request byte
and write the value to the Request register in dual port. The write
operation will pend the request to the other side.
Request
Ack
= 0001 0100
= 0001 0101
To respond to an interrupt, the following steps are performed:

1. XOR the Request byte with the Ack byte and save the results.
Request
Ack
Temp reg.
= 0001 0100
= 0001 0101
= 0000 0001
2. XOR the results with the Ack byte and write this result to the Ack
memory location. This will acknowledge receipt of the these
requests.
Request
Ack
Temp reg.
= 0001 0100
= 0001 0100
= 0000 0001
3. Use the results to determine which services have been requested

and call the proper routine.
Temp reg.
= 0000 0001
515
HOST_to_ASIC_Request and HOST_to_ASIC_Ack

0x0004
HOST_to_ASIC_Request
abttx
notify
abts
m
config
ucmt
return
oldrx
newtx
0x0005
HOST_to_ASIC_Ack
abttx
notify
abts
m
config
ucmt
return
oldrx
newtx
Abort All Tx
Notify Register changed
Abort Station Management Request
Configuration Request
New UCMM to Transmit
Return UCMM Receive buffer
Old_Rx (Old buffer for Receive)
New_Tx (New buffer to Transmit)
Through this set of registers, the firmware is interrupted by the Host.

When the conditions shown above occur, the host will initiate an
interrupt to the firmware by forcing the corresponding bits in the
Request and Ack registers being different. The algorithm shown in
ASIC_to_HOST, on page 513, applies to the Host to ASIC
interrupts as well.
ASIC_Selftest
0x0006
0x0007
ASI _Selfte t
ASIC_Selftest
pre3
pre2
pre1
pre0
post3
post2
post1
post0
rev3
rev2
rev1
rev0
flt3
flt2
flt1
flt0
This register holds the MAC processor selftest results and the Comm
processor firmware revision and fault code. The selftest results are
broken out into preReset (pre3 pre0) and postReset (post3
post0) results. The preReset field should be ignored on initial
poweron reset. Good data is in this field only after subsequent
resets without power deasserted.
MAC Processor Fault Code Values
Selftest Error Values:
post3 post0 Description
0
1
2
3
4
5
No Error
Incorrect ROM signature
MAC RAM test failure
Streams test failure
Max packet test failure
BigMAC test failure
516
Run Time Error Values:

Description
pre3pre0
0
1
2
3
4
No Error
Weeds fault
Jabber fault
Illegal state
Remote Reset
The ASIC fault bits (flt3 flt0) indicate either a selftest or runtime
error. If the ASIC_Fault_Flag (page 513) changes to 0xFF, a
runtime fault was detected. The appropriate fault code will be
placed in the fault bits.
COMM Processor Fault Code Values
Selftest Error Values:
flt3flt0
Description
0
1
2
3
4
5
6
No Error
Incorrect ROM signature
Private RAM test failure
Screener RAM test failure
Dual Port RAM test failure
FIFO RAM test failure
Instruction set test failure
Run Time Error Values:

flt3flt0
Description
8
9
A
B
C
D
ASIC not properly jumpered

Firmware fault Bad Vector
MAC processor faulted
Screener swap timeout
MAC processor Tx timeout
Host watchdog timeout
The firmware revision will be read in the rev3 rev0 bits. This
revision will be written at powerup and will not change during the
firmwares operation.
ASIC_WD_Count and HOST_WD_Count

0x0008
ASIC_WD_Count
acnt7
acnt6
acnt5
acnt4
acnt3
acnt2
acnt1
acnt0
0x0009
HOST_WD_Count
hcnt7
hcnt6
hcnt5
hcnt4
hcnt3
hcnt2
hcnt1
hcnt0
517
The firmware supports a watchdog mechanism that allows a host to

detect when the ASIC processor is not operating properly. The ASIC
provides a mechanism that allows the host to detect a failure within
100 mSec. The ASIC also provides a mechanism that allows the
firmware to watchdog the Host and transition to a fault state if the
Host fails to write the watchdog location faster than the configured
timeout period. This timeout period is in milliseconds and is setup
using the Set_ASIC_Operating_Mode configuration command
(page 5114). The timeout value defaults to zero which disables this
function. Setting a nonzero value in HOST_WD_Count will enable
this behavior. If the value of Host_WD_Count is set to zero it will
disable the timeout function. This allows the Host to quickly enable
and disable the timeout if needed.
Two registers have been provided in the ASIC to provide this
function. One register is written by the firmware and read by the
host (ASIC_WD_Count), the other is written by the host and read by
the firmware (Host_WD_Count). These registers operate as
follows:
1. After reset, the host initializes Host_WD_Count to some
nonzero value.
2. The background task in the firmware periodically copies this
value to internal memory. The firmware has a 1 mSec timer
interrupt which, when executed, will copy the value from internal
memory to the ASIC_WD_Count .
3. Periodically, the host should read the ASIC_WD_Count and
compare it to the Host_WD_count.
If the two do not match, an internal counter is incremented. If
the count exceeds some maximum, a watchdog error is
generated.
If the two counts do match, the host clears the internal count,
and modifies the Host_WD_Count so that it is again different
from the ASIC_WD_Count.
If for some reason, the firmware goes out to lunch, step 2 never gets
performed. The host will know something is wrong and counts some
number of periods to see if the two count values ever become equal.
The nonzero values in these registers are not important. What is
important is that whenever the host makes the two registers different,
the firmware continually makes them the same within 100 mSec.
The periodic interval the host uses to poll the watchdog register and
the count used to determine a failure will be design dependent. For
example, if the host used 20 mSec as the periodic rate, and the host
counted 5 intervals while waiting for a match, it could detect a
failure within 100 mSec. This system confirms that both the
interrupt and background systems are operating in the firmware.
518
Start_Stop_Actual
0x000A
0x000B
0x000C
0x000D
Start_Stop_Actual
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
The start/stop condition of any channel can be determined at any

time by interrogating the Start_Stop_Actual Status registers. This
Status register consists of 31 bits with each bit representing one of
the channels (32nd bit is unused). A one in any bit position indicates
the channel is started. The firmware will update these registers as
part of a start or stop configuration command (refer to page 5114).
These registers are provided so that the host will not have to
maintain the channel states in its own memory.
Channel_Configured
0x000E
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
0x000F
0x0010
ch16
ch24
ch15
ch23
ch14
ch22
ch13
ch21
ch12
ch20
ch11
ch19
ch10
ch18
ch9
ch17
ch31
ch30
ch29
ch28
ch27
ch26
ch25
Channel_Configured
hannel_ onfigured
0x0011
The configuration condition of any channel can be determined at any

time by interrogating the Channel_Configured Status registers. This
Status register consists of 31 bits with each bit representing one of
the channels (32nd bit is unused). A one in any bit position indicates
the channel is configured. The firmware will update these registers
as part of a Set_Config_Channel command (refer page 5114).
These registers are provided so that the host will not have to
maintain the channel states in its own memory.
Buffer_A_ASIC and Buffer_B_ASIC

0x0012
0x0013
0x0014
0x0015
0x0016
0x0017
0x0018
0x0019
Buffer_A_ASI
Buffer_A_ASIC
Buffer_B_ASI
Buffer_B_ASIC
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
ch8
ch16
ch24
0
ch7
ch15
ch23
ch31
ch6
ch14
ch22
ch30
ch5
ch13
ch21
ch29
ch4
ch12
ch20
ch28
ch3
ch11
ch19
ch27
ch2
ch10
ch18
ch26
ch1
ch9
ch17
ch25
519
Buffer_A_Host and Buffer_B_Host

0x001A
0x001B
0x001C
0x001D
0x001E
0x001F
0x0020
Buffer_A_ OST
Buffer_A_HOST
Buffer_B_ OST
Buffer_B_HOST
0x0021
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
ch8
ch16
ch24
ch7
ch15
ch23
ch6
ch14
ch22
ch5
ch13
ch21
ch4
ch12
ch20
ch3
ch11
ch19
ch2
ch10
ch18
ch1
ch9
ch17
ch31
ch30
ch29
ch28
ch27
ch26
ch25
The Buffer_A/B_ASIC and Buffer_A/B_Host are companion

registers. Which side owns a particular buffer is determined by the
difference between the associated bits in the Buffer_A/B_ASIC and
Buffer_A/B_Host registers. When the bits are the same, the
firmware owns the buffer. When the bits are different, the host
owns the buffer.
When the firmware wishes to give a buffer to the host, it toggles the
buffer bit in the Buffer_A/B_ASIC registers and interrupts the host
by toggling either the Rx_Ready (rxrdy) or Tx_Done (txdn) bits in
the ASIC_to_HOST_Request register (page 513). When the host
wishes to give a buffer to the firmware, the host toggles the
associated buffer bit in the Buffer_A/B_Host registers and likewise
toggles either the Old_Rx (oldrx) or New_Tx (newtx) bits in the
Host_to_ASIC_Request (page 515). The actual value of a bit
carries no information; it is the difference between the corresponding
bits in the Buffer_A/B_ASIC and Buffer_A/B_Host registers that
matters.
Buffer_RX_Notify
0x0022
0x0023
0x0024
0x0025
Buffer_R _ otify
Buffer_RX_Notify
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
The Notify register is used to tell the firmware whether the host
wishes to be informed when new data arrives. The bits in this
register control channel behavior, not individual buffer behavior.
When the host is operating in the Suppressed mode for certain
channels, the notify bits for those channels are set to zero. When the
host is operating in the Notify mode, the notify bits are set to one.
When the host changes this register, the host must interrupt the
firmware to process the changes. This is accomplished by toggling
the notify interrupt bit in the HOST_to_ASIC_Request (page 515)
for triggering the firmware to process changes to the Notify registers.
5110
Tx_Buffer_A_Mask and Tx_Buffer_B_Mask

0x0026
0x0027
0x0028
0x0029
0x002A
0x002B
0x002C
0x002D
T _Buffer_A_ a
TX_Buffer_A_Mask
T _Buffer_B_ a
TX_Buffer_B_Mask
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
ch8
ch16
ch24
0
ch7
ch15
ch23
ch31
ch6
ch14
ch22
ch30
ch5
ch13
ch21
ch29
ch4
ch12
ch20
ch28
ch3
ch11
ch19
ch27
ch2
ch10
ch18
ch26
ch1
ch9
ch17
ch25
RX_Buffer_A_Mask and RX_Buffer_B_Mask

0x002E
ch8
ch7
ch6
ch5
ch4
ch3
ch2
ch1
0x002F
0x0030
0x0031
ch16
ch24
0
ch15
ch23
ch31
ch14
ch22
ch30
ch13
ch21
ch29
ch12
ch20
ch28
ch11
ch19
ch27
ch10
ch18
ch26
ch9
ch17
ch25
ch8
ch16
ch24
ch7
ch15
ch23
ch6
ch14
ch22
ch5
ch13
ch21
ch4
ch12
ch20
ch3
ch11
ch19
ch2
ch10
ch18
ch1
ch9
ch17
ch31
ch30
ch29
ch28
ch27
ch26
ch25
0x0032
0x0033
0x0034
R _Buffer_A_ a
RX_Buffer_A_Mask
R _Buffer_B_ a
RX_Buffer_B_Mask
0x0035
The Tx_Buffer_A/B_Mask and Rx_Buffer_A/B_Mask registers are

provided to allow the host to determine which buffers are receive
buffers and which are transmit buffers. These registers and their
contents are maintained by the firmware. When a channel is
configured, these registers are updated to reflect the buffer definition.
Each channel will have a 1 in either the corresponding bit position
in the Tx_Buffer_A_Mask or the Rx_Buffer_A_Mask but never
both. Likewise, a bit will be set for each channel in either the
Tx_Buffer_B_Mask or the Rx_Buffer_B_Mask but never both.
When the host gets an interrupt to process a reception, it can use the
Rx Mask registers to isolate the receive buffers for processing.
Event_Queue_Write_Index, Event_Queue_Read_Index, and

Event_Queue
addr
3
0x0036
Event_Queue_Write_Index
addr4
0x0037
Event_Queue_Read_Index
ovwr
addr4
E ent_Queue[0]
Event_Queue[0]
id4
addr
3
id3
src7
src6
src5
src4
src7
src6
src5
0x0038
0x0039
addr2
addr1
addr0
addr2
addr1
addr0
id2
id1
id0
src3
src2
src1
src0
id4
id3
id2
id1
id0
src4
src3
src2
src1
src0
...
0x0076
0x0077
E ent_Queue[31]
Event_Queue[31]
5111
Because of the variety of events, it is considerably more efficient to

post all events in the ASIC through a single mechanism. This
mechanism is a circular event queue of 32 entries. There are 4 major
sources of events that have been defined: UCMM events, Data
Channel events, Queue events, and Network events.
Entries in and out of the queue are controlled by two index registers.
The index registers consist of an input index register
(Event_Queue_Write_Index) and an output index register
(Event_Queue_Read_Index). Pending events are indicated by a
difference in these index values. When they are both equal, there are
no events to be processed in the queue.
Each event consists of a pair of entries. The first byte (lower
address) identifies the Event Number (id4 id0) and the second byte
identifies the Source (src7 src0) of the event.
For example, assume the two index registers are equal to zero.
When the firmware is ready to post a new event:
1. The event data is written into the location pointed to by the base
address plus the input index. In this case, Entry #0
2. The input index register is incremented. If the new value exceeds
31, it is reset to zero. In this case, the index equals 1.
3. The firmware informs the Host of a new event in the queue by
pending the New Event in Event Queue bit in the
ASIC_to_HOST_Request register.
When the host processes the interrupt:
1. The host reads the event data at the location pointed to by Base
address plus the output index, and processes the event. In this case,
Entry #0.
2. The output index register is incremented. If the new value
exceeds 31, it is reset to zero. In this case, the output index equals 1.
3. The host would compare the input and output index values. If
different, loop back and process another event. In this case, the two
are again equal and event processing is complete.
If the host chooses to have events scanned in the background, event
interrupts can be masked and the host can poll for an event. If
events were pending, it would loop through the procedure outlined
above until the two registers where again equal. Interrupt
acknowledge would still be necessary.
5112
If events pile up to the point where 31 events are posted and a 32nd
event occurs. The firmware will post an event overflow. It does this
by writing over the last event posted with the event overflow event.
It continues to do this until the host frees up an event location. At
this point, events will again be posted as before. When the host
reaches the overflow indication, it should consider this a fault
condition. The host recovery mechanism is a product design
decision. It is hoped that products are designed such that it is highly
improbable for this to occur as part of normal operation.
A debugging feature is included in the firmware which allows the
host to prevent Event_Queue_Overflow events by writing a value of
0x20 to the Event_Queue_Read_Index (i.e., setting the ovwr
overwrite enable bit). This will cause the firmware to write new
events over the oldest event. At that point, the host will not know
which events it has or has not processed but it will be able to see the
last 32 events posted by the firmware.
Event Source
Values (Hex)
UCMM_CHANNEL_EVENTS
DATA_CHANNEL_EVENTS
1 1F
QUEUE_EVENTS
FE
NETWORK_EVENTS
FF
Event Name
Value
(Hex)
5113
Description
EVENT_QUEUE_OVERFLOW
Reserved
OVERFLOW_EVENT
Rx no buffer available (maskable in

channel config)
OVERWRITE_EVENT
Rx Overwrite of good data

(maskable in channel config)
RX_DATA_TOO_BIG_EVENT
Rx size larger than buffer size
INSUFFICIENT_BW_EVENT
Tx Scheduled data left at end of

assigned NUT
OFF_LINE_DUP_EVENT
Duplicate MAC address detected
OFF_LINE_ROGUE_EVENT
MAC Parameter mismatch with

network
ON_LINE_EVENT
Result of ControlNet Object

receiving a Set_MAC_Params
while in ListenOnly Mode
LONELY_EVENT
MAC processor has determined

there are no other nodes are
currently on the network
RX_DATA_TIMEOUT_EVENT
used by Class 1 Consumers
OFF_LINE_RESET_EVENT
ControlNet Object has received a

Reset_to_Listen_Only
ON_LINE_CHANGE_EVENT
ControlNet Object has received a

Sync command
UCMM_TX_BUFFER_EVENT
Host requested transmit of the

UCMM Tx buffer but it was not
owned by the Host
UCMM_RX_BUFFER_EVENT
Host signaled return of the UCMM

Rx buffer but it was not owned by
the Host
HEARTBEAT_TIMEOUT_EVENT
10
Heartbeat timeout expired
PARAMETER_ERROR_EVENT
11
MAC_ID > UMax or redundancy

configuration error
GUARDBAND_ERROR_EVENT
12
Guardband interrupt processing not

completed before start of next
guardband period
Event Queue overflow
5114
Node_Address, Config_Type, Current_Net_Mode, Config_Result,

and Config_Data
0x0080
Node_Address
0x0081
Config_Type
0x0082
Current_Net_Mode
0x0083
Config_Result
0x0084
0x0085
RW
R/W
Config_Data[0]
onfig_Data[0]
addr5
addr4
addr
3
cfg4
cfg3
cfg2
cfg1
cfg0
mod2
mod1
mod0
addr6
addr2
addr1
addr0
rslt3
rslt2
rslt1
rslt0
dat7
dat6
dat5
dat4
dat3
dat2
dat1
dat0
dat15
dat14
dat13
dat12
dat11
dat10
dat9
dat8
...
0x009A
0x009B
RW
R/W
Config_Data[11]
onfig_Data[11]
dat7
dat6
dat5
dat4
dat3
dat2
dat1
dat0
dat15
dat14
dat13
dat12
dat11
dat10
dat9
dat8
The configuration section is a 14 word field that is broken down as

shown above. This section acts as a free form configuration window
to the ASIC. Only four bytes of this section have a fixed definition:
Node_Address, Config_Type, Current_Net_Mode, and
Config_Result. The definition of the remaining bytes depends upon
the type of configuration operation being done.
The Config_Type byte defines the type of operation to be performed
and it determines the content of the data in the Config_Type
Dependent field. A summary of the Configuration Types is shown
below. The Config_Result indicates either a successful operation or
the type of error that was detected. Node_Address is used by the
Set/Get Node address operation and Current_Net_Mode indicates
when the ASIC is in Listen_Only Mode or On_Line.
Configuration Sequence
After reset, the configuration section is owned by the host. The basic
configuration operation is as follows:
If a configuration set operation is being performed:
1. The host writes the operation type to the Config_Type byte and
the appropriate configuration data into the prescribed locations.
2. The host issues a request to the ASIC to process the configuration
command by toggling the Configuration Request bit (config) in
the HOST_to_ASIC_Request register (page 515).
3. The host awaits an indication from the ASIC that the
configuration command is complete by means of the
Configuration Done bit (config) in the ASIC_to_HOST_Request
register (page 513).
4. The host interrogates the Config_Result register for possible error
code. If an error was detected, the appropriate action is taken by
the host.
5115
If a configuration get operation is being performed:

1. The host writes the operation type to the Config_Type byte
2. The host issues a request to the ASIC to process a configuration
command by toggling the Configuration Request bit (config) in
the HOST_to_ASIC_Request register (page 515).
3. The ASIC writes the requested configuration data into the
prescribed locations based on the type of operation being
requested.
4. The host awaits an indication from the ASIC that the
configuration command is complete by means of the
Configuration Done bit (config) in the ASIC_to_HOST_Request
register (page 513).
5. The host interrogates the Config_Result register for possible error
code. If no error was detected, the data is used by the host. If an
error was detected, the host takes the appropriate action.
Node_Address
After coming out of reset and self test, the ASIC will wait for the
host to provide it a MAC ID. There are two methods to choose
from: either the host can provide the MAC ID directly through the
configuration section of the dual port RAM, or it can issue a
command to have the ASIC read the MAC_ID from the MAC ID
port . This port is an 8 bit port that supports BCD or binary type
switches.
Regardless of the method chosen, the configuration process follows
the process described below. The only difference is the
Config_Command the host provides.
The ASIC will only support addresses from 1 to 99.; any other
address will be considered a configuration error.
When a Set MAC_ID from Pushwheel command is used, the ASIC
reads the MAC ID from the port and writes the value into the
Node_Address register. If the value read is invalid, an error
indication is returned in the Config_Result register. Otherwise, a
success indication is returned and the value is used by the ASIC.
The host must use either a SET_MAC_ID_FROM_PW_BCD or
SET_MAC_ID_FROM_PW_BINARY, depending upon the type of
switches used.
When a Set MAC_ID from Dual Port command is used, the host
first writes the MAC ID into the Node_Address register. If the value
written is invalid, an error indication is returned in the Config_Result
register. Otherwise, a success indication is returned and the value is
used by the ASIC.
5116
Once the MAC ID is configured, the firmware will use a very loose
set of MAC parameters that will allow it to receive messages
regardless of what is actually in use on the wire. This will enable the
firmware to obtain the correct MAC parameters from a keeper.
Config_Type and Config_Result
The following table lists the configuration types and the possible
configuration results. The Value column indicates the number to be
entered in the Config_Type register and the Configuration Result
shows the possible values returned in the Config_Result register.
The Configuration Type column shows the name of configuration
and the steps that the firmware takes to complete the configuration
request. The error code results are listed across from the firmware
step than can generate those errors. The Data Structure column
identifies a Config_Data structure associated with the request. The
structures are shown in the table in the Config_Data section below.
Value
1 (0x01)
2 (0x02)
3 (0x03)
4 (0x04)
5 (0x05)
6 (0x06)
7 (0x07)
Configuration Type
Configuration Result
SET_MAC_ID_FROM_PW_BCD
Read the Pushwheel port
Write value to dualport
Validate BCD
Convert BCD to Binary
Range check 199
Set MAC processors MAC_ID
SET_MAD_ID_FROM_PW_BINARY
Read Pushwheel port
Range check 199
SET_MAD_ID_FROM_DP
Read Binary value from dualport
Range check 199
GET_MAD_ID_FROM_PW_RAW
Read the Pushwheel port or general
purpose input port
SET_MAD_ID_FROM_DP_RAW
Read Binary value from dualport
SET_MAC_PARAMS_FROM_WIRE
(This is handled automatically and is no
longer used.)
GET_WORK_MAC_PARAMS_INTO_WINDOW
Read Working MAC_PARAMS from
MAC processor into dualport
0x00 = SUCCESS
0x0E = INVALID_MODE_FOR_COMMAND
Data
Structure
N/A
0x0C = INVALID_BCD
0x0D = INVALID_MAC_ID
0x00 = SUCCESS
N/A
0x0C = INVALID_MAC_ID
0x00 = SUCCESS
N/A
0x0C = INVALID_MAC_ID
0x00 = SUCCESS
0x0D = INVALID_MODE_FOR_COMMAND
N/A
0x00 = SUCCESS
N/A
0x02 = INVALID_CONFIG_TYPE
N/A
0x00 = SUCCESS
Value
8 (0x08)
9 (0x09)
10 (0x0A)
11 (0x0B)
12 (0x0C)
13 (0x0D)
14 (0x0E)
15 (0x0F)
16 (0x10)
17 (0x11)
Configuration Type
GET_HOLD_MAC_PARAMS_INTO_WINDOW
Read Holding MAC_PARAMS from
MAC processor into dualport
SET_MAC_PARAMS_FROM_WINDOW
Write Holding MAC_PARAMS to MAC
processor from dualport
APPLY_MAC_PARAMS
Send USE command to MAC processor
with Tminus value from dualport
RESET_TO_LISTEN_ONLY
Set MAC processor to LISTEN_ONLY mode
CLEAR_DIAGNOSTIC_COUNTERS
Send GET_AND_CLEAR_COUNTERS to
MAC processor
Copy 1st half of counters to dualport
Save 2nd half of counters
GET_CONFIG_CHANNEL
Get a channels configuration into dualport
SET_CONFIG_CHANNEL
Set a channels configuration from dualport
0x00 = SUCCESS
SET_ALL_DEFAULTS
(no longer used)
SET_PRODUCER_TAGS
set up to 4 Producer TAGs
SET_CONSUMER_TAGS
set up to 4 Consumer TAGs
18 (0x12)
START_CHANNELS
19 (0x13)
20 (0x14)
STOP_CHANNELS
GET_DIAGNOSTIC_COUNTERS_1
Send GET_COUNTERS to MAC processor
Copy 1st half of counters to dualport
Save 2nd half of counters
GET_DIAGNOSTIC_COUNTERS_2
Copy 2nd half of counters from last read
into dualport
GET_STATION_STATUS
TX_UCMM_CONFIG_NO_RESPONSE
21 (0x15)
22 (0x16)
23 (0x17)
5117
Data
Structure
1
0x00 = SUCCESS
0x00 = SUCCESS
N/A
0x00 = SUCCESS
N/A
0x00 = SUCCESS
N/A
0x00 = SUCCESS
0x00 = SUCCESS
0x01 = INVALID_CHANNEL
0x03 = CHANNEL_NOT_STOPPED
0x04 = INVALID_TRANSPORT_TYPE
0x05 = INVALID_FEATURES
0x06 = INVALID_ADDRESS
0x07 = ADDRESS_TOO_SMALL
0x08 = ADDRESS_TOO_BIG
0x09 = DUPLICATE_TAG_CONFIG
0x02 = INVALID_CONFIG_TYPE
N/A
0x00 = SUCCESS
0x00 = SUCCESS
0x09 = DUPLICATE_TAG_CONFIG
0x00 = SUCCESS
0x0A = CHANNELS_NOT_CONFIGURED
0x00 = SUCCESS
0x00 = SUCCESS
0x00 = SUCCESS
0x00 = SUCCESS
0x00 = SUCCESS
0x0B = INVALID_BUFFER_SIZE
4
4
6
3
N/A
5118
Value
Configuration Type
24 (0x18)
TX_UCMM_CONFIG_WAIT_FOR_RESPONSE
25 (0x19)
26 (0x1A)
27 (0x1B)
28 (0x1C)
SET_ASIC_OPERATING_MODE
GET_UCMM_BUFFER_SIZES
SET_UCMM_BUFFER_SIZES
MEMORY_TO_MEMORY_MOVE
0x00 = SUCCESS
0x0B = INVALID_BUFFER_SIZE
0x00 = SUCCESS
Data
Structure
N/A
8
9
9
N/A
Two additional Error codes are possible when attempting to fix a

hung configuration request. A configuration request should never
get hung except if some error event occurs (like the node going DUP
or ROGUE) while the configuration request is being processed. The
occurrence of the event should result in the firmware flushing the
buffers and reporting of the event. When the host sees the event
(page 5110), it can take appropriate action to terminate any hung
requests. However, it may also chose to issue an
Abort_Station_Management or Abort_All_Tx interrupt. If the
configuration request was hung due to some wire station
management request, it is possible for the Hosts request to then
complete normally. Otherwise, the pending request will be
terminated and an SM_FAILED error code of 16 will be returned.
Likewise, if an Abort_All_Tx request is made, the pending interrupt
will terminate with a NETWORK_FAULT error code of 15.
Current_Net_Mode
The current net mode can take on 1 of 5 possible values.
Mode: mod2 mod0
Description
000
Invalid Mode
001
Powerup Mode
010
ListenOnly Mode
011
OnLine Mode
100
Duplicate Mode
Config_Data
The following table shows the various Config_Data structures that
are used with the configuration commands listed above. The
Structure # column corresponds to the Data Structure value in the
Configuration Type table.
Structure #
Structure Name
MAC Parameters
TAGS
Station Status
Start/Stop Channels
Channel Configuration
Name
Network Update Time
Sched Max Node
Unsched Max Node
Slot Time
Blanking Time
Guardband Start
Guardband Center
Redundancy Control
Sched Max Frame
Interval Modulus
Guardband Prestart
Macro Cycle Start
Macro Cycle Length
Macro Cycle Count
Macro Cycle Multiplier
Table Unique Identifier (TUI)
ControlNet Object State
Channel Number
TAG ID
Channel Number
TAG ID
Channel Number
TAG ID
Channel Number
TAG ID
MAC Processor Version
Dirty Bits
Toggle Bits
Host Bits
Hardware Configuration
Channel State
Channels [16:1]
Channels [31:17]
Channel Select
Reserved
Transport Type
Feature Select
Buffer A Size
Buffer B Size
Buffer A Pointer
Buffer B Pointer
Producer TAG ID
Consumer TAG ID
Response Timeout
Tx NUT Number
Address
0x0084
0x0086
0x0087
0x0088
0x0089
0x008A
0x008B
0x008C
0x008D
0x008E
0x008F
0x0090
0x0091
0x0092
0x0093
0x0094
0x009A
0x0084
0x0085
0x0088
0x0089
0x008C
0x008D
0x0090
0x0091
0x0084
0x0085
0x0086
0x0087
0x0088
0x0089
0x0084
0x0086
0x0084
0x0085
0x0086
0x0087
0x0088
0x0089
0x008A
0x008C
0x008E
0x0091
0x0094
0x0096
Size
(Bytes)
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
6
2
1
3
1
3
1
3
1
3
1
1
1
1
1
1
2
2
1
1
1
1
1
1
2
2
3
3
2
2
5119
Notes
Applies only to the get
msb not used
See bit mappings below

Size is in Words
Size is in Words
5120
Structure #
Structure Name
Diagnostic Counters 1st Half
Diagnostic Counters 2nd

Half
Operating Mode
UCMM Buffers
Buffer Errors
Error Log
Good Frame Transmitted
Good Frame Received
Selected Channel Errors
Channel A Frame Errors
Channel B Frame Errors
Aborted Frames Transmitted
Highwaters
NUT Overloads
Slot Overloads
Blockages
0x0084
0x0086
0x008E
0x0091
0x0094
0x0095
0x0096
0x0097
0x0098
0x0099
0x009A
0x009B
Size
(Bytes)
2
8
3
3
1
1
1
1
1
1
1
1
NonConcurrence
0x0084
Aborted Frames Received

Lonely Counter
Duplicate Node
Noise Hits
Collisions
Moderator MAC ID
NonLowman Moderators
Mismatch
Unheard Moderator
Station Management
Commands
Unused
PreReset Fault Register
PostReset Fault Register
Pad Byte Word Alignment
Operating Mode
Host Watchdog Timeout (msec)
Timer Interrupt Rate (msec)
Tx Buffer Size
Rx Buffer Size
Rx Buffer Pointer
0x0085
0x0086
0x0087
0x0088
0x0089
0x008A
0x008B
0x008C
0x008D
1
1
1
1
1
1
1
1
1
0x008E
0x008F
0x0093
0x0094
0x0095
0x0084
0x0086
0x0088
0x0084
0x0085
0x0086
4
1
1
1
2
2
2
1
1
2
Name
Address
Notes
See bit mappings below
Size is in Words
Size is in Words
Applies only to the get
5121
Feature Select Bits

0x0087
R/W
Feature_Select
txdn
ovfl
rxdup
fast
prio1
prio0
modt
x
lonely
clkout
ovfl
pass
addit
auto
ready
red1
red0
Transmit Done Enable

Overflow/Overwrite Enable
Receive Duplicate Data Enable
Reserved Set to 0
Network Trigger Fast
Transmit Piority Unscheduled
Transmit Priority Scheduled
Reserved Set to 0
Operating Mode Bits

0x0084
Operating_Mode
Reserved Set to 1
Disable Moderator Transmit
Enable Lonely Event
Reserved Set to 0
Reserved Set to 0
Enable Clock_Out Output
Enable UCMM Overflow
Enabled ControlNet Object Passthrough
0x0085
Operating_Mode
Enabled Additional External ControlNet Services

Enabled Auto Address Dup Behavior
Reserved Set to 0
Reserved Set to 0
Reserved Set to 0
Ready Timing
Redundancy Mask Bit 1
Redundancy Mask Bit 0
5122
ASIC Redundancy Behavior

ASIC Operating_Mode
ControlNet Network Attribute Redundancy Setting
Redundancy Mask Bits
Redundant (03)
Channel A (02)
Channel B (01)
None (00)
Redundant (default) 0 0
Redundant
Channel A Only
Channel B Only
NAP Only
Single Channel A Only
01
Parameter Error
Channel A Only
Parameter Error
NAP Only
Single Channel B Only
10
Parameter Error
Parameter Error
Channel B Only
NAP Only
NAP Only
NAP Only
NAP Only
NAP Only
NAP Only
11
Ready Timing
Description
Normal Ready Dtack
Early Ready Timing
Enable Auto
Address Dup
Description
Disabled When a duplicate MAC_ID is detected, it will stay in

the DUP_Listen_Only state until the ASIC is reset. This is the
default value.
Enabled When a duplicate MAC_ID is detected, it will be able

to recover by exiting the DUP_Listen_Only state when setting
another MAC_ID for an Auto Address Node.
Enable Additional
External
ControlNet
Services
Description
Disabled If a ControlNet message is unrecognized, the

firmware returns an error condition. This is the default condition.
Enabled Any unrecognized ControlNet Object message will be

sent to the UCMM Buffer for the Host to process.
Interval_Count
0x009C
Interval_Count
cnt7
cnt6
cnt5
cnt4
cnt3
cnt2
cnt1
cnt0
This field displays the current NUT number. The firmware gets the
current value from the MAC processor at each Guardband. The
count rolls over back to 0 when the working net configuration
interval_count modulas (Macrocycle Length) is reached.
5123
Comm_Timer
0x009D
Comm_Timer
time7
time6
time5
time4
time3
time2
time1
time0
This field contains the Comm_Timer interrupt count which is

incremented by the firmware at the specified millisecond Timer
Interrupt Rate in the configuration command
Set_ASIC_Operating_Mode (see the Operating Mode structure on
page 5118). After the time reaches 255, it rolls over back to 0.
UCMM_Tx_Status
0x009E
0x009F
U
_Tx_Statu
UCMM_Tx_Status
rslt3
rslt2
rslt1
rslt0
There are cases where a transmission request cannot be process (e.g.,

the node is offline). This register indicates the results of the
transmission and should be inspected bu the host when the transmit
buffer is returned to determine if the message was successfully sent.
Note that only the upper byte of the status word is used. When the
UCMM Tx buffer is returned to the Host it indicates the results of
the transmission as follows:
Status: rslt3
rslt0
Description
0000
transaction SUCCESS, response received
0001
ASIC OFF_LINE, transaction aborted
0010
size in buffer larger than configured size
0011
UCMM buffer size change pending

(wait for size change to complete then try again)
UCMM_Tx_Buffer
0x00A0
0x00A1
RW
R/W
U
UCMM_Tx_Buffer[UCMM_TX_SIZE]
_Tx_Buffer[U
_T _SI E]
dat7
dat6
dat5
dat4
dat3
dat2
dat1
dat0
dat15
dat14
dat13
dat12
dat11
dat10
dat9
dat8
This area of the dualport is reserved for building UCMM messages

to be sent out. The UCMM_TX_SIZE range can be anywhere from
32 to 255 words with the default being set at 32 words. The size of
the buffer can be configured through the
SET_UCMM_BUFFER_SIZES configuration command (page
5114).
0X00E0*
0x00E1
U
_Rx_Source_ A _TAG_Index
src7
src6
src5
src4
src3
src2
src1
src0
tag7
tag6
tag5
tag4
tag3
tag2
tag1
tag0
5124
"
The starting address of this field depends on the UCMM_TX_SIZE

(page 512). 0x00E0 is the lowest it can be and 0x029E is the
highest starting address.
This register will show the source address and MAC TAG index of
the associated UCMM received message. These bytes are the first
two byte of UCMM messages and are inserted by the transmitting
nodes hardware. The source address (src7 src0) has a range of
099 for fixed addresses and 0255 for auto address nodes. For
UCMM messages, the MAC TAG index (tag7 tag0) will be either
an 0xF0 if the message is from the network or 0xF1 if the message is
from the NAP port.
UCMM_Rx_Buffer
0X00E2*
R/W
dat7
dat6
dat5
dat4
dat3
dat2
dat1
dat0
0x00E3
R/W
dat15
dat14
dat13
dat12
dat11
dat10
dat9
dat8
"
The starting address of this field depends on the UCMM_TX_SIZE

(page 512). 0x00E2 is the lowest it can be and 0x02A0 is the
highest starting address.
This area of the dualport is reserved for receiving UCMM messages.
The UCMM_RX_SIZE range can be anywhere from 32 to 255
words with the default being set at 255 words. The size of the buffer
can be configured through the SET_UCMM_BUFFER_SIZES
configuration command (page 5118).
Rx_Channel_Buffer
xxxx
Rx_Channel_Buffer_Size
xxxx
Rx_Channel_Buffer_Status
xxxx
RW
R/W
Rx_ hannel_Buffer[ A EL_SI E]

Rx_Channel_Buffer[CHANNEL_SIZE]
sz7
sz6
sz5
sz4
sz3
sz2
sz1
sz0
rsvd
pad
szErr
type
dat7
dat15
dat6
dat14
dat5
dat13
dat4
dat12
dat3
dat11
dat2
dat10
dat1
dat9
dat0
dat8
The receive channel buffers are located in the dualport buffer space
which can be located anywhere after the end of the
UCMM_Rx_Buffer. That address is dependent upon the configured
size of the UCMM transmit and receive buffers. With minimum Tx
and Rx sizes, the offset will be 0x0122. With default sizes it will be
0x2e0, and with maximum sizes it will be 0x49e.
5125
The Rx_Channel_Buffer_Size indicates the data size, in words, of

the received message. The status consists of the lower 3 bits with bit
4 (rsvd) reserved for firmware use. The type bit will be clear if the
buffer contains NEW data and set if the buffer contains
DUPLICATE data. The szErr bit indicates a received data size
error. When set, a message was received with an Invalid size (1 or 3
data bytes). If szErr is cleared, the size was valid. The pad bit
indicates if there is a PAD byte at the end of the buffer. When set, a
PAD byte is present.
Tx_Channel_Buffer
xxxx
Tx_Channel_Buffer_Size
sz7
sz6
sz5
sz4
sz3
sz2
sz1
sz0
xxxx
R/W
Tx_Channel_Buffer_Status
rslt3
rslt2
rslt1
rslt0
pad
type
xxxx
RW
R/W
Tx_ hannel_Buffer[ A EL_SI E]

Tx_Channel_Buffer[CHANNEL_SIZE]
dat7
dat15
dat6
dat14
dat5
dat13
dat4
dat12
dat3
dat11
dat2
dat10
dat1
dat9
dat0
dat8
The transmit channel buffers are located in the dualport buffer space
which can be located anywhere after the end of the
UCMM_Rx_Buffer. That address is dependent upon the configured
size of the UCMM transmit and receive buffers. With minimum Tx
and Rx sizes, the offset will be 0x0122. With default sizes it will be
0x2e0, and with maximum sizes it will be 0x49e.
The Tx_Channel_Buffer_Size indicates the data size, in words, of
the message to be transmitted. The status contain two bits (type and
pad) for characterizing the messaging going out and 4bits (rslt3
rslt0) of transmit status returned to the host. The type bit directs the
firmware to send the buffer as NEW or DUPLICATE data. If the
data is NEW, the type bit will be cleared. If DUPLICATE, it will be
set. The pad bit indicates if there is a PAD byte at the end of the
buffer. When set, a PAD byte is present.
"
This does not apply to Transport types 0 or 7.

When the Tx buffer is returned to the Host it indicates the results of
the transmission as follows (low nibble will remain unchanged):
Status: rslt3 rslt0
Description
0000
transaction SUCCESS, response received
0001
ASIC OFF_LINE, transaction aborted
0010
size in buffer larger than configured size
0011
timed out waiting for response
5126
Sanity Check Sequence
In order to perform a quick sanity check of the Host/ASIC dualport

interface, several quick checks can be performed.
1. Read the ASIC_Fault_Flag (0x0000) once the ASIC has
completed its selftest. The value read should be something other
than 0xFF.
2. Read the ASIC_Selftest register (0x0006) and look for a value of
0x200. The 2 is the revision number and the two 0s indicate
successful hardware and firmware selftests. A nonzero value in
the lower nibble of address 0x06 or 0x07 can indicate a selftest
failure. The represents the unknown value for the preReset
fault field that gets ignored at poweron reset. Please refer to
ASIC_Selftest on page 515 for details of the faults.
3. Write and read back any locations at or beyond 0x02E0. This is
the channel data area which must be configured by the host. Prior
to being configured, that area of memory can be freely written
and read.
Once these steps have successfully completed, the developer can be
fairly certain that the Host/ASIC dualport interface is functioning
properly.

Objects Required In All

ControlNet Networks
This appendix specifies the system objects required in all ControlNet
networks. They provide functions which are necessary to operate in
a ControlNet system. This appendix contains these sections:
Section
Page
01hex
512
02hex
5114
06hex
5118
PCCC Object
67hex
5121
Rack Object
7Chex
5125
ControlNet Object
65hex
5132
ControlNet Keeper Object
Device / Identity Object
Use the tabs to quickly

find the object you need
512
Objects Required In All ControlNet Networks

Class Code: 01hex
Used to provide identification and general information about the

module. This object is required in all ControlNet-compliant
products.
If a module must provide identification of its subsystems, use
multiple instances of this object. In these cases, use instance one to
identify the whole device, module or product. Use instances
two and greater to identify the subsystems.
Adapters provide an entry point to a collection of modules (rack).
They allow devices outside of the rack to address individual modules
in the rack to determine their identification. The adapter also
provides the CIP messaging for these modules. For example, if a
Modular Block Adapter on the ControlNet tries to provide CIP
identification of the attached modules, it must do this by allowing
devices to specify the module in the Connection Path rather than
using the multiple instance feature of the Device/Identity Object.
513
Table 51.A
Class Attributes for the Device/Identity Object
Attribute
ID
Need in
Implementation
Access
Rule
Name
Data Type
Semantics of Values
Optional*
Get
Revision
UINT

attribute.

updates that require an
increase in this value are
made, then the value of this
attribute increases by 1.
Optional
Get
Max Instance
UDINT
Maximum instance number of

an object currently created in
this class level of the device.
The largest instance number

of a created object at this
class hierarchy level.
Optional
Get
Number of
Instances
UDINT
Number of object instances

currently created at this class
level of the device.
The number of object

instances at this class
hierarchy level.
Optional
Get
Optional
attribute list
STRUCT of

attributes used in an object

attributes implemented in the
number
attributes
UINT

The number of attribute

numbers in the list.
optional
attributes
ARRAY of
UINT

numbers.
The optional attribute

numbers.
Optional
service list
STRUCT of
List of optional services used

in an object class
implementation.
A list of service codes

services implemented in the
number services
UINT

The number of service codes

in the list.
optional services
ARRAY of
UINT
List of optional service codes.
The optional service codes.
Optional
Get
Optional
Get
Maximum ID
Number Class
Attributes
UINT

device.
Optional
Get
Maximum ID
Number
Instance
Attributes
UINT

last instance attribute of the
class definition implemented
in the device.
514
Table 51.B
Instance Attributes for the Device/Identity Object
Attribute
ID
1
2
Need in
Implementation
Access Name
Rule
Required
Get
Required
Data Type
Semantics of Values
Vendor1
UINT
Identification of each vendor

by number
See Semantics Note 1
Get
Product Type1
UINT
Indication of general type of

product
Required
Get
Product Code1
UINT
Identification of a particular
product of an individual
vendor
Required
Get
Revision1
STRUCT of:
Revision of the item the

Identity Object represents
Major Revision1 USINT
Minor Revision1 USINT
Required
Get
Status
WORD
Summary status of module
Required
Get
Serial number
UDINT
Serial number of module
Required
Get
Product name
STRUCT of:
Human readable identification
Length
USINT
Length of following array (in

bytes)
Contents
array of
USINTs
minimum 0
maximum 32
Contents (characters)
Use only printable ASCII,

codes 0x20 through 0x7E,
inclusive
Use the following Instance Attributes to identify the appropriate

slave device targeted by a connection.
Vendor
Product Type
Product Code
Revision
515
Semantics
Note1 Vendor ID is 1 for Allen-Bradley. Value zero means
Unknown when returned as an attribute.
Note2 The Product Type attribute indicates the general type of this
product. Multiple vendors use the Open range of values. There is
also a vendor specific range. The Product Type is used to:
Register Assembly Object instance definitions
Provide a scope for the Product Code numbers
If the value zero is returned as an attribute, it means Generic
Device. An explanation of the Generic Device must be supplied in
the vendor documentation.
Note3 The Product Code attribute identifies a product among a
particular product type. Each vendor assigns this code to each of its
products. It should map into a catalog/bulletin number. Value zero
is reserved to mean Unassigned. If the value zero is returned as
the attribute value, it means Generic Vendor Product.
Note4 The Revision attribute, consists of Major and Minor
Revisions, identifies the revision of the item the Identity Object
represents. If the value zero is returned as an attribute, it means
Unknown. The Major and Minor attributes are sometimes called
a Series and Revision, respectively. The Major Revision attribute is
limited to 7 bits. The eighth bit is reserved and must have a default
value of zero.
516
Note5 The Status attribute provides some status that is generally

available and useful in most ControlNet products. It represents the
current status of the entire module. The value of this attribute
changes as the module state changes. The status attribute is an
ControlNet WORD, with the following bit definitions:
This bit:
Is Called:
And Is Defined As:
Owned
TRUE indicates the module (or an object

within the module) has an owner.
1
2
reserved
Configured
reserved, set to 0
4,5,6,7
State
refer to the table below1
Minor Recoverable Fault
TRUE indicates the module detected a

problem with itself, which is thought to be
recoverable. The problem did not cause
the module to go into one of the faulted
states. See Behavior section.
Minor unrecoverable Fault

problem with itself, which is thought to be
unrecoverable. The problem did not
cause the module to go into one of the
faulted states. See Behavior section.
10
Major Recoverable Fault

problem with itself, which caused the
module to go into the Other Faults
state. See Behavior section. The Health
LED should be Solid Red.
11
Major unrecoverable Fault

problem with itself, which caused the
module to go into the Major Fault state.
See Behavior section. The Health LED
should be Flashing Red.
12, 13, 14, 15
TRUE indicates the application of the

module has been configured to do
something different than the out-of-box
default. This does not include
configuration of the communications.
Used for product specific status,

independent of state. To be defined in
products Statement of Compliance.
517
Bits: 7,6,5,4
Is Defined As (corresponding state):
And Health LED shows:
0000
Self-testing (power-up)
Solid Red
0001
Non-Volatile Storage Update in progress
Flashing Red
0010
Communication Fault (lost connection)
Flashing Red
0011
Unkeyed, Awaiting Connection
Flashing Green
0100
Non-Volatile Configuration Bad
Flashing Red
0101
Major Fault (see bits 10 and 11 for fault

classification and LED states)
Minor fault is not a state change
Flashing or Solid Red
0110
Connected, Active
Solid Green
0111
Idle (program mode type)
Flashing Green
1 0 0 0 thru
1001
reserved for future company wide states
not defined
1 0 1 0 thru
1111
reserved for product specific states
to be defined in products
Statement of Compliance.
The value of the following status bits indicates the state of the
module. The event that sets the bit may also cause a state change.
Recoverable in this context implies recoverable via
communications commands.
Recoverable
Unrecoverable
Minor (no state change)
Bit 8
Bit 9
Major (state changes)
Bit 10
Bit 11
Bit 8: Minor Recoverable Fault

Bit 9: Minor Unrecoverable Fault
Bit 10: Major Recoverable Fault
Bit 11: Major Unrecoverable Fault
The events that constitute a fault (recoverable or unrecoverable) are

to be determined by the product developer. The following examples
should help to define the various types of faults:
Minor Recoverable Fault - an analog input device is sensing an
input that exceeds the configured maximum input value
Minor Unrecoverable Fault - the devices battery backed RAM
requires a battery replacement. The device will continue to
function properly until the first time power is cycled.
Major Recoverable Fault - the devices configuration is
incorrect or incomplete
Major Unrecoverable Fault - the device failed its ROM
checksum process
518
See the State Transition Diagram in Figures 51.2, 51.3, and 51.4
below:
Figure 51.2, Communication Module State Transition Diagram
for the Device/Identity Object
Figure 51.3, Controller State Transition Diagram for the
Figure 51.4, I/O Module State Transition Diagram for the
Note6 The Serial Number is a unique number for each module
produced by a vendor. Use it in conjunction with the Vendor
Number to be a unique number for the ControlNet system.
Note7 The Product Name attribute consists of length and contents.
Use only the actual number of character bytes required, with no
trailing NULL byte. The receiver of the Get_Attributes_All service
response must have enough buffer to receive a 32-character array.
The values of the USINTs in the product name string are ASCII
characters from the range 0x20 to 0x7E, inclusive.
Following is a sample Product Name format for Allen-Bradley
products:
s Catalog Number
p
a
c 1756-OB16D
e
1756-IA16I
Allen-Bradley
A-B
A-B
s Abbreviated
p Description
a
c 24VDC DIAG OUTPUT
e
120VAC ISOLATED
Common Services
The Device/Identity Object provides the following Common
Services:
Service
ervice Code
ode
Need in
Implementation
Service
ervice Name
ame
ervice
Optional
Returns the contents of the specified attribute.
Optional
Required
Reset
Invokes the Reset service for the device.
01hex
Optional
Required
Get_Attributes_All
Returns the contents of all attributes of the Identity object.
03hex
Optional
Optional
Get_Attributes_List
Gets the specified all attributes of the class or the instance
11hex
Optional
n/a
Causes the specified Class to search for and return a list of

instance IDs of existing instances of the Identity object.
Class
Instance
0Ehex
Optional*
05hex
*The Get_Attribute_Single service is REQUIRED if any class attributes are implemented.
519
Reset Service
When the Device/Identity Object receives a Reset request, it
determines if it can provide the type of reset requested
responds to the request
attempts to perform the type of reset requested
The Reset common service has the following object-specific
parameter:
Name
Type
Description of Request
Parameters
Semantics of
Values
Type
USINT
Type of Reset
See Table
below.
The parameter for the Reset common service has the following
specifications:
Value:
Type of Reset:
Emulate as closely as possible cycling power on the item the Identity Object
represents. This value is the default if this parameter is omitted.
Return as closely as possible to the factory configuration, then emulate cycling

power as closely as possible.
Name
Data Type
Description of Instance Attribute
Vendor
UINT
ID of vendor
Product Type
UINT
Product Type
Product Code
UINT
Product Code
Revisions
2 USINTs
Major, then minor revision
Status
WORD
Current state of the module
Serial number
UDINT
Serial number of module
Product Name
USINT
Length
(continued)
USINTs
name (length) byte 1 (printable ASCII)
1 Because the length of the name is not known before issuing the Get_Attributes_All service request,
allow enough memory space to store a response up to 32 characters long.
Object-specific Services
The Device/Identity Object provides no Object-specific services.
5110
Connections
The Device/Identity Object does not directly support any
connections.
Behavior
In the following State Transition Diagrams (STD), we show behavior
of the Device/Identity Object for a:
Communication Module
Controller
I/O Module
These STDs associate the state of the device with the status reported
by the Status Attribute and the state of the Health LED.
The Device/Identity Object State Transition Diagram, state number
definitions and product specific status definitions are included in the
products Statement of Compliance document.
Important:
A device may not be able to communicate in the Major

Unrecoverable Fault state. Therefore, it may not be
able to report a Major Unrecoverable Fault. It will not
process a Reset service. The only exit from a Major
Unrecoverable Fault is to cycle Power.
Communication Module Example

A Communication Module Health LED should behave according to
the following Health LED status table.
Bits 7,6,5,4 of
attribute 5
0000
The Health LED:
If:
1. goes to Solid Red
a Power On or Software reset and

stays red while conducting Module
Self-Testing.
0100
2. goes to Flashing Red
at the end of self-test, non-volatile

configuration is bad. This indicates a
user correctable fault.
0011
3. goes to Flashing Green
the static configuration is corrected, or

if it was never bad. This indicates the
Communication Module is Unkeyed
Awaiting Connection, but not yet
communicating.
0110
4. goes to Solid Green
a real-time connection is established

to/through the module or an
unconnected message is passed
through the module (Active
Connected).
5111
0101
a Major Unrecoverable Fault occurs

within any state
0001
a Non-Volatile Storage Update

request is received during any state
The Device/Identity Object State Transition Diagram (STD) for a

Communication Module contains the following events: (Refer to the
following figure.)
Figure 51.2
Communication Module State Transition Diagram for the
Non-Volatile
Storage
Update
Any State
Power-On Reset or
Software Reset
Non-Volatile Storage update

SelfTesting
1 Solid Red
Static Configuration bad

(key module functions impaired)
Passed
3 Flashing Green
Real-time connection or
unconnected message
passed through
4 Solid Green
Any State
Flashing Red
Unkeyed
Awaiting
Connection
Non-Volatile
Configuration
Bad
Flashing Red
Configuration
Corrected
Active
Connected
Major Unrecoverable
fault occurs
Major
Unrecoverable
Fault
Solid Red
Controller Example
A Controller Health LED should behave according to the following
Health LED status table.
Bits 7,6,5,4 of
attribute 5
The Health LED should:
If:
0000
1. go to Solid Red
a Power-On or Software reset and stays

red while conducting Module Self-Testing.
0101
2. go to Flashing Red
a Major Recoverable Fault is detected.

This indicates a user correctable fault.
0110
3. go to Solid Green
no fault occurred or the above major fault

is cleared and the controller is Connected
0101
4. go to Solid Red
a Major Unrecoverable Fault occurs

within any state
0001
5. go to Flashing Red
a Non-Volatile Storage Update request is

received during any state
5112
The Device/Identity Object State Transition Diagram (STD) for a

Controller contains the following events: (Refer to the following
figure.)
Figure 51.3
Controller State Transition Diagram for the Device/Identity
Object
Non-Volatile
Storage
Update
Any State
Power-On Reset
of Software Reset
Non-Volatile Storage update

SelfTesting
1 Solid Red
Passed
3 Solid Green
Flashing Red
Connected
Any State
Major Fault
Detected
Fault
Cleared
Major
Recoverable
Fault
Major Recoverable
Fault Occurs
Major unrecoverable
fault occurs
Flashing Red
Major
Unrecoverable
Fault
Solid Red
I/O Module Example

An I/O module Health LED should behave according to the
following Health LED status table.
Bits 7,6,5,4 of
Attribute 5
The Health LED:
If:
0000
a Power-On or Software reset occurs and stays red while conducting Module Self- Testing.
0001
a Non-Volatile Storage Update request is received during any state
0010
a Communication Fault occurs when communications are lost after a connection is

established
0011
the static configuration is corrected, or it was never bad (passes Self Test). This indicates
the I/O Module is Unkeyed/Idle, but not yet communicating.
0100
at the end of self-test, non-volatile (static) configuration is bad. This indicates a user
correctable fault.
0101
a Major Unrecoverable Fault occurs during any state
0110
6. goes to Solid Green
a real-time connection is established to an input only module or if an output receives

consumer data and is commanded to Run mode from either the Wait for Initial Data or
Idle/Standby state.
0111
consumer data is received by an output commanding it to Idle/Standby mode from either

the Unkeyed/Idle or Run state.
The Device/Identity Object State Transition Diagram (STD) for an

I/O module contains the following events: (Refer to the following
figures.)
5113
Figure 51.4
Single Connection I/O Module State Transition Diagram for
the Device/Identity Object
Start
Update
Non-Volatile
Storage
Update
Any State
Flashing Red
PowerOn Reset
or Software Reset
SelfTesting
(LED test 1 sec)
0 Solid Red
Static
Configuration
Corrected
Open Connection
with Correct Key
Wait for
Initial Data
Major
Major
Unrecoverable
Unrecoverable
Fault
Fault
Solid Red
Statis Configuration
bad (key module
functions impaired)
No Faults Detected
Idle Mode defaults to all OFF
3 Flashing Green
Unkeyed
Close Connection
(Wait for
Connection)
Open Connection
(glitchless)
Internal
Fault
Non-Volatile
Configuration
Fault
Flashing Red
transition state
Outputs wait first data
Open Connection
Inputs Only
6 Solid Green
Close Connection
Run
(output)
7 Flashing Green
Close Connection
Run
Run
Idle
(output)
Idle
Idle
Open Connection
2 Flashing Red
Communication
Fault
Connection
Timeout
Wait, Idle
or Run State
5114
Used to provide messaging. Routes incoming messages to the

appropriate object for execution, implementing the ControlNet
Network Connected Messaging protocol, as documented in DES #
130/001/01.
Class Code: 02hex
Table 51.C
Class Attributes for the Message Router Object
Number
Need in
Implementation
Access
Rule
Name
Data Type
Semantics of Values
Optional*
Get
Revision
UINT

updates that require an increase
in this value are made, then the
value of this attribute increases
by 1.

attribute.
Optional
Get
Optional
Get
Optional
attribute list
STRUCT of

attributes utilized in an object

specifying the optional attributes
implemented in the device for
this class.
number
attributes
UINT

The number of attribute numbers

in the list.
optional
attributes
ARRAY of
UINT

numbers.
The optional attribute numbers.
Optional
service list
STRUCT of
List of optional services utilized

in an object class
implementation.
A list of service codes specifying

the optional services
implemented in the device for
this class.
number
services
UINT

The number of service codes in

the list.
Optional
Get
Max ID
Number of
Class
Attributes
UINT

device.
The number of the last class

attribute implemented to simplify
auto determination of classs
implementation by a remote
terminal.
Optional
Get
Max ID
Number of
Instance
Attributes
UINT

last instance attribute of the class
device.
The number of the last instance

attribute implemented to simplify
auto determination of classs
implementation by a remote
terminal.
5115
Number
Need in
Implementation
Optional
Access
Rule
Name
Data Type
Semantics of Values
Get
Object_list
STRUCT of
A list of supported objects
Structure with an array of

object class codes supported
by the device
Number
UINT
Number of supported classes

in the classes array
The number of class codes in

the classes array
Classes
ARRAY of
UINT
List of supported class codes
The class codes supported by

the device
Optional
Get
Number
Available
UINT
Maximum number of
connections supported
Count of the max number of

connections supported
Optional
Get
Number active
UINT
Number of connections
currently used by system
components
Current count of the number

of connections allocated to
system communication
Optional
Get
Active
Connections
ARRAY of:
UINT
A list of the connection IDs of

the currently active
connections
Array of system connection

IDs
Common Services
The Message Router Object provides the following Common
Services:
Need in Implementation
ervice
Service
Code
ode
Class
Instance
0Ehex
Optional*
Optional*
Returns the contents

of the specified
attribute.
01hex
Optional
Optional
Get_Attributes_All
Returns the contents

of all attributes.
03hex
Optional
Optional
Get_Attributes_List
0Ahex
n/a
Optional
Multiple Command
Service
ervice Name
ame
Description of
Service
ervice
Performs multiple
commands
*The Get_Attribute_Single service is REQUIRED if any attributes are implemented.
See the DeviceNet Communication Model and Protocol for

definitions of these services.
Table 51.D
Instance Attributes for the Message Router Object
5116
At the Class level, the order of the attributes returned in the

Object/service specific reply data portion (see Volume I for
DeviceNet messaging format) of the Get_Attributes_All response is
lowest attribute to highest attribute of ALL implemented attributes
with:
Because the Message Router Object has no required Instance
attributes, the Get_Attributes_All response at the Instance level is
lowest attribute to highest attribute of ALL implemented attributes.
No settable attributes exist on either the Class or Instance level for
the Message Router Object.
Object-specific Services
The Message Router Object provides no object specific services.
Message Router Connections

Name
Number
Messaging
Messaging application protocol
Table 51.E
Structure of Input Data for the Messaging Connection
Data Name
Data Type
Description of Data
Message
Request
STRUCT of
Data
A message request in the messaging

protocol format.
Semantics
of Values
Table 51.F
Structure of Output Data for the Messaging Connection
Data Name
Data Type
Description of Data
message
response
STRUCT of
Data
A message response formatted in the

messaging protocol format.
Semantics
of Values
5117
Behavior
Service Request
Interpretation of the Class Instance is performed on every service
received by the Message Router.
Any Class Instance that cannot be interpreted by a devices
implementation of a Message Router will report the
Object_Not_Found error.
The service is then routed to an application object. The information
routed to an application object must include the following:
the service code of the message
a pointer to the next byte to access in the message
the number of bytes left to process in the message
a device specific identification of the message source or
Connection ID for the response
If no Class Instance specification is supplied or if the message
specifies the Message Router Object itself, the service is processed
by the Message Router.
Service Response
All service responses are routed to the source of the service request.
The source could be one of the following:
the Unconnected Message Manager
an active connection to the Message Router Object
This requires the service request sources to supply a unique
identifier. This identifier is device- and implementation-specific and
simplifies implementation of the Message Router in any given
application.
Important:
The message router has only one state. That state is an

Active state in which all of the above behavior is
performed.
The Message Router Object performs the following functions:

interprets the Class Instance specified in a message
routes a service to the specified object
interprets services directed to it
routes a response to the correct service source
5118
Connection Manager
Object
Used to manage the establishment and maintenance of

communication connections.
Table 51.G
Class Attributes for the Connection Manager Object
Class Code: 06hex

Need in
Implementation
Access
Rule
Name
Data Type
Optional
Get
Revision
UINT
Optional
Spec
Max Instance
UDINT
Number
Semantics of Values
Table 51.H
Instance Attributes for the Connection Manager Object
Number
Need in
Implementation
Access
Rule
Name
Type
Optional
Set
OpenReqs
UINT
Number of Open Requests

received including Null Open
Requests.
Optional
Set
OpenFormat
Rejects
UINT
Number of open requests rejected by this node due to format

errors
Optional
Set
OpenResource
Rejects
UINT
Number of open requests rejected by this node
Optional
Set
OpenOther
Rejects
UINT
Number of open requests rejected or timed out by downstream nodes
Optional
Set
CloseReqs
UINT
Number of close requests received
Optional
Set
CloseFormat
Rejects
UINT
Number of close requests rejected by this node due to format

errors
Optional
Set
CloseOther
Rejects
UINT
Number of close requests rejected or timed out by downstream nodes
Optional
Set
ConnTimeouts
UINT
Number of connections which

have been timed out by this node
after they were opened
Optional
Get
NumConnEntries
UINT
Number of Conn Array Entries

(bit field). This attribute, divided
by 8 and incremented for any remainder, gives the size of the
byte array for attribute 10.
10
Optional
Get
ConnOpenBits
ARRAY of List of connection data which

BYTE
may be individually queried by
the Get/Search Connection Data
Services. Each bit represents a
possible connection.
0 No Connection.
1 Connection Established.
Query for more information.
11
Optional
Get
CpuUtilization
UINT
0 0% Utilization.
1000 100% Utilization.
Value indication CPU Utilization.
Semantics of Values
Number of bits used in the ConnOpenBits Attribute.
5119
Number
Need in
Implementation
Access
Rule
Name
Type
Semantics of Values
12
Optional
Get
MaxBuffSize
UDINT
Amount of buffer space

originally available.
Size is in Bytes
13
Optional
Get
BufSize
Remaining
UDINT
Amount of buffer space

available at this time.
Size is in Bytes
Note: Set implies that the attribute is both Gettable and Settable.
Get implies that the attribute is only Gettable
The instance attributes which are settable allow the attribute value to be cleared.
Common Services
Service
Code
ode
Need in
Implementation
Class
Service
ervice Name
ame
ervice
Instance
03hex
Optional
Optional
Get_Attributes_List
01hex
Optional
Optional
Get_Attributes_All
0Ehex
Optional
Optional
Returns the contents of the specified attribute.
04hex
n/a
Optional
Set_Attributes_List
02hex
n/a
Optional
Set_Attributes_All
10hex
n/a
Optional
Modifies an attribute value
The Connection Manager Object provides the following Common

Services:
5120
The Connection Manager Object provides the class specific services
contained in the following table.
Table 51.I
Class-specific Services provided by the Connection
Manager Object
Need in
Implementation
Name
ervice
Service
Code
ode
Description of
Service
ervice
Class
Instance
Open
4Bhex
n/a
Obsolete
Fwd_Open
4Chex
n/a
Obsolete
Close
4Dhex
n/a
Required
Fwd_Close
4Ehex
n/a
Required
Find
4Fhex
n/a
Optional
Proxy_Open
50hex
n/a
Obsolete
Proxy_Close
51hex
n/a
Optional
Unconnected_ Send
52hex
n/a
Optional
Unconnected Send
Service
Ni_Open
53hex
n/a
Required
Open a connection
Ni_Fwd_Open
54hex
n/a
Required
Open a connection
Ni_Proxy_Open
55hex
n/a
Optional
Get_Connection_Data
56hex
n/a
Optional
Get information about

a specific connection
Search_Connection_Data
57hex
n/a
Optional
Search for information

about a connection
Close a connection
Refer to Functional Specification 130/009/003, Connections in

CIP for more information about the Connection Manager Object
specific services and their behavior.
PCCC Object
Used to provide a way to deliver PCCC messages (DH, DH+,

DH-485 application layer) encapsulated inside OB messages.
Class Code: 67hex
Table 51.J
Class Attributes for the PCCC Object
Need in
Implementation
Access
Rule
Name
Data Type
Optional
Get
Revision
UINT
Optional
Spec
Max Instance
UDINT
Number
5121
Semantics of
Values
Table 51.K
Instance Attributes for the PCCC Object
Number
1
Need in
Implementation
Access
Rule
Name
Type
Semantics of Values
Required
Set
PLC2 files
UINT
File number to use for PLC2

commands
Global Data Table file number
Common Services
The PCCC Object provides the following Common Services:
Need in
Implementation
Class
Service
ervice Name
ame
ervice
Instance
03hex
Optional
Optional
Get_Attributes_List
01hex
Optional
Optional
Get_Attributes_All
04hex
Optional
Optional
Set_Attributes_List
02hex
Optional
Optional
Set_Attributes_All
Class-specific Services provided by the PCCC Object

Name
ame
Number
um er
Execute PCCC
Execute DH+
ervice
Parameter Names
ames
Required
Execute the PCCC_Command via

ControlNet connections
Client ID, PCCC_Command
Required
Execute the PCCC_Command

across DH+ link
DH Header, PCCC_Command
Class
Instance
4Bhex
Optional
4Chex
Optional
PCCC Object
Service
Code
ode
5122
These two services are both used to cause execution of PCCC

commands, according to DS PC 4056. They differ in the
identification of the requestor and the support of intervening DH+
links. If the requestor, executor and all intervening links are
ControlNet, then the Execute PCCC service should be used. This
service uses the ControlNet identification of the requestor. If either
the requestor or executor are non-ControlNet devices or if any
intervening link is a DH+ link, then the Execute DH+ service
should be used.
The following parameters are defined for the Execute PCCC Service
request.
PCCC Object
Table 51.L
Parameters for the Execute PCCC Service request
Name
Type
Description of Request Parameter
Semantics of Values
Length
USINT
Length of requestor ID
Number of bytes, including Length, Vendor, Serial

Number, and Other fields.
Vendor
UINT
Vendor number of requestor
Same as the attribute in the Device Object of the same

name.
Serial
Number
UDINT
CIP serial number of requestor
Same as the attribute in the Device Object of the same

name.
Other
Product
Specific
Identifier of user, task, etc. on the requestor
Product specific
CMD
USINT
Command byte
See PCCC specification
STS
USINT
Must be zero on PCCC requests
TNSW
UINT
Transport word
None. Same value must be returned to requestor
FNC
USINT
Function code: not used for all CMDs
PCCC_
params
ARRAY of
USINT
CMD/FNC specific parameters
The following parameters are defined for the Execute PCCC Service
response.
5123
Table 51.M
Parameters for the Execute PCCC Service response
Name
Type
Description of Response Parameter
Semantics of Values
Length
USINT
Length of requestor ID
Same value as in request.
Vendor
UINT
Vendor number of requestor
Serial
Number
UDINT
CIP serial number of requestor
Other
Product
Specific
Identifier of user, task, etc. on the requestor
CMD
USINT
Command byte
STS
USINT
Status byte
TNSW
UINT
Transport word
None. Same value as the request
EXT_
STS
USINT
Extended Status: not used for all CMDs
PCCC_
results
ARRAY of
USINT
CMD/FNC specific result data
The following parameters are defined for the Execute DH+ Service
request.
Name
Type
Description of Request Parameter
Semantics of Values
DLink
UINT
Destination Link ID
See DH+ specification
DSta
USINT
Destination Station number
DUser
USINT
Destination User number
SLink
UINT
Source Link ID
SSta
USINT
Source Station number
SUser
USINT
Source User number
CMD
USINT
Command byte
STS
USINT
Must be zero on PCCC requests
TNSW
UINT
Transport word
None. Same value must be returned to requestor
FNC
USINT
Function code: not used for all CMDs
PCCC_
params
ARRAY of
USINT
CMD/FNC specific parameters
PCCC Object
Table 51.N
Parameters for the Execute DH+ Service request
5124
The following parameters are defined for the Execute DH+ Service
response.
Table 51.O
Parameters for the Execute DH+ Service response
Type
Description of Response Parameter
Semantics of Values
DLink
UINT
Destination Link ID
DSta
USINT
Destination Station number
DUser
USINT
Destination User number
SLink
UINT
Source Link ID
SSta
USINT
Source Station number
SUser
USINT
Source User number
CMD
USINT
Command byte
STS
USINT
Status byte
TNSW
UINT
Transport word
None. Same value as the request
EXT_
STS
USINT
Extended Status: not used for all CMDs
PCCC_
results
ARRAY of
USINT
CMD/FNC specific result data
PCCC Object
Name
Rack Object
5125
Used to support both real rack to adapter operation as well as proxy

operation for adapters that are linked to the Remote I/O Network
through an RIO Scanner.
Class Code: 7Chex
Dependencies
As proxies for RIO adapters there is a dependency on an existing
scan list in the RIO Host Object. Without the scan list all instances
remain in the Not Configured state.
Table 51.P
Class Attributes for the 1771 Discrete I/O Rack
Need in
Implementation
Access
Rules
Name
Data Type
Semantics of Values
Required
Get
Revision
UINT
Revision of this Object
Rev 2.0
Required
Spec
Max Instance
UINT
Depends upon # of channels

on module
Rack Object
Number
5126
Table 51.Q
Instance Attributes for the 1771 Discrete I/O Rack
Need in
Implementation
Access
Rules
Name
Data Type
Required
Spec
Owner
UDINT
serial number of owner
Required
Spec
Vendor ID
UINT
Vendor of owner
Optional
Get
number_slots
USINT
physical slots in the rack
Optional
Get
state
BYTE
actual state
Optional
Get
Input_Mask
DWORD
indicates which slots have

inputs
1=input present in logical slot
Optional
Get
module_size
ARRAY of
UINT
physical size of modules in

physical slots
bits per module
Optional
Get
BT_Status
WORD
Optional
Get
Status_Word
WORD
Optional
Set
Messaging
Error
USINT
RIO link messaging errors
10
Optional
Set
Retry Counter
UINT
Keeps count of error total
11
Optional
Get
Rack Input
State
USINT
12
Optional
Get
Rack Output
State
USINT
Rack Object
Number
Semantics of Values
4
5
5127
Bits for the State attribute indicate the actual state of the rack
0
unused
1
unused
2
processor restart lockout configuration:
0 = processor cannot restart the rack, human action required
1 = processor can restart
3
Communications fault action configuration:
0 = outputs hold last state
1 = outputs reset
4
I/O State:
0 = I/O are reset
1 = I/O are not reset
5, 6
Density:
bit 5=0, bit 6=0: Double slot addressing
bit 5=1, bit 6=0: Single slot addressing
bit 5=0, bit 6=1: Half slot addressing
bit 5=1, bit 6=1: <not allowed>
1 = Inputs are being produced
7
Bits for the BT_Status attribute indicates which slots have BTs
Bits for the Status Word attribute indicate the actual state of the rack
0..1
Adapter Size
2
In scan list
Exists (replied at least once)
3
4
Adapter Online (receiving valid replies)
5
Faulted (Adapter is faulted =1 , off line = 0 )
6
Node Adapter (when set, adapter is a node adapter)
7
Inhibit (when set, send no messages)
8
Output Enable (when clear, send CMD 1s)
9
Unsolicited BT (Unsolicited BT received = 1, No unsolicited BT requests = 0 )
10
Freshness (Input image data for this adapter 1 = fresh 0 = stale)
11
Known (internal RIO bookkeeping)
12..15
Reserved
Messaging error description for master slave protocol. See project specific literature for information regarding value meanings.
Product dependent. See version description for values.
Common Services for the 1771 Discrete I/O Rack

Service Name
Get_Attributes_All
required
Set_Single_Attribute
optional
App_Open_Connection (local service only)
required
NI_App_Open_Connection (local service

only)
optional
App_Close_Connection (local service only)
required
5128
In ascending order the attributes returned in the reply data of the
response are dependent upon which of the optional Instance
attributes are selected. See product design documents for specifics.
None
1771 Discrete I/O Connections

Name
Number
Type
Inputs Packed
<structure>
report current state of discrete input

modules
Outputs
Packed
<structure>
set current value of discrete output

modules
Inputs Open_Connection Request Application Data

The following parameters are used in the Data Segment field of
the Open_Connection request for all of these connections. There is
no data in the Data Segment field of the Open_Connection
response for any of these connections.
Name
Type
Semantics of Values
Number of slots
UINT
Number of logical slots
Logical slot = 16 bits
Rack Object
There is no data in the Data Segment field of the

Close_Connection request for any of these connections. There is no
data in the Data Segment field of the Close_Connection response
for any of these connections.
5129
Packed Inputs Connection Structure

The following table defines the Inputs Connection Structure.
Description of
Member
Name
Type
Semantics of Values
Adapter_Status
DWORD
Input_Mask
DWORD
indicates which slots

have inputs
1 = input present in
logical slot
Data
ARRAY of
WORD
module data
16 bits per logical slot
1 Bits for the Adapter Status DWORD are as follows

0
Data Integrity: good = 0, bad =1
1
Adapter detected 1771 chassis backplane short: good = 0, bad = 1
2
Scanner Induced a fault: good =0, bad = 1
3
Rack Address overlap: good =0, bad =1
4
Duplicate RIO Scanner detected: good =0, bad = 1
5
Maximum # of devices exceeded: good = 0, bad =1
Packed Outputs Connection Structure

The following table defines the Outputs Connection Structure.
Name
Type
Description of Member
Semantics of Values
Command
UDINT
Mode for whole rack
0 = program (disable)
not zero = run (enable)
Data
ARRAY of
DWORD
Module Data
16 bits per logical slot
The following describes the local connection process to the rack.

This object supports simultaneous connections to both input
connection point and output connection point. The size of the
Net OT for the output connection point (must equal rack size) is
checked first then the size of the Net TO for input connection (
to rack size) point is checked. If either of the sizes conflicts with
the allowable size permitted to this connection point the entire
connection is faulted. There is no indication in the status to
specify which size was incorrect.
Subsequent connections to a rack instances input connection point
must not contain a request for output connection point. These
connections requests will be faulted.
Rack Object
Behavior Specifics
5130
Figure 51.5
Behavior
Rack Output (CP2)
Processed App Open to CP2:

Failed. Rack size provided in net
OT connection parameters does
not equal rack size.
NonExistent
Power up
Not Configured
Hard Reset
Processed Configuration:
Which is by reading
switches on 1771
backplane or as a proxy
rack for an RIO adapter
reading the scan list of the
RIO Scanner for location
and size.
Idle
Scan List Received: This is only for a

proxy rack for an RIO adapter in an RIO
Scanner where the rack is no longer in the
list.
Soft Reset: This is either caused by push button or is self generated if the 1771 backplane
PRL switch is set to false or as a proxy rack
for RIO adapters it falls through to Idle.

Success
Failed. Only one connection to
CP2 allowed at a time. Multicast
connections to CP1 must come
without a request to CP2.
/ Received Timeout
Processed App Close to CP2: Success
to CP2: Loss of communications. This will terminate all open connections to CP1. As a proxy rack for an RIO adapter it will cause the
RIO Scanner to stop scanning the adapter (INHIBIT).
Active Program
Communication Fault
This is the
only
event
that can reset
the rack when
the
PRL
switch is set to
true
Output Enabled Failed

due 1771 short or scanner induced fault (SIF)
not cleared
Output Disabled due to either a request

from the controlling device or a short on the
1771 backplane or because the RIO Scanner induced a fault to adapter this rack is
proxying for. CP1 status set to indicate
problem for the last SIF and 1771 short
Processed App Open CP2 / Close to

CP1 : Failed. These requests are not
supported in this state
Output Enabled Success
Active Run
Rack Object
Processed App Close to CP2: Success

/ Received Timeout
to CP2: Loss of communications. This will terminate all open connections to CP1. As a proxy rack for an RIO adapter it will cause the
RIO Scanner to stop scanning the adapter (INHIBIT).

Failed. Only one connection
to CP2 allowed at a time. Multicast connections to CP1 must
come without a request to CP2.
5131
Rack Input (CP1)

Processed App Open to
CP2: Success. The state
of CP2 changed to active
program
NonExistent
Idle
Processed App Close to

CP1: Success.

CP1: Failed. Connection
does not exist.

CP1: Failed. The size in
Net TO parameters is
greater than the rack
size. Size must be to
rack size.
CP1: Success.
Producing Inputs
Single Cast
Processed App Close

to CP1: Success 1
remaining connection
CP1: Failed. Connection
does not exist.
Processed App Close
to CP1: Success.

CP1: Failed. The size in Net
TO parameters does not
equal first open connection
size.
CP1: Success
Producing Inputs
Multicast
Rack Object
Processed App Close to CP2 : Success /

Received Timeout: Loss of communications.
The connections to CP1 are dependent on
the connection to CP2. If CP2 fails or is
closed so are all connections to CP1.

Failed. The size in Net TO
parameters does not equal first
open connection size or due to
lack of available resources.
Success.
5132
ControlNet Object
Class Code: 65hex
Provides the configuration interface of a single ControlNet port.

Provides a local and regional configuration management interface to
the ControlNet LLC (where the LLC is the top sublayer of the
ControlNet data link layer which provides a common interface to
multiple physical media implementations). Refer to the Figure 51.6
for the ControlNet Object context.
Figure 51.6
ControlNet Object Context
Connection
Manager
Device
Object
Application Messaging
Objects
Message Router
Application Data
Objects
Class 3
Transport
UCMM
Class 1
Transports
ControlNet
Object
ControlNet
Driver
ControlNet
MAC
Physical
Layer
ControlNet
Table 51.R
Class Attributes for the ControlNet Object
Number
0x1
ControlNet Object
0x2
Need in
Implementation
Access
Rule
Name
ControlNet
Data Type
Description of
Attribute
Optional
Get
revision
UINT
Revision of this object 1
Optional
Get
max instance
UDINT
Maximum instance
number
The value for the revision Class attribute is 1.
The value for the max_instance Class attribute is implementation specific.
Semantics of
Values
2
5133
Number
0x80
Need in
Implementation
Access
Rule
Name
Type
Semantics of Values
Required
Set
pending_
config
STRUCT OF:
24 bytes
pending configuration
parameters
pending_ net_
config
STRUCT OF:
12 bytes
ControlNet pending
network
parameters
nut_time
UINT
Network
Update
Time
in 10 micro second ticks
smax
USINT
Scheduled max node ID
range 1-99
umax
USINT
Unscheduled max node ID
smax + 8
slot_ time
USINT
Slot Time
in micro secs
blank_ time
USINT
Blanking
Time
in bytes
gb_start
USINT
Guard Band
Start
in 10 micro sec ticks
gb_center
USINT
Guard Band
Center
in 10 micro sec ticks
redundancy
BYTE
Redundancy Control
sched_
max_frame
USINT
Scheduled
Maximum
Frame
in byte-pairs4
int_cnt mod
USINT
Interval
Count
Modulus
fixed: 255
gb_prestart
USINT
Guard Band
Prestart
in 10 micro second ticks
pending_
sched_rate
STRUCT of:
4 bytes
Scheduled data production

rate
macrocycle_
start
USINT
Macrocycle
start
macrocycle_
length
USINT
Macrocycle
length
macrocycle_
count
USINT
number of consecutive NUTs

allows
macrocycle_
multiplier
BYTE
Multiple rates node allows
TUI
STRUCT of
6 bytes
Keeper Table
Unique
Identifier
10
unique_id
UDINT
Keeper
Unique Identifier value
11
ControlNet Object
Table 51.S
Instance Attributes for the ControlNet Object
5134
Number
Need in
Implementation
Access
Rule
Name
Type
Semantics of Values
status_flag
BYTE[2]
TUI flag
12
state
UINT
ControlNet Object state
13
0=Listen Only
1=On-Line
Required
Get
current_ config
STRUCT of
24 bytes
current
configuration
parameters
14
current_ net_
config
STRUCT OF:
12 bytes
ControlNet working network

parameters
15
current_
sched_rate
STRUCT of: 4
bytes
Current Scheduled data

production rate
16
TUI
STRUCT of
6 bytes
Keeper table
unique
identifier
10
State
UINT
ControlNet Object state
13
diagnostic_
counters
STRUCT of
42 bytes
Diagnostic
counters
17
buffer_errors
UINT
Buffer event
counter
18
error_log
BYTE[8]
Bad MAC
frame log
19
event_
counters
STRUCT of
31 bytes
Diagnostic
counters
20
pad byte
BYTE
pad byte
value ignored
station_
status
STRUCT of
6 bytes
Station
status
21
0x81
0x82
Required
Set
Get
ControlNet Object
0x83
Required
5135
Semantics
1
The values within the pending_config attribute configure the

ControlNet communication parameters for the device. This attribute
is settable when the ControlNet Object is in any mode. (See
External Behavior on page 5151). Anyone can set this attribute.
Portions of this attribute must be synchronized. (See
Synchronization of Attributes on page 5157).
2
The values within the pending_net_config sub-attribute

correspond to the pending ControlNet network configuration
parameters for the device.
When the ControlNet Object is in Listen-Only mode, the act of
setting the values for this sub-attribute causes these values to take
affect immediately (i.e. these pending values become the
working values of the current_net_config sub-attribute). When the
ControlNet Object is not in Listen_Only mode, the values for this
sub-attribute may need to be synchronized either locally or with
other devices on the ControlNet Network (via the class-specific Sync
service). (See Synchronization of Attributes on page 5157 for
more information on attribute synchronization.)
3
The redundancy sub-attribute is the two least-significant bits of

this BYTE. The remaining 6 bits of this byte are reserved. The
value of this sub-attribute corresponds to the LSB of this field for the
net_config attribute.
Because this sub-attribute is a field within the pending_config
attribute, the value of this sub-attribute is synchronized.
Single channel devices that receive A/B (3) or B (1) from a Set
Attributes will not accept the command and remain in the
ListenOnly state.
The redundant mode control bits allow forced selection of either
ChA or ChB for the entire network as shown in the following table.
Bit 1
Bit 0
Meaning
reserved
use Channel B only
use Channel A only
redundant media - modem selects between the two receiver inputs
ControlNet Object
Table 51.T
Redundancy Mode Control Bits
5136
The sched_max_frame sub-attribute is used to limit the maximum

size of each nodes scheduled interval transmit slot. The range of
values can be 0 to 255. Note that 255 byte-pairs equals 510 bytes. A
value of 0 indicates that a node must not transmit during the
scheduled portion of the NUT (i.e. scheduled token rotation).
5
The values within the pending_sched_rate sub-attribute correspond

to the pending ControlNet port parameters for the device. This
sub-attribute consists of four byte values.
6
The value of the macrocycle_start sub-attribute corresponds to the

value of the Interval Match register. This sub-attribute corresponds
to the nodes macrocycle start NUT number. This sub-attribute is
used to interleave node data production on the network.
A value of 0 for this sub-attribute means that the nodess fast data
production (i.e. macrocycle) must start on this nodes first NUT
because NUTs are zero-based values.
The value of the macrocycle_start sub-attribute must be less than or
equal to the value of the macrocycle_length attribute.
7
The value of the macrocycle_length sub-attribute corresponds to

the value of the Interval Mask register. This sub-attribute
corresponds to the nodes (macrocycle length - 1), expressed as a
number of NUTs. This sub-attribute is used to interleave node data
production on the network.
A value of 0 for this sub-attribute means that the node must transmit
scheduled data on every NUT (i.e. single NUT macrocycle).
The value of the macrocycle_length sub-attribute must be the nodes
fast data production rate.
ControlNet Object
The macrocycle_count sub-attribute represents the number of

consecutive NUTs this node is allowed to transmit scheduled data.
5137
The valid range of values is 0 to 255. A value of 0 indicates that a

node must not have any reserved bandwidth available to transmit
scheduled data.
9
The macrocycle_multiplier sub-attribute represents the scheduled

data production rates supported by this node. This sub-attribute
contains an array of bits which represents rates of 1, 2, 4, 8, 16, 32,
64, and 128 times the macrocycle. The least significant bit of this
sub-attribute must always be zero: the value of this attribute must
always be even.
Where a nodes macrocycle is referred to as its fast data production
rate, a multiple of the macrocycle is referred to as a nodes slow data
production rate. A value of 0 for this sub-attribute means the fast
rate and all slow rates for the node are equal.
10
The TUI sub-attribute consists of six byte values. The value of

this sub-attribute corresponds to the ControlNet Keeper Table
Unique Identifier of the entire network.
Even though this sub-attribute is a part of the pending_config
attribute, the value for this sub-attribute is not synchronized.
The value of the TUI sub-attribute within the pending_config
structure is the same as the TUI sub-attribute in the current_config
attribute. The values for this sub-attribute take effect immediately
when setting the pending_config attribute.
11
The unique_id field of the TUI subattribute consists of four byte

values.
The ControlNet Object ignores the values for this field of the TUI
subattribute.
12
ControlNet Object
The status_flag field of the TUI sub-attribute consists of two byte

values. The TUI flag bits reflect the status of the ControlNet Keeper
Table Unique Identifier for the entire network as shown in the table
below.
5138
Table 51.U
ControlNet Configuration Manager (CCM) Table Unique
Identifier (TUI) Status Flag Bits
Bit
Meaning
Valid TUI bit:

0 = invalid TUI
1 = valid TUI
Real CCM TUI bit:

0 = Temporary CCM TUI
1 = Real CCM TUI
0 = TUI sent by temporary CCM

1 = TUI sent by real CCM
3 - 15
reserved
The behavior of the ControlNet Object depends on the values for this
field of the TUI sub-attribute (see Synchronization of Attributes
section).
13
The values for the state subattribute correspond to the two

operational states of the ControlNet Object. The value 0 represents
the ListenOnly state while the value 1 represents the OnLine
state and the value 2 represents the Dup ListenOnly state. Though
included as part of the configuration attribute, this subattribute is
only gettable. Anyone can read this subattribute.
The value of the state sub-attribute within the pending_config
structure is the same as the state sub-attribute in the current_config
attribute. Any values for this sub-attribute are ignored when setting
the pending_config attribute.
14
The values within the current_net_config attribute correspond to

the current, working ControlNet network parameters for the device
(see the pending_net_config attribute for the contents of this
structure). This attribute is only gettable. Anyone can read this
attribute.
15
ControlNet Object
The values within the current_net_config sub-attribute correspond

to the current, working ControlNet parameters for the device.
(See the pending_config attribute for the contents of this structure.)
5139
To establish network communication, the following values of the

current_net_config attribute must match those of another device on
the link.
nut_time
smax
umax
slot_time
blank_time
gb_start
gb_center
int_cnt_mod
gb_prestart
These values represent the contents of the ControlNet moderator
Lpacket.
16
The values within the current_sched_rate sub-attribute correspond

to the current, working ControlNet port parameters for the device
(see the pending_sched_rate attribute for the contents of this
structure).
17
The diagnostic_counters attribute contains counters. Anyone can

get the value of these counters. Anyone can set the values of these
counters to zero using the Get_And_Clear service. See the
Classspecific Services section.
Values contained within this attribute are not protected against
rollover.
18
The value of the buffer_errors sub-attribute includes the number

of communication buffer overflows, underflows, and out-of-buffer
conditions detected.
19
The error_log sub-attribute contains the last eight MAC IDs

which sent a MAC packet which this node received as a bad Rx
MAC frame. The order of MAC IDs is most recent first to oldest.
Values of zero represent unused positions in the error log.
20
The values within the event_counters sub-attribute correspond to

the contents of the ControlNet ASIC Diagnostic Object.
The values within the station_status attribute correspond to the
contents of the ControlNet ASIC Station Status Object. This
attribute is only gettable. Anyone can read this attribute.
ControlNet Object
21
5140
The station_status attribute contains several byte values. The most

useful of these bytes is the Channel State. The bits of the Channel
State byte are described in the table below.
Table 51.V
Channel State Bits
Bits
Description
0,1,2
Channel A LED State
3,4,5
Channel B LED State
Redundancy Warning - When active, the non-selected channel in a redundant

configuration is unusable by the controller.
0 = normal
1 = warning active
Active Channel - indicates which of two channels the receiver is listening to.
0 = Channel B
1 = Channel A
Common Services
The ControlNet Common Services section of this Product Developer
Guide describes the following common services.
These services must all operate with an internal time-out to prevent a
hardware error condition in the ASIC from indefinitely stalling
operations. The actual timeout values are device dependent.
The ControlNet Object requires the following Common Services:
Service
Code
ode
Need in
Implementation
Service
ervice Name
ame
ervice
Instance
10hex
Not
Required
Required
Set network and node

specific configuration for
devices
05hex
Not
Required
Required
Reset
Return ControlNet object to

Listen-Only
0Ehex
Not
Required
Required
Get network and node

specific configuration for
devices
ControlNet Object
Class
5141
The ControlNet Object may provide the following Common

Services:
Service
Code
ode
Need in
Implementation
Service
ervice Name
ame
ervice
Returns the contents of all

attributes of the ControlNet
object.
Class
Instance
01hex
Not
Required
Optional
Get_Attributes_All
02hex
Not
Required
Optional
Set_Attributes_All
03hex
Not
Required
Optional
Get_Attributes_List
04hex
Not
Required
Optional
Set_Attributes_List
Set_Attributes_Single Request
Use the set_attributes_single request to:
set the network and the node-specific configurations for a
ControlNet device.
bring the ControlNet Object out of Listen-Only mode (see
External Behavior section).
ControlNet Object
The Object/Service specific parameters portion for a valid

set_attributes_single request is shown in the table below.
This request contains 24 bytes.
5142
pending_config attribute '
Name
ControlNet
Data Type
pit_time
UINT
Pending Periodic Interval of Time
smax
USINT
Pending Scheduled Maximum Node ID
umax
USINT
Pending Unscheduled Maximum Node ID
slot_time
USINT
Pending Slot Time
blank_time
USINT
Pending Blanking Time
gb_start
USINT
Pending Guard Band Start
gb_center
USINT
Pending Guard Band Center
redundancy
BYTE
Pending Redundancy control
sched_max_frame
USINT
Pending Scheduled Maximum Frame
int_cnt_mod
USINT
Pending Interval Count Modulus
gb_prestart
USINT
Pending Guard Band Prestart
macrocycle_start
USINT
Macrocycle start
macrocycle_length
USINT
Macrocycle length
macrocycle_count
USINT
Macrocycle PIT count
BYTE
Macrocycle multiplier
unique_id
UDINT
Table Unique Identifier value
status_flag
BYTE[2]
Table Unique Identifier status flag
state
UINT
Object State - value ignored
Note: That the ControlNet Object ignores any values for the state
field within the parameters of the set_attributes_single request.
Note: That the parameters of the set_attributes_single request do not
include values for the counters. Counters must only be set to zero
using the class specific Get_And_Clear service.
With the exception in Note 3 of External Behavior on page 5151
and in Synchronization of Attributes on page 5157, the
ControlNet Object does not perform attribute value checking during
any set operation.
ControlNet Object
The Set_Attributes_All request behaves the same as the

set_attributes_single request.
5143
pending_config attribute '
current_config attribute '
Name
ControlNet
Data Type
pit_time
UINT
Pending Periodic Interval Time
smax
USINT
Pending Scheduled Maximum Node ID
umax
USINT
Pending Unscheduled Maximum Node ID
slot_time
USINT
Pending Slot Time
blank_time
USINT
Pending Blanking Time
gb_start
USINT
Pending Guard Band Start
gb_center
USINT
Pending Guard Band Center
redundancy
BYTE
Pending Redundancy control
sched_max_frame
USINT
Pending Scheduled Maximum Frame
int_cnt_mod
USINT
Pending Interval Count Modulus
gb_prestart
USINT
Pending Guard Band Prestart
macrocycle_start
USINT
Macrocycyle start
macrocycle_length
USINT
Macrocycle length
macrocycle_count
USINT
BYTE
unique_id
UDINT
status_flag
BYTE[2]
state
UINT
Object state
pit_time
UINT
Current Periodic Interval Time
smax
USINT
Current Scheduled Maximum Node ID
umax
USINT
Current Unscheduled Maximum Node ID
slot_time
USINT
Current Slot Time
blank_time
USINT
Current Blanking Time
gb_start
USINT
Current Guard Band Start
gb_center
USINT
Current Guard Band Center
ControlNet Object
The ControlNet Object response to a Get_Attributes_All request is

shown in the table below. This data is returned in the
Object/Service specific reply data portion of a successful response.
This response contains 96 bytes.
5144
ControlNet Object
diagnostic_counters attribute '
Name
ControlNet
Data Type
redundancy
BYTE
Current Redundancy control
sched_max_frame
USINT
Current Scheduled Maximum Frame
int_cnt_mod
USINT
Current Interval Count Modulus
gb_prestart
USINT
Current Guard Band Prestart
macrocycle_start
USINT
Macrocycle start
macrocycle_length
USINT
Macrocycle length
macrocycle_count
USINT
BYTE
unique_id
UDINT
status_flag
BYTE[2]
state
UINT
Object state
buffer_errors
UINT
Buffer overflow / underflow errors
error log
BYTE[8]
MAC IDs of bad MAC frames received
good_frame transmitted
BYTE
Good MAC frames transmitted LSB
good_frame
transmitted
BYTE
Good MAC frames transmitted
BYTE
Good MAC frames transmitted MSB
good_frame received
BYTE
Good MAC frames received LSB
good_frame received
BYTE
Good MAC frames received
good_frame received
BYTE
Good MAC frames received MSB
selected_channel_frame_
errors
USINT
Selected channel frame errors
channel_a_frame_errors
USINT
Channel A frame errors
channel_b_frame_errors
USINT
Channel B frame errors
aborted_frames_
transmitted
USINT
Aborted frames transmitted / Tx stream

underflows
highwaters
USINT
Highwaters / out-of-step events
pit_overload
USINT
PIT overloads
slot_overloads
USINT
Slot overloads
blockages
USINT
Number of blockages
non_concurrence
USINT
Non-concurrence events
aborted_frames_received
USINT
Aborted frames received
lonely_counter
USINT
Lost contact with network counter
duplicate_node
USINT
Frames from duplicate MAC ID
Name
ControlNet
Data Type
noise_hits
USINT
Noise detected which locked the PLL
collisions
USINT
Collisions
moderator_mac_id
USINT
MAC ID of current moderator
non_lowman moderators
USINT
Moderators from non-lowmen
mismatch
USINT
Rogue events
unheard_moderator
USINT
Unheard moderator occurrences
sm_cmds
USINT
Station management commands received

from wire (not host)
spares
BYTE[4]
Spare (unused) bytes
pre_reset_fault_reg
USINT
Fault register pre-reset record
post_reset_fault_reg
USINT
Fault register post-reset record
pad byte
BYTE
Pad byte for WORD alignment - ignore
smac_ver
USINT
ASIC version
dirty_bits
BYTE
Dirty bits - least significant 5 bits
toggle_bits
BYTE
Toggle bits - least significant 5 bits
host_bits
BYTE
Host config bits - least significant 3 bits
hardware_config
BYTE
ASIC hardware configuration bits - least

significant 3 bits
channel_state
BYTE
Channel state LEDs, redundancy warning,

and active channel bits
Note: Because of the large size of the Get_Attribute_All response,

devices with limited resources may not support this service.
ControlNet Object
station_status attribute '
5145
5146
Reset
The Reset service causes the ControlNet Object to enter the
Listen-Only mode (see the External Behavior section below).
The Reset service has side effects on the ControlNet Object
attributes. After receiving a Reset request and before its transition to
the Listen-Only state, the ControlNet Object sets its
current_net_config attribute to a very loose set of values (see
Listen-Only Network Parameters section). This allows the ASIC to
receive packets regardless of what network configuration is actually
in use on the wire.
While in the On-Line state the ControlNet Object should respond
successfully to a Reset request before actually performing a reset
operation. In devices where a Reset cannot be performed
successfully because the Reset response takes too much time, the
Reset response need not be sent. The Reset response contains no
parameters.
Note that anyone can halt device communications by resetting the
ControlNet Object.
Class-specific Services provided by the ControlNet Object

ame
Name
Number
um er
Class
lass
Instance
ervice
Parameter
75
Not
Required
Not Required
for Phase 1
Apply the pending attribute

values and may synchronize
the changes across the
ControlNet link
T-minus
Get_And_Clear
76
Not
Required
Required
Get then clear the diagnostic

counters
<none>
Check_For_Moderator
77
Not
Required
Required only for ControlNet

Configuration Manager
(CCM) and temporary CCM
devices
Check for ControlNet

Mod MAC ID Network
Moderator MAC ID and return Parameters
network parameters
ControlNet Object
Sync
5147
Sync Service
This service causes the ControlNet Object to copy its pending_config
attribute values to its current_config attribute values. This service is
required for synchronizing node operation parameters in an orderly
fashion.
The class specific Sync request includes the parameter shown in the
table below.
Name
T-minus
Type
USINT
Semantics of
Values
Time to wait before synchronizing

attribute changes
Number of network
update times1
Semantics
1
The valid range of T-minus values is 1 or 10 to 255. A value of 1

causes the ControlNet Object to perform a local synchronization.
Values greater than 1 cause synchronization for all nodes on the local
ControlNet sub-net.
The ControlNet Object:
does not check whether attribute values are pending
performs the Sync service only while in the On-Line state.
The ControlNet Object always responds successfully to a Sync
request before actually performing its synchronization operation.
The Sync response contains no parameters.
Get_And_Clear Service
While in the On-Line state, the ControlNet Object responds

successfully to a Get_And_Clear request with the parameters shown
in the table below. The ControlNet Object sets the values of these
attributes to zero after queueing the response. This response contains
42 bytes.
[The changes to the following table are not marked with revision
bars.]
ControlNet Object
This service is similar to the Get_Attributes_Single request of the

diagnostic_counters attribute except that in addition to responding
with the current counter values, the ControlNet Object immediately
clears these same counters. Use this service for node troubleshooting
and network performance analysis.
5148
Get_And_Clear Response
ControlNet Object
diagnostic_counters attribute '
Name
ControlNet
Data Type
buffer_errors
UINT
Buffer overflow / underflow errors
error_log
BYTE[8]
MAC IDs of bad MAC frames received
BYTE
Good MAC frames transmitted LSB
BYTE
Good MAC frames transmitted
BYTE
Good MAC frames transmitted MSB
good_frame received
BYTE
Good MAC frames received LSB
good_frame received
BYTE
Good MAC frames received
good_frame received
BYTE
Good MAC frames received MSB
selected_channel_frame_
errors
USINT
Selected channel frame errors
channel_a_frame_errors
USINT
Channel A frame errors
channel_b_frame_errors
USINT
Channel B frame errors
aborted_frames_
transmitted
USINT
Aborted frames transmitted / Tx stream

underflows
highwaters
USINT
Highwaters / out-of-step events
pit_overload
USINT
PIT overloads
slot_overloads
USINT
Slot overloads
blockages
USINT
Number of blockages
non_concurrence
USINT
Non-concurrence events
aborted_frames_received
USINT
Aborted frames received
lonely_counter
USINT
Lost contact with network counter
duplicate_node
USINT
Frames from duplicate MAC ID
noise_hits
USINT
Noise detected which locked the PLL
collisions
USINT
Collisions
moderator_mac_id
USINT
MAC ID of current moderator
non_lowman moderators
USINT
Moderators from non-lowmen
mismatch
USINT
Rogue events
unheard_moderator
USINT
Unheard moderator occurrences
sm_cmds
USINT
Station management commands received

from wire (not host)
spares
BYTE[4]
Spare (unused) bytes
pre_reset_fault_reg
USINT
Fault register pre-reset record
5149
Name
ControlNet
Data Type
post_reset_fault_reg
USINT
Fault register post-reset record
pad byte
BYTE
Pad byte for WORD alignment - ignored
Check_For_Moderator Service
The ControlNet Object provides only a local interface to the class
specific Check_For_Moderator service. This service is not available
over the network.
This local service is used to detect 9 consecutive moderator packets,
each from the same Mac ID and with the same network parameters.
This service responds with a pointer to the Mac ID of the current
moderator and a pointer to the current network parameters and a
pointer to a moderator flag word. If no moderator exists, this service
responds with NULL pointer values.
The class specific Check_For_Moderator request includes the
parameters shown in the table below.
Type
Semantics of
Values
Mod_Mac_
Id
POINTER
Pointer to the MAC address of

the current network Moderator
Valid MAC ID or
NULL pointer 1
Network_
Parameters
POINTER
Pointer to a structure of the

current network parameters
Valid network
parameters or
NULL pointer 1
Mod_flag
POINTER
Pointer to a flag word, whose

Valid Mod_flag or
least significant bit is set to 1 if
NULL pointer 1
any moderators were detected, or
0 if no moderators were detected.
ControlNet Object
Name
5150
Semantics
1
Null pointer values indicate that the ControlNet Object was unable
to detect 9 consecutive moderator packets, each from the same MAC
ID with the same values for the following network parameters:
pit_time
smax
umax
slot_time
blank_time
gb_start
gb_center
int_cnt_mod
gb_prestart
The ControlNet Object checks for NULL pointer addresses when this
service is invoked. Refer to the following Check_For_Moderator
flow chart.
ControlNet Object Connections

The ControlNet Object does not support any connections.
ControlNet Object MAC IDs

The ASIC supports 256 MAC IDs. However, the valid range of
MAC addresses is 1 to 99 because devices on ControlNet have only
two hardware switches for selecting MAC IDs (each switch
representing a decimal digit). A devices MAC ID must match its
switch settings. Address 0 is reserved as a temporary MAC ID for
Super Node mode. Addresses above 99 are used for transient
nodes such as a handheld terminal. Transient nodes which power
up with a MAC ID set to 255 (0xff) must perform an auto address
sequence to set their MAC address to an unused value within the
range of smax and umax (where umax is always at least smax + 8).
ControlNet Object
If the ControlNet Object receives values for umax below the range of
its MAC ID, a Parameter Error event is flagged and the Listen-Only
state is entered under the control of the ControlNet Object.
5151
External Behavior
The ControlNet Object operational states are presented in the figure
below.
Powerup
Software States External to the ControlNet Object

External Software determines
MAC ID and invokes the ControlNet Object
Local Event
Indications:
Dup Node
and
Lonely
Reset to the Identity Object
All
States
NonExistent
Powerup
Dup Node
Flash Red if Lonely, otherwise Flash
Green
Railroad
Red
Dup ListenOnly
ListenOnly
Flash
Green
Flash
Green
Set
Single
Flash
Green
Railroad
Red
Railroad
Red
Reset to the
ControlNet
Object
Set Single +
Parameter
Error
Parameter
Error
Local Event
Indications:
Rogue
Dup Node
Lonely,
Online,
Reset,
Online Change
Rogue by
Leaky Bucket
detection
Dup Node
Solid
Green
OnLine
Solid
Green
Sync
Solid
Green
Get_Single
Get_Attribute_...
Set_Attribute_...
Solid
Green
Get_And_Clear
Note: All Set_Single events imply an OffLine Event.

Note: After leaving the OnLine state you must wait until 4 PITs
have passed before attempting to go OnLine again.
Note: Allowable ASIC Transitions:
ListenOnly
ControlNet Object
OnLine
Rogue or Dup
OffLine
ControlNet Object Operational States
5152
Table 51.W
External Behavior: ControlNet Object State Transitions
Event
State
Non
Existent
Powerdo
wn
NA
ListenOnly Goto
Non
Existent
Powerup
Reset
ControlNet
Object.
See Note 7
Set Single
to
ControlNet
Object.
See Note 7
Rogue
Goto
ListenOnly
(flashing red if
Lonely, flashing green
otherwise),
disable Rogue
and enable
Dup
NA
NA
NA
NA
NA
NA
NA
NA
No
Action
See
Note 1
NA
Goto the
Dup
Listen
Only state;
the default
ASIC
action is to
display railroad red
LEDs
No Action;
the default
ASIC operation is to
display
flashing
RED LEDs
Goto
Non
Existent
NA
NA
NA
NA
Goto
Non
Existent
NA
After
Rogue
detection
by Leaky
Bucket
mechanism, Goto
ListenOnly
and force
railroad red
LEDs
Goto the
Dup
Listen
Only state;
the default
ASIC
action is to
display railroad red
LEDs
No Action;
the default
ASIC operation is to
display
flashing
RED LEDs
Goto
Non
Existent
Goto
Listen
Only
Goto
Non
Existent
NA
NA
NA
OnLine
Goto
Non
Existent
NA
Goto
See
ListenOnly Note 2
Reset to
Identity
Object.
Param.
Error
See Note 3
See Note 7
ControlNet Object
Set
pending
Attributes
Lonely
See Note 4, See Note 5, See Note 6

7
7
Go
OnLine
Dup
Listen
Only
Dup
5153
Notes
Note 1: Go OnLine with the green LED. Clear Rogue and Dup
interrupts and enable Rogue detection; do not clear the receive
interrupt; set Pending Attributes and perform Local Synch.
If there is a Parameter error, stay in ListenOnly, do not perform the
above actions and maintain the flashing green LEDs.
Note 2: Set pending Attributes (except when received Set_Single
packet TUI_flag bit 2 = 0 and ControlNet Object TUI_flag bit 2 = 1);
perform Local Synch if received Set_Single packet TUI_flag bit 2 =
1 and ControlNet Object TUI_flag bit 2 = 0. See the on-line set
attribute behavior diagram.
Note 3: Parameter errors consist of:
A node configured for a MAC ID greater than UMAX (the device
will not be able to send messages to itself or to any node above
UMAX).
The Redundancy network parameter set to an invalid value.
Note 4: Rogue error processing requires all nodes to perform
LeakyBucket Rogue detection. In this scheme, the first few
Rogue interrupts received do not immediately invoke Rogue error
handling; instead the following is done:
1. Increment a Rogue counter by 2 for every Rogue interrupt.
2. Decrement the Rogue counter by 1 every 100 milliseconds.
3. If the counter is ever greater or equal to 32, proceed with Rogue
error handling.
The Rogue interrupt is disabled while the Kept Node is in the
ListenOnly state. On transition to OnLine the Rogue interrupt
is cleared and enabled; if the Rogue condition still exists the node
will return to the ListenOnly state, disable the Rogue interrupt,
and override the default ASIC LED behavior to display Railroad
Red LEDs. The node waits until the Keeper gives it new network
and port parameters and brings it OnLine.
ControlNet Object
If already OnLine the Rogue interrupt is enabled and the LED

should be solid green. If Rogue is detected the node goes to the
ListenOnly state, and forces the Railroad Red LED display; this
requires the default ASIC LED behavior in ListenOnly mode to
be overridden.
5154
Note 5: At Powerup, when going OnLine, if a Dup node is

detected enter the Dup ListenOnly state; the default ASIC action is
to display Railroad Red on the LEDs. If already OnLine, a Dup
node powering up should detect the Dup condition and go to the Dup
ListenOnly state (showing the Railroad Red LEDs). If two links are
joined, the first node to hear the other should go to the Dup
ListenOnly state; the remaining node should not be affected. Nodes
in the Dup ListenOnly state will remain there with Railroad Red
LEDs until a Reset to the Identity Object is received or power is
interrupted. A Reset to the Identity Object will force the node to
perform its Powerup sequence.
Note 6: No special action is required to handle a Lonely condition;
the Lonely interrupt may be enabled or disabled. The default action
of the ASIC is to display a Flashing Red LED.
At Powerup, if the node is Lonely, the LEDs will change from
flashing green (ListenOnly) to flashing red.
If already OnLine, and you go Lonely, the LEDs will change form
solid green to flashing red.
Note 7: Health LED behavior:
The Health LED should:
be solid green when connections are active

flash red for a recoverable error
display solid red for a non-recoverable error
When in the ListenOnly state the Health LED should be blinking
green, indicating lost connection, since connections are broken in
ListenOnly.
If the ASIC goes Rogue with Railroad Red LEDs, the Health LED
should be flashing green.
ControlNet Object
If the ASIC goes DUP withe Railroad Red LEDs, the Health LED
should be flashing red, indicating a fix configuration condition.
5155
The ControlNet Object has four operational states. Each state allows
different services to be invoked and different attributes to be set.
1. NonExistent The ControlNet Object is in an unknown
condition. After powerup the ControlNet Object enters the
ListenOnly state.
2. ListenOnly The ControlNet Object waits for its network
configuration parameters, other than the MAC ID. These
parameters are obtained either directly from a local host (the host
has this information in persistent storage), or over the network
from a keeper (either Temporary or Real). The keeper sends this
information via the Set_Single service request to the ControlNet
Object. The Set_Single service transitions the ControlNet Object
into the OnLine state.
3. OnLine ControlNet network communication is enabled. The
host may initiate or respond to its own connect request messages.
The Reset service transitions the ControlNet Object into the
ListenOnly state. The ControlNet Object accepts all its services
while in this state.
ControlNet Object
4. Dup ListenOnly Dup Node error state. Nodes in the Dup

ListenOnly state will remain there with Railroad Red LEDs (the
default ASIC LED behavior) until a Reset to the Identity Object
is received or power is interrupted. A Reset to the Identity Object
will force the node to perform its Powerup sequence.
5156
Listen-Only Network Parameters

Whenever the ControlNet Object transitions to the Listen-Only state,
the ControlNet Object sets its own current_config attribute to the
values (expressed as decimal) found in the following table.
ControlNet
Data Type
Value of Attribute
pit_time
UINT
10000 (10 ms ticks)
smax
USINT
0 (no scheduled token rotation)
umax
USINT
107 (maximum unscheduled token MAC ID)
slot_time
USINT
131 ms
blank_time
USINT
6 (1.6 ms byte times)
gb_start
USINT
49 (10 ms ticks)
gb_center
USINT
33 (10 ms ticks)
redundancy
BYTE
2 (enable channel A)
sched_max_frame
USINT
0 (no scheduled traffic)
int_cnt_mod
USINT
255 (fixed)
gb_prestart
USINT
68 (10 ms ticks)
macrocycle_start
USINT
0 (macrocycle starts on first NUT)
macrocycle_length
USINT
0 (single NUT macrocycle)
macrocycle_count
USINT
0 (disable Tx during scheduled portion of NUT)
BYTE
0 (fast data production rate equals slow rate)
Unique_id
UDINT
0 (value dont care)
status_flag
UINT
0 (invalid TUI)
state
UINT
0 (listen-only state)
ControlNet Object
Name
5157
Synchronization of Attributes
The ControlNet Object uses a two step, double-buffer type
arrangement for changing its configuration. These steps involve
copying its pending_config attribute values to its current_config
attribute values. This allows for the orderly synchronizing of node
operation parameters.
The current_config attribute contains the information for ControlNet
Object functions. The pending_config attribute is used to hold a
copy of the configuration information in preparation for applying it
to the current_config attribute.
Applying a configuration change requires use of the ControlNet
Object specific Sync service. This service causes the
pending_config attribute values to be copied to the current_config
attribute values.
Receiving multiple set_attributes_single requests without receiving a
corresponding Sync request causes the ControlNet Object to write
over its pending_config attribute values. However, there are two
exceptions.
While in the Listen-Only state, after receiving a
Set_Attributes_Single request, the ControlNet Object sets its
pending_config attribute, performs a local Sync and goes On-Line.
While in the On-Line state, the ControlNet Object exhibits specific
behavior regarding its settable attribute. After receiving a
Set_Attributes_Single request while in the On-Line state, the
ControlNet Object does one of the following:
sets its pending_config attribute
sets its pending_config attribute and performs a local Sync
ignores the request
ControlNet Object
This behavior depends on:

the current value of its TUI status_flag sub-attribute
the value of the TUI status_flag in the Set_Attribute_Single
request packet. The table below summarizes this behavior.
5158
Table 51.X
On-Line Set Attribute Behavior
Event
Received Set_Single packet with Received Set_Single packet with

Bit 2 of TUI status_flag = 0
Bit 2 of TUI status_flag = 1
State
Set Pending
Attribute
&
Local Sync
Node is OnLine
and Bit 2 of the
Current ControlNet Object TUI
status_flag = 0
Set Pending
Attribute
Node is OnLine
and Bit 2 of the
Current ControlNet Object TUI
status_flag = 1
Ignore Entire
Set Request
Set Pending
Attribute
Set Pending
Attribute, Local Sync and go
OnLine
Set Pending
Attribute, Local Sync and go
OnLine
Node is ListenOnly
with Loose default
parameters.
(status_flag = 0 or 1)
Note: The TUI field of the pending_config attribute takes effect and
becomes the current_config TUI field immediately after setting the
pending_attribute. The current ControlNet Object state of the TUI
field should be checked before the pending attribute is set.
ControlNet Object
This behavior does not check the valid bit (Bit 0) of TUI status flag.
This behavior assumes that the value of an invalid TUI is all zeroes.
5159
Event Indications
The ControlNet Object provides a local interface for the following
event notifications as defined by the error processing conditions in
the ASIC Reference Manual.
These indications are available in the Listen-Only and the On-Line
states:
Duplicate MAC ID
Lonely
These indications are available only in the On-Line states:
Duplicate MAC ID
Lonely
Rogue Node (Network Configuration Mismatch)
Reset
On Line Change (Sync)
Off Line
The ControlNet Object also provides a local indication when it
transitions from the Listen-Only state to the On-Line state.
All of these event notifications are implementation dependent.
ControlNet Object
The Check_For_Moderator service provided by the ControlNet

Object is used only for Real Keeper and Temporary Keeper
Powerup sequences, to determine if a network exists that can be
joined; otherwise the keepers must attempt to establish a network. A
flow chart for Check_For_Moderator is presented in the figure
below.
5160
Figure 51.7
Check_For_Moderator
Check_for_Moderator
This routine attempts to receive 9 consecutive
Moderator Packets.
Check_for_Moderator
Set Moderator Received to 0
Moderator_received
Enable Reception of Moderators
Is this moderator the same

as the last one?
Y
Get start time
Call Moderator_received
Increment mod_received
Copy this moderator to

last_moderator
mod_received >= 9
or current_time
start_time > 2 ?
Set mod_received to 1
Disable reception
of Moderator.
Return NULL pointers to

MAC ID and Moderator
Parameters; return NULL
pointer to Mod_flag if no
Moderator was detected,
otherwise return a pointer
to a Mod_flag of 1 if at
least 1 Moderator was
detected.
Call Moderator_received
mod_received >= 9?
Y
Get Moderator
Source
ControlNet Object
Return Pointers to the

Moderator MAC ID,
Moderator Parameters
and Mod_flag (which
should be 1).
Return mod_received
5161
And:
Then:
Node is On-Line and Bit 2 of current ControlNet

Object TUI status_flag = 0
received Set_Attribute_Single packet with Bit 2 of

TUI status_flag = 0
Set Pending Attribute


TUI status_flag = 1
Set Pending Attribute and Local Sync
Node is On-LIne and Bit 2 of current ControlNet


TUI status_flag = 0
Ignore Entire Set Request


TUI status_flag = 1
Set Pending Attribute
Node is Listen-Only with Loose default

parameters (status_flag = 0 or 1

TUI status_flag = 0
Set Pending Attribute,

Local Sync and go On-Line
Node is Listen-Only with Loose default

parameters (status_flag = 0 or 1

TUI status_flag = 0
Set Pending Attribute,

Local Sync and go On-Line
ControlNet Object
If:
5162
ControlNet Object
Notes:
Appendix
The Object And Common

Service Definition Process
This appendix contains these sections:
Section
Page
Change History
511
Process For Creating Or Modifying An Object Specification
511
Detailed Object Definition Process
513
Defining ControlNet Common Services
518
Change History
Create and maintain a record of the changes made to the object

specification.
Process For Creating Or

Modifying An Object
Specification
This section documents the process for creating new object

definitions or modifying existing definitions which are visible to
users of the ControlNet messaging protocol.
Introduction to the Object Definition Process

A product is modeled to the communication system as a set of
objects. Each object models some function of the product. To
maximize interoperability, re-use existing objects whenever
possible. Model new functions to the communication system by
using new objects, or modifications to existing objects.
Overview of the Object Definition Process
Use the following steps to create or modify an object definition
(Table NO TAG). These steps are expanded in the section below
titled, Detailed Object Definition Process.
512
The Object And Common Service Definition Process
Table 51.Y
Steps for creating or modifying an object definition
Step
Who
What
When
Product Designer
Identifies need, contacts

Architecture team
Product definition phase
Architecture team
Validates need
Early in product definition

phase
Product Designer
and Architecture
team, jointly
Proposes definition,
identify review team
Early in product definition

phase
Review team
Reviews definition
Following product
definition phase
Product/Project team
Implements definition
During product
implementation
Tests implementation
During project unit test
Architecture team
Releases Specification
with an implementation
At next revision of object

specification
Participants in the Object Definition Process

The following people participate in the object definition process.
Refer to the table above.
Product Designer
The product designer is responsible for producing a plan for the
object definition including capabilities and future enhancements.
Architecture team
The architecture team is responsible for maintaining the object
specification. One person acts as the primary contact point for
the team. This person could also be the editor of the object
specification.
Review team
The review team reviews proposals for new definitions using the
guidelines outlined in the section below titled, Guidelines for
creating or modifying object specifications.
The product/project team is responsible for implementing
products which include the object being defined, as well as
products which will access the object using the ControlNet
messaging protocol.
Detailed Object Definition

Process
513
Refer to the table above, Steps for creating or modifying an object

definition.
1. Identify Need
The product designer identifies the need for a new object. A new
object may be required because:
of a new feature
an existing feature is now visible to the communication
system
As soon as the product designer recognizes that this need is
beyond the currently defined objects, he submits the need to the
architecture team.
2. Validate Need
The architecture team reviews the request, looking for
opportunities to reuse objects already in the object library.
The architecture team uses existing objects by:
generalizing text to make the object usable in more products

interpreting existing objects to make sure that different groups
have not used different terms to describe the same thing
using the latest revisions of all specifications
making sure the requestor understands the purpose of the new
or extended object. For example, the requestor may have
misunderstood that the specified externally visible behavior
was dictating an internal implementation, which he did not
want to provide.
3. Propose Definition
The product designer and the architecture team work together to
propose a definition for the new object or object extension. The
product designer understands the desired function of the object
while the architecture team understands the operation of the rest
of the system and standards that might not be obvious. The
product designer and/or the architecture team edit the first draft.
In parallel with this, an appropriate review team is identified.
Refer to Step 4.
514
4. Review Definition
The review team reviews the definition, looking for areas to
improve interoperability, reusability and verifiability. The review
team uses these three criteria to evaluate proposals for new and
modified objects. Also refer to, Guidelines for creating or
modifying object specification.
interoperability: The ability to use a set of AllenBradley

products to construct a system. This involves how products
communicate with each other.
reusability: The ability to build a new AllenBradley product
by extending a previous design. Our backwards compatibility
requirements usually state that new products must function
with the previous generation of products.
verifiability: The ability to evaluate a product to make sure it
conforms to the specification.
Reviewers include:
those who implement the object in products

those who access the object using the ControlNet messaging
protocol
those who need to understand how a feature is provided
(marketing)
This review may result in changes to the definition.
5. Implement
The first product or project which needs the new object or object
extension will implement the definition. Ways to make the
object easier to implement may change the definition. Consider
prototyping objects to avoid implementation problems.
6. Test Implementation
The project team validates the implementation. These test
implementers are different than the project team members who
did the original implementation. This test implementation may
identify unclear parts of the definition.
7. Release Specification
The architecture team releases the ControlNet Object
Specification for others to use.
515
Guidelines for Creating or Modifying Object Specifications

This section gives you guidelines for creating or modifying objects.
Modularity: Break large objects into smaller objects when
possible without creating interdependencies. See cohesion,
below. For example, break a Controller into Data Table
which can be read and written and Program, which can be
edited.
Cohesion: Dont break an object into multiple objects if this
creates many interdependencies. Keep things that are tightly
coupled in one object.
Information Hiding: Hide those aspects that are not important
to the object being specified. For example, if you can store a set
of data as an array or in a linked list, dont specify one or the
other. Leave the set of data as data storage.
Dont Hide Semantics: Dont hide aspects that are important to
the object being specified. For example, dont write a value to a
special location to cause a mode change. Use an interface that
allows you to clearly state the desired action.
Generalize: Ask, If product A needs an object from product B,
will it also need it from product C in the future? If this is a
possibility, how can I define the object so that it is also useful in
product C?
Expansion: When possible, use variable length fields. You can
extend fields in the future to handle cases not considered today.
Use the numeric value itself instead of encoding the numeric
value into a smaller number of bits, so that unencodable values
which could become necessary in the future do not cause the
specification and implementations to change..
In the lifetime of the object specification, assume:
Addresses will double in length for a given context (from 8
to 16, to 32, to 64 bits).
Product memory sizes (both RAM and ROM) will
quadruple twice.
CPU speeds will double, two or three times. Therefore,
you may want to select an algorithm that is CPU intensive,
but simplifies other aspects, knowing that the next
implementation will be easier.
Configuration options will double twice. Therefore, if a bit
field is over 25% filled with definitions, consider a larger
bit field definition.
Communication links will increase in bit rate.
Costs will continue to drop dramatically.
516
Clarity: Keep all statements, references and terms as clear and

obvious as possible by using meaningful names. Dont add
complexity where not needed.
Scalability: Make sure the object is useful in a wide range of
products. For example, from a controller to a very large
controller.
Optimizations: Consider the following before making the object
definitions more complex.
Performance optimizations: There are very few areas in
a system that need performance optimization. Locate any
performance optimizations and optimize the rest of the
system for easy reuse and expansion. Rather than looking
at fine tuning one aspect of a design, look at the overall
design for a completely different algorithm or paradigm
that might result in a large improvement. For example:
-Instead of creating a complex interface to make an
interpreter run 10% faster, use an incremental compiler
that can run 500% faster.
-Instead of making a message two bytes shorter, decide
whether the message can be avoided completely.
Cost optimizations: Use a different partitioning of
functions. This can often save more than changing how a
function is implemented in a product. For example, dont
add complex encodings to save RAM. Instead, eliminate
the need to store the item.
Rules for Modifying an Object Specification
Objects in this specification have a version associated with them.
The version of an object specifies the interface to that object. The
interface of an object includes all of the items in this specification
including services, attributes, connections and behavior. The version
is not the version of an implementation, but the version of the
specification the implementation is designed to meet.
The version of an object is accessible by a user of the object through
a class attribute of the object.
The version of an object in the server device may be different from
the version expected by the client. Differences between object
versions must therefore be documented in the objects definition.
The effects of these differences on servers and clients must also be
documented in the object definition.
517
Following are rules for creating a new version of an object

definition. The new version of an object definition:
cannot modify data type definitions of existing attributes
cannot delete previously defined attributes
cannot change the attribute numbers of previously defined
attributes
can add new attributes after the last attribute in the most recent
definition
can only add to the end of the Get_ Attributes_ All and the Set_
Attributes_ All structure definitions
must fully define any requirements for the new server, to
accommodate old clients
can only add to the list of accepted services
Following are rules for clients interfacing with different versions of
server objects:
The client is not required to determine the version of a server
object before building the request message.
When the client receives an error due to a version mismatch, the
client can:
report the version mismatch with an error handler, or
determine the version of the servers object and perform
special case processing. This could include an error
handler.
The server follows the rules specified for the object version
implemented in the server. These rules include the use of the
attribute values for object state transitions and for responding to the
services defined for the object. The server does not need to
understand the rules for other versions of the object.
The server objects are not required to perform any special function
other than verifying that their attribute values are correctly defined
for a transition to run mode. These requirements for the transition to
run mode are object specific and must be defined in the object
definition. The verification of attributes is divided over the set,
apply and start services. The set services verify individual attribute
values. The apply and start services verify all attribute values for a
transition to run mode.
518
Defining ControlNet
Common Services
The ControlNet common services are those services that all

objects in a ControlNet system can request or respond to when
the service parameters and general implementations are used.
Any object or class-specific services are documented in the relevant
object description.
Consider the basic requirements listed below when defining any
ControlNet services, whether they are common to all of ControlNet
or specific to an object or class:
1. Error conditions pertaining to variably sized request and response
buffers must be considered for all services. The maximum size of
the request and response buffers depends on both the customers
ControlNet system implementation and the ControlNet network
involved.
2. A semaphore locking mechanism must be implemented for all
services that allow fragmentation of primitive data types over
multiple requests and/or responses. In addition, a semaphore
locking mechanism must be implemented for every object that
supports indivisible operations, such as program loads and
structure writes.
3. All parameter data transmissions are in the compact encoding
scheme specified in Chapter 18, ControlNet Data Management, of
this document.
4. All service request and response messages are structured using
the general structures defined in this chapter.
519
How Services are Processed by Objects Whose Versions Differ

Object version differences must also be considered when defining
ControlNet common services. These differences can disrupt the
required processing of the common service requests and responses.
Table NO TAG. shows how common services are processed by
objects whose versions do not match the version expected by the
client. Only those common services that are affected by differences
in object versions are listed in the table.
Table 51.Z
Service Processing for Object Version Conflicts
Service
Version Conflict
Server Processing of
Request
Client Processing of Response
Get_Attributes_All
More data in response

than expected by client
er ion of object (client
client is
i
version
older than server)
Respond with the data defined

for the Get_Attributes_All
re pon e structure
tructure definition of
response
the object version implemented
in the server
Perform error handling for version

mismatch
Less data in response

than expected by client
version
er ion of object (client
client is
i
newer than server)

re pon e structure
response
in the server

mismatch
More data in request than

expected by server
version of object (server is
older than client
client)
Modify attributes defined for the

object versions
Set_Attributes_All request
structure
tructure from the data supplied
upplied
and report too much data error
in service response message

mismatch
Less data in request than

expected by server
version of object (server is
ne er than client)
newer
client

servers object versions
Set_Attributes_All request
structure
tructure from the data supplied
upplied
and report not enough data
error in service response
message

mismatch
Illegal attribute value for

server version of the
object
Respond with invalid attribute

value error in service response
message
Object-specific behavior for

errored attribute
Set_Attributes_All
Determine version of object and

perform special case processing



Get_Attributes_List
Attribute does not exist in Respond with undefined

the server version of the
attribute error in service
object (server is older than response message
client)

errored attribute
Set_Attributes_List

client)

errored attribute

object

errored attribute
Get_Attribute
Get_Attribute_More

message

client)

errored attribute
5110
Service
Set_Attribute
Set_Attribute_More
Set_Attribute_More_Continued
Set_Attribute_More_Complete
Version Conflict
Server Processing of
Request
Client Processing of Response
Access of attribute 0
generates more data in
re pon e than expected
response
by client version of object
(client is older than server)

re pon e structure
response
in the server

mismatch
generates less data in
response than expected
by client version
er ion of object
(client is newer than
server)

for the Get Attributes All
response structure definition of
the object version
er ion implemented
in the server

mismatch



client)

errored attribute

object

errored attribute

message

client)

errored attribute

object

message

errored attribute
generates more data in
request than expected by
server
er er version
er ion of object
(server is older than client)

object versions Set Attributes
All request structure from the
data supplied
upplied and report too
much data error in service
response message

mismatch
generates less data in
request than expected by
server
er er version
er ion of object
(server is newer than
client)

object versions Set Attributes
All request structure from the
data supplied
upplied and report not
enough data error in service
response message

mismatch


Appendix

This appendix explains both transport and application connections.
Just as network connections provide the basis of transport
connections, transport connections are the basis of application
connections. Once the network layer has formed the connections of
producers to consumers, the next layer is to connect the transports to
the producers and consumers.
This appendix contains these sections:
Section
Transport Connections
Page
512
Components Of Transport Connections
513
Creating Transport Connections
519
Transport Classes
5113
Transport Class 1
5113
Transport Class 3
5121
Unconnected Message Manager
5133
Interoperability Of Transport Classes
5148
Transport Classes And Network Connections
5148
5154
Polling
NO TAG
512
Transport And Application Connections
Transport Connections
A transport connection is a logical binding between two transport

instances that is made to enable two applications to transfer data over
network connections. A transport instance is a specific
implementation of a transport function. Every transport connection
is built on one or two network connections. Figure 51.8 uses the
ControlNet communication model to show the context in which
ControlNet transport connections are made.
Figure 51.8
Context of Transport Services within ControlNet
Communication Model
Input
Upload
Upload
Download
Scanner
Application
Connection
Manager
Message
Router
Data Buffer
Transport
Transport Services
UCMM
Network
Network Connections
Link/Physical
ICN
ICP
IDN
In the example shown below, application A interfaces to a client

transport instance to trigger the production of data over the network
connection, and application B interfaces to a server transport
instance to be notified that data has been written to the transport
protocol data unit (T-PDU) buffer. A T-PDU comprises one packet
of data as well as its link, network, and transport headers. A T-PDU
buffer is a memory location in which one T-PDU can be stored.
Figure 51.9
Application-to-Application View of Data Transfer
Client
Transport
Send
Link
Producer
TPDU Packet
Link
Consumer
Trigger
Application
A
Transport
Header
TPDU Packet
TPDU Buffer
TPDU Packet
Server
Transport
Data Arrived
Transport
Header
TPDU Buffer
Data
Packet
Arrived
Data
Application
B
513
Data is not directly written to or read from the transport instances:

data is sent to or removed from the T-PDU buffers. The client and
server transport instances are responsible only for managing the
transport headers of the data packets in the T-PDU buffers.
Important:
Producers, consumers, and transport instances do not

have public interfaces. They are accessible only through
the connection manager that creates them.
Tools Used to Discuss Transport Services

The following detailed descriptions adhere as closely as possible to
the methods described in the Strategies for RealTime Systems
Specification text by D. J. Hatley and I. A. Pirbhai. The Mealy
model has been used for the state transition diagrams. These
methods should be consistent with Cadres Teamwork tool that is
available within AllenBradley.
Components Of Transport
Connections
A transport connection includes the transport instance(s), the clientand server-side T-PDU buffer(s), and the network connection(s)
involved. The network connection, in turn, includes the link
producer(s) and link consumer(s). The originating application is
responsible for creating all of the above components, and for
creating bindings between those components that result in the desired
transport connection being created.
Network Connections
A logical binding between a producer and consumer forms a network
connection. This connection is established by the connection
manager. The connection manager defines the fixed path that the
message will take. When a producer wants to send a message, it will
provide just the connection ID. The connection ID will imply the
path that the connection manager specified. Because of this implied
route, no addressing or routing information other than the connection
ID is used at run time.
The connection ensures data integrity from the producer to the
consumer. While data integrity is ensured between producers and
consumers, whether it is maintained at the end nodes is the
responsibility of the module developer. This aspect of behavior is
beyond the definition of producers and consumers. It is dependent
on the implementation. Only those aspect of behavior that deal with
interoperability are described in this section.
514
There is no queuing of data along a network connection. Overwrites

are permitted at all intermediate nodes. Those applications that
require queuing must use an appropriate transport class (i.e., class 3)
to deliver this behavior.
Link Producer
The link producer is responsible for fetching data from the data
buffer and producing it on the data link after the send event has been
received. Data buffer management schemes such as overwrite,
double buffered, triple buffered are not excluded, but since they are
implementation specific, they are not specified here.
Data Flow Diagram (DFD)
Note that the link producer reads the TPDU packet from the
TPDU buffer and transmits it unchanged. While the TPDU buffer
is shown as a single buffer in the DFD, it does not imply that the
transport header and the data are stored in consecutive locations.
There are no restrictions on actual implementations. An
implementation that stored the transport header and data in
nonconsecutive locations is permitted as long as the link producer
can find all parts of the TPDU packet.
Figure 51.10
Data Flow Diagram for a Link Producer
Client
Transport
Trigger
Link
Producer
Send
Transport
Header
Server
Transport
Link
Consumer
Packet
Arrived
TPDU Packet
Application
Data
TPDU Packet
TPDU Buffer
TPDU Packet
Data Arrived
Transport
Header
Application
TPDU Buffer
Data
The application, not the link producer, is responsible for ensuring

that the TPDU buffer has been initialized before the first trigger has
been issued.
515
State Transition Diagram (STD)

Nonexistent
Create
Running
Delete
1
Send/
Produce TPDU
State Event Matrix (SEM)

State
Nonexistent
Running
Create
Transition to Running
Error
Delete
Error
Transition to Nonexistent
Send
Error
1) Produce TPDU
Event
Services
Create Create instance of a link producer.

Delete (Optional) Delete instance of a link producer.
Send Produce the TPDU buffer.
Attributes
Production ID [Implementation Specific Size]

Priority [URGENT, HIGH, MEDIUM, LOW]
Connection Size UINT
Destination Type [POINTTOPOINT,MULTICAST]
State UINT
Link Consumer
The link consumer is responsible for receiving TPDU packets,
storing them in the TPDU buffer and notifying the server transport
class that a packet has arrived. Data buffer management schemes
such as overwrite, double buffered, triple buffered are not excluded,
but since they are implementation specific, they are not specified
here.
516

Note that the link consumer writes the TPDU packet unchanged to
the TPDU buffer. While the TPDU buffer is shown as a singe
buffer in the DFD, it does not imply that the transport header and the
data are stored in consecutive locations. There are no restrictions on
actual implementations. An implementation that stored the transport
header and data in nonconsecutive locations is permitted as long as
the consumer can find both parts of the TPDU packet.
Client
Transport
Trigger
Link
Producer
Send
Transport
Header
Application
Data
TPDU Packet
Server
Transport
Link
Consumer
Packet
Arrived
TPDU Packet
TPDU Buffer
TPDU Packet
Data Arrived
Transport
Header
Application
TPDU Buffer
Data

Nonexistent
Create
Receive TPDU/
Store TPDU
Packet Arrived
Running
Delete

StateEvent
Nonexistent
Running
Create
Error
Delete
Error
Receive TPDU
Error
Store TPDU
Packet Arrived
Services
Create Create instance of a link consumer.

Delete (Optional) Delete instance of a link consumer.
517
Attributes
Consumption ID [Implementation Specific Size]

Priority [URGENT, HIGH, MEDIUM, LOW]
Connection Size UINT
Destination Type [POINTTOPOINT,MULTICAST]
State UINT
Triggers
A trigger will cause data to be sent. This trigger can be anything that
makes sense from an application point of view, such as a clock on a
module, a network trigger, a scheduler, an asynchronous event, or a
timer.
Figure 51.11
Triggers
Clock
Network trigger
Trigger
Client
Transport
Instance
Scheduler
Asynchronous event
Timer
Important:
The writing of data to the buffer and triggering of that

data are separate functions. An application may write
to a buffer more often than it triggers data to be sent or
trigger data more often than it writes to the buffer.
Applications must write data to the data buffer before it
is initially triggered to ensure that valid data is sent.
TPDU Buffer
The TPDU buffer contains a TPDU packet. The TPDU packet
consists of a transport header and data. Applications will write data
to and read data from the TPDU buffers directly. Instances of
transports will write and read the transport header in the TPDU
buffer while consumers will write data to the TPDU buffer and
producers will read data from the TPDU buffer. The TPDU
buffers and buffer management are not part of the ControlNet
communication services.
518
Figure 51.12
TPDU Buffer
Client
Transport
Trigger
Link
Producer
Server
Transport
Link
Consumer
Packet
Arrived
Send
Transport
Header
TPDU Packet
Application
Data
TPDU Packet
TPDU Packet
TPDU Buffer
Data Arrived
Transport
Application
Header
TPDU Buffer
Data
TPDU Buffer Management

TPDU buffer management is implementation specific.
Implementations that use single buffering, double buffering,
overwrite or queueing to manage TPDU buffers are all allowed
Implementors are responsible for ensuring buffer integrity (atomic
access).
Applications are responsible for ensuring that the buffer has been
initialized before a trigger is issued. Failure to initialize the buffer
will allow unknown data to be sent. This is true for producers and
the client and servers sides.
Transport Header
The transport header is 16 bits. In transport classes 13, the transport
header is a 16bit sequence count, class 0 has a dont care in this
field. The transport header is written to the TPDU buffer by the
transport and is read by the transport from the packet coming from
the consumer. The sequence count for classes 1-3 is 16 bits for two
reasons:
11 bits of sequence count would allow production rates between 1
msec and 2 seconds without aliases, or a 2000 to 1 difference in
rate. 16 bits allows a 65000 to 1 difference in rate (.1 msec to 6.5
sec).
ControlNet is word aligned. ICP is long word aligned. A
sequence count less than 16 bits would provide very little saving
in cost or improvement in performance.
519
Classes 1,2, and 3

Table 51.AA
Class 13 Transport Header
Sequence Count, 16 Bits
TransportProtocolHeader2 ::= WORD {LSB(0),MSB(15)

}
Notification
Transport classes can signal the application through events. The valid
events are listed in Table NO TAG.
Table 51.AB
Notification
Client
E ent
Event
Class 1
Server
Class 1
Class 3
Data Arrived
Class 3
Duplicate Arrived
Acknowledgment
Verification
"
Creating Transport
Connections
A Duplicate Arrived event is normally not of interest to the

application; however, it might be useful in triggering a watchdog
timer to indicate that the clients application is alive and triggering.
After the application has bound the producer to the consumer at the
network layer of the ControlNet communication model, the
application creates the transport connection by binding the producer,
consumer, and T-PDU buffer(s) to the transport instances at the
transport layer. An application can support as many transport
connections as resources RAM, ROM, CPU, EEPROM, etc.
permit.
The simplest transport functions use a single network connection,
which can be either point-to-point or multicast; the more complex
transport functions also use one or more point-to-point return
network connections. The transport functions correspond to the
transport classes defined for ControlNet. Each transport class
provides a specified level of transport services.
5110
Binding Transports to Producers and Consumers of Network

Connections
The binding rules followed to create ControlNet transport
connections are listed below:
A client transport instance is bound to exactly one producer
instance.
A client transport instance can be bound to zero, one, or many
consumer instances.
A server transport instance can be bound to zero or one producer
instances.
A server transport instance is bound to exactly one consumer
instance.
A server transport instance can be bound to a producer instance
and a consumer instance, but can not be bound to a producer
instance without also being bound to a consumer instance.
The examples below demonstrate application of the binding rules to
different kinds of transport connections that include network
connections with different destination types.
For a point-to-point connection that does not have a reverse
data path, the producer is bound to the client transport instance
and the consumer is bound to the server transport instance. The
figure below illustrates this scenario.
Figure 51.13
Binding Transport Instances to the Producer and Consumer
of a Transport Connection that Does Not Have a Reverse
Data Path
Client Application
Client
Transport
Producer
Consumer
Server
Transport
Server
Application
For a point-topoint connection that does have a reverse data

path:
In the client-to-server direction, the producer is bound to

the client transport instance, and the consumer is bound to
the server transport instance.
In the server-to-client direction, the producer is bound to
the server transport instance, and the consumer is bound to
the client transport instance.
5111
The figure below illustrates this scenario.

Figure 51.14
Binding Transport Instances to the Producers and
Consumers of a Transport Connection that Does Have a
Reverse Data Path
Producer
Client
Application
Consumer
Client
Transport
Server
Transport
Consumer
NOTE:
Server
Application
Producer
In this configuration, the transport connection includes:

1) the client and server transport instances
2) the network connections, including the producers and
consumers in both the client-to-server and server-to-client
directions.
For a multicast connection that does not have a reverse data

path, the producer is bound to the client transport instance, and
each consumer is bound to a separate server transport instance. It
is important to note that there is only one client transport
instance, and there are as many server transport instances as
there are client-to-server network connections.
Figure 51.15
Binding Transport Instances to the Producer and
Consumers of a Multicast Connection When the Transport
Connection Does Not Have a Reverse Data Path
Client
Application
NOTE:
Client
Transport
Producer
In this configuration, there are two transport

connections: one from client transport to producer to
consumer A to server transport A, and one from
client transport to producer to consumer B to server
transport B.
Consumer A
Server
Transport
A
Server
Application
A
Consumer B
Server
Transport
B
Server
Application
B
5112
For a multicast connection that does have a reverse data path:

In the client-to-server direction, the producer is bound to
the client transport instance, and each consumer is bound
to a separate server transport instance.
In the server-to-client direction, each producer is bound to
a separate server transport instance, and each consumer is
bound to the client transport instance. It is important to
note that there is only one client transport instance, and
there are as many server transport instances as there are
client-to-server network connections.
Figure 51.16
Binding Transport Instances to the Producers and
Consumers of a Multicast Connection When the Transport
Connection Does Have Reverse Data Paths
Node #1
Node #2
Producer
A
Client
Application
Consumer
A
Client
Transport
Server
Transport
A
Consumer
B
Server
Application
Producer
B
Consumer
D
Node #3
Consumer
C
NOTE:
In this configuration, there are two transport

connections:
D one from the client transport to producer A to
consumer A to server transport A to producer B to
consumer B to the client transport
D
one from the client transport to producer A to
consumer C to server transport C to producer D to
consumer D to the client transport.
Server
Transport
C
Producer
D
Server
Application
Transport Classes
5113
Applications interface to transport services through the supported

transport classes. The figure below lists the four general-purpose
transport classes that have been defined for ControlNet systems.
Each transport class provides a different level of functionality.
Table 51.AC
General-Purpose ControlNet Transport Classes Defined to
Date
Class Number
Class Name
Duplicate Detection
Verified
Transport class 1 builds on the behavior of transport class 0, and

transport class 3 builds on the behavior of transport class 1.
Transport class 3 has DeviceNet counterparts designated transport
class 3d. Because of DeviceNets 8-byte maximum packet size, it
does not support the sequence count in transport class 3d.
It is the responsibility of the originating application to determine
which transport class best suits its needs for a particular data transfer.
Transport Class 1
(Duplicate Detection)
Transport class 1 uses either a point-to-point or multicast connection.

A class 1 transport header includes a sequence count, which is used
to detect the delivery of duplicate data packets. The Class 1 target
application does not have to perform duplicate detection, which
reduces the overhead required in that end node. This class was
designed to allow change of state data transfers.
The figure below shows the actions which take place during data
transfer using a class 1 client transport instance and a class 1 server
transport instance.
Figure 51.17
Data Flow Diagram Using Client Transport Class 1 and
Server Transport Class 1
Write
Client
Transport
Class 1
Trigger
Send
Transport
Header
Application
Link
Producer
T-PDU
Packet
T-PDU
Packet
Link
Consumer
T-PDU
Packet
TPDU Buffer
Data
Packet
Arrived
Transport
Header
Server
Transport
Class 1
Dupl.
Arrived
Data
Arrived
Application
TPDU Buffer
Data
NOTE:
The T-PDU packet comprises the transport
header from the client transport and data
from the application.
5114
The figure below shows the sequence in which actions take place
when transferring data using client transport class 1 and server
transport class 1. Note that the sequence count is incremented with
every write. Also note that in the case where the packet is lost on a
new data sample, and the packet is later triggered and sent. This data
received by the client is treated as new data. This is because this is
the first time the server has received this sequence count. This
mechanism provides fault tolerance for those samples that change
infrequently.
Figure 51.18
Sequence Diagram of Data Transfer Using Client Transport
Class 1 and Server Transport Class 1
Application
Client
T1
Producer
Consumer
Server
T1
Application
Write to
Data Buffer
Trigger
Send
Seq. Cnt = 1, Data
Update Data
Buffer
Data Arrived
Write to
Data Buffer
Write to
Data Buffer
Trigger
Send
Seq. Cnt = 3, Data
Update Data
Buffer
Data Arrived
Trigger
Send
Seq. Cnt = 3, Data
Update Data
Buffer*
Dup. Arrived
Write to
Data Buffer
Packet Lost
Trigger
Send
Seq. Cnt = 4, Data
Trigger
Send
Seq. Cnt = 4, Data
Update Data
Buffer
Data Arrived
Implementors must decide whether to update the data buffer upon receipt of duplicate data packets,
since they can best assess the impact of the additional processing.
5115
Class 1 Client Transport

Transport class 1 starts with the behavior in class 0 and adds a
sequence count. This sequence count is incremented by the client
transport class when data is written to the data buffer. When the
transport receives a write event, it will increment the sequence count.
When a trigger event is received the transport will update the
sequence count in the TPDU buffer and invoke the send service.
Applications could use this transport class to distinguish between
new samples and old samples that were sent to maintain the
connection. To maintain the connection, a timer may be used to
trigger the production of the current data in the TPDU buffer. To
transmit new data the application would first write to the TPDU
buffer and then trigger the client transport.
A class 1 client transport is responsible for:
Accepting the client applications trigger that it has written a data
packet to the client-side T-PDU buffer
Writing a transport header to the T-PDU buffer for each packet
that the client application writes to the client-side T-PDU buffer
(NOTE: The transport header for each packet must include a
sequence count.)
Initializing the sequence count in the transport header (for the
first packet transmitted) or incrementing the sequence count (for
subsequent packets of the same transmission)
Triggering the producing node of the network connection to
produce the T-PDU packet on the link and send it to the
consuming node of the network connection
Nonexistent
Create/
Seq. Cnt = 0
Idle
Delete
Start
Stop
Running
Write/
Seq. Count =
Seq. Count + 1
Trigger/
Store Seq. Cnt. in TPDU Buffer
Send
5116
The sequence count is set to 0 by the create service. It is then

incremented after every write event until it reaches a maximum value
of 2161. After that it rolls over to 0.
State Event Matrix
State
Event
Nonexistent
Idle
Running
Create
1) Transition to Idle
2) Set seq. count = 0
Error
Error
Delete
Error
Transition to Non Error

existent
Start
Error
Error
Stop
Error
No Action
Transition to Idle
Write
Error
No Action
1) Seq. Cnt = Seq.

Cnt + 1
Trigger
Error
No Action
1) Store Seq. Cnt.

in TPDU Buffer
2) Send
Services
Create Create instance of client transport class 1.

Delete (Optional) Delete instance of client transport class 1.
Write This service is invoked when data is written to the data
buffer. It will cause the sequence count to be incremented.
Trigger This service is invoked when the data in the TPDU
buffer is to be sent. It will store the current sequence count in the
TPDU buffer and invoke the send service in the producer.
Start Transition to running state.
Stop Transition to idle state.
Attributes
State UINT [0 Nonexistent, 1 Idle, 2 Running]

Sequence Count UINT
Class 1 Server Transport
Transport class 1 starts with the behavior in class 0 and adds a
sequence count. The received sequence count is compared with the
previous sequence count. If they are equal, the received packet is
considered to be a duplicate packet. If they are not equal, the
received data is considered to be a new sample. There is no attempt
to count how many sequence counts have changed between samples.
5117

connection. To maintain the connection, the data arrived and
duplicated arrived events may be ORed together to reset a timer. If
this timer were to expire, the application would know that no data
was received within the designated time. The data arrived event
would identify new samples of data. This may allow applications to
reduce their overhead by only processing new data samples.
A class 1 server transport is responsible for:
Accepting the notification from the consuming node of the
network connection that it has written a data packet to the
server-side T-PDU buffer
Locating and reading the transport header of each packet that the
consuming node of the network connection writes to the
Triggering the server application that data has been written to the
Comparing the sequence count of each packet with that of the
previous packet
Notifying the server application that the most recently arrived
packet is a duplicate of the previous one when their sequence
counts match
Nonexistent
Create
Delete
Idle
Stop
(From any state)
Start
Ready to Run
Reset
Packet Arrived
Data Arrived Notify = TRUE/
Notify: Data Arrived
Running
Packet Arrived
THeader =
Seq. Count
Dup. Arrived Notify = TRUE/
Notify: Dup. Arrived
Packet Arrived
Data Arrived Notify = FALSE
Packet Arrived
THeader <>
Seq. Count
Data Arrived Notify = TRUE/
5118
State Event Matrix

State Event
Nonexistent
Idle
Ready to Run
Running
Create
Transition to
Idle
Error
Error
Error
Delete
Error
Transition to
Nonexistent
Error
Error
Start
Error
Transition to
Ready to Run
Error
Error
Stop
Error
No Action
Transition to Idle
Transition to Idle
Reset
Error
Error
No Action
Transition to Ready to
Run
Packet Arrived
Transport Header <> Seq. Count
Data Arrived Notify = TRUE
Duplicate Arrived Notify = TRUE
Error
No Action
Packet Arrived
Transport Header = Seq. Count
Error
No Action
Notify: Duplicate Arrived
Packet Arrived
Duplicate Arrived Notify = FALSE
Error
No Action
Packet Arrived
Error
No Action
No Action
Packet Arrived
Error
No Action
No Action
Packet Arrived
Error
No Action
Notify: Duplicate Arrived
Packet Arrived
Error
No Action
No Action
Packet Arrived
Error
No Action
No Action
Services
Create Create instance of server transport class 1.

Delete (Optional) Delete instance of server transport class 1.
Reset (Optional) Transition to ready to run. (Accept next packet
as new data)
Start Transition to ready to run state.
5119
Attributes
Data Arrived Notify [TRUE, FALSE]

Duplicate Arrived Notify [TRUE, FALSE]
State UINT [0 Nonexistent, 1 Idle, 2 Ready to Run, 3
Running]
Sequence Count UINT
Transport class 1 can be used in conjunction with a heartbeat timer to
keep a connection open when there are periods when no data is
transmitted. The heartbeat timer must be initialized every time the
producing node of the network connection transmits a packet, and
must be set so that its maximum value, or the maximum time
between data transmissions, is less than the path time-out value for
the network connection. When the heartbeat timer reaches its
maximum value, it triggers the client transport instance so that the
producing node produces and retransmits the packet in the client-side
T-PDU buffer before the connection times out. The consuming node
of the network connection, recognizing that the packet has the same
sequence count as the last packet it received, may or may not
overwrite the packet in the server-side T-PDU buffer; that
implementation decision is left to the product developers, since they
can best assess the impact of additional processing.
connection. To maintain the connection, a timer may be used to
trigger the production of the current data in the TPDU buffer. To
transmit new data the application would first write to the TPDU
buffer and then trigger the client transport.
connection. To maintain the connection, the data arrived and
duplicated arrived events may be ORed together to reset a timer. If
this timer were to expire, the application would know that no data
was received within the designated time. The data arrived event
would identify new samples of data. This may allow applications to
reduce their overhead by only processing new data samples.
Possible uses of transport class 1 include sampled inputs, standard
outputs, cyclic block transfers, diagnostic events, and
communication between controllers and operator interface devices.
Table C.A shows how the transport classes map to specific product
functions.
5120
Table 51.AD
How Products Use Transport Services
Connection Type
Transport
ransport
Class
Product Use
se
Client>Server
Pt-Pt/Multicast
Server>Client
Pt-Pt/Multicast
1
3
3
Multicast
Multicast
Multicast
None
Pt-Pt
Pt-Pt
Scheduled
High
High
Fixed
Fixed
Fixed
No
No
No
1
3
Pt-Pt
Pt-Pt
None
Pt-Pt
Scheduled
High
Fixed
Fixed
No
No
Block Transfer Read

(Cyclic)
Pt-Pt
None
Scheduled
Fixed
No
Block Transfer Write

(Cyclic)
Pt-Pt
None
Scheduled
Fixed
No
Block Transfer Read

(Asynchronous)
Pt-Pt
Pt-Pt
High
Variable
No
Block Transfer Write

(Asynchronous)
Pt-Pt
Pt-Pt
High
Variable
No
1
2
3
1
2
3
Multicast
Multicast
Multicast
Multicast
Multicast
Multicast
None
Pt-Pt
Pt-Pt
None
Pt-Pt
Pt-Pt
Low
Low
Low
Low
Low
Low
Fixed
Fixed
Fixed
Fixed
Fixed
Fixed
No
No
No
No
No
No
Master/Slave (DeviceNet)
2d, 3d3
Multicast
Pt-Pt
High
Fixed
No
Diagnostic Events
Multicast
None
Scheduled
Fixed
No
Event
Acknowledgement
(Message)
Pt-Pt
Pt-Pt
Low
Variable
Yes
Messages
Pt-Pt
Pt-Pt
Low
Variable
Yes
Upload/Download
Pt-Pt
Pt-Pt
Low
Variable
Yes
Connection
Establishment
UCMM4
Pt-Pt
Pt-Pt
Low,
High
Variable
No
Inputs
Sampled
Change of State
Processor Input
Interrupt (PII)
Outputs
Standard
Time-Coordinated
Controller to Operator
Interface1
Inputs
Outputs
Priority
Variable/
Fixed Size
Retry
Timer
Controller to Controller2
Inputs
Outputs
Parameters for controller to operator interface inputs and outputs are not defined as of 20 September 1993. This list is a
sample of possible uses only.
Parameters for controller-to-controller inputs and outputs are not defined as of 20 September 1993.
Transport classes 2d and 3d are DeviceNet implementations of transport classes 2 and 3, respectively.
Transport class Unconnected Message Manager (UCMM) is limited to a single link; it is not a general-purpose transport
service. There can be only one UCMM transport instance per port.
Transport Class 3
(Verified)
5121
Transport class 3 starts with the behavior in class 1 and adds a return
connection that verifies that the application has received the packet.
The sequence count that is returned with the verify is the same as the
sequence count sent with the data. This return connection is used to
identify the verification message.
This transport class allows the application to be notified that the
server application has responded to the transmitted packet. This
verification tells the client application not only that the data arrived
but that the server application has read the buffer and that a new
sample can be sent without overwriting the buffer.
The main advantage of this class over class 2 (Acknowledgement) is
that verification conveys an application response. The disadvantage
is that the delay in receiving the verification can be very difficult to
predict.
Transport class 3 uses two connections: the originator-to-target
connection, which can be either point-to-point or multicast; and the
return connection, which must be point-to-point. A multicast
connection using transport class 3 must have a point-to-point return
connection corresponding to each client-to-server connection. The
verification notifies the client application that the server application
has received and read the transmitted data. If a server application
does not verify receipt of the packet, the client application
retransmits the most recently sent packet; if the client-to-server
connection is a multicast, the data is retransmitted over all of the
network connections of the multicast.
The server application initiates and sends the verification after the
consuming node of the network connection has written the packet to
the T-PDU buffer, after the transport has read the packets transport
header, and after the application has read the packet. The servers
verification signals the client application that the server-side T-PDU
receive buffer is ready to accept the next data packet.
The figure below shows the actions which take place during a data
transfer using client transport class 3 and server transport class 3.
5122
Figure 51.19
Data Flow Diagram Using Client Transport Class 3 and
Server Transport Class 3
TPDU Buffer
TPDU Buffer
TPDU
Packet
Write
Verify
TPDU
Packet
Link
Consumer
Send
Trigger
Application
Link
Producer
Transport
Header
Data
TPDU
Packet
Client
Transport
Class 3
Data
Transport
Header
Packet
Arrived
Packet
Arrived
Transport
Header
Data
Arrived
Server
Transport
Class 3
Send
Link
Consumer
TPDU
Packet
TPDU
Packet
TPDU Buffer
Link
Producer
Data
Transport
Header
Dupl
Arrived
Verify
Application
Data
TPDU
Packet
TPDU Buffer
NOTES:
1 The client and server transports each use
two buffers: one for transmitting, and one
for receiving.
2 The server application can return data to
the client application using the connection
established for the verification.
Figure 51.20 shows the sequence of actions which take place during
data transfer using client transport class 3 and server transport class
3. In the example depicted, the verification is the only data
transmitted in the server-to-client direction. The unshaded areas in
the figure below indicate client-to-server data transmission, and the
shaded areas indicate server-to-client transmission.
5123
Figure 51.20
Class 3 and Server Transport Class 3 without Returned Data
Application
Client
T3
Link
Producer
Link
Consumer
Server
T3
Application
Write to
Data Buffer
Trigger
Update Data
Buffer
Seq. Cnt = 1, Data
Send
Data Arrived
Link
Consumer
Verify
Link
Producer
Seq. Cnt = 1
Verify
Write to
Data Buffer
Trigger
Send
Link
Producer
Seq. Cnt = 2, Data
Link
Consumer
Update Data
Buffer
Data Arrived
Trigger
Update Data
Buffer*
Seq. Cnt = 2, Data
Send
Dup. Arrived
Link
Consumer
Verify
Link
Producer
Seq. Cnt = 2
Verify
Write to
Data Buffer
Trigger
Send
Link
Producer
Seq. Cnt = 3, Data
Link
Consumer
Update Data
Buffer
Data Arrived
Link
Consumer
Trigger
Send
Link
Producer
Verify Lost
Seq. Cnt = 3
Seq. Cnt = 3, Data
Link
Producer
Link
Consumer
Verify
Update Data
Buffer*
Dup. Arrived
Link
Consumer
Verify
*
Seq. Cnt = 3
Link
Producer
5124
At times, the server-to-client transmission comprises the verification

and additional data. The figure below shows the sequence in which
actions take place during data transfer using client transport class 3
and server transport class 3 when the verification and data are
returned to the client. Note that the returned data is written
asynchronously to the receipt of data from the client. The unshaded
areas in the figure below indicate client-to-server data transmission,
and the shaded areas indicate server-to-client transmission.
5125
Figure 51.21
Class 3 and Server Transport Class 3 with Returned Data
Application
Client
T3
Link
Producer
Link
Consumer
Server
T3
Application
Write to
Data Buffer
Trigger
Update Data
Buffer
Seq. Cnt = 1, Data
Send
Data Arrived
Verify
Link
Consumer
Seq. Cnt = 1, Data = xyz
Link
Producer
Link
Producer
Seq. Cnt = 2, Data
Link
Consumer
Write to
Data Buffer
(Data=xyz)
Verify
Write to
Data Buffer
Trigger
Send
Update Data
Buffer
Data Arrived
Trigger
Update Data
Buffer*
Seq. Cnt = 2, Data
Send
Write to
Data Buffer
(Data=zzz)
Dup. Arrived
Verify
Link
Consumer
Seq. Cnt = 2, Data =zzz

= zzz
Link
Producer
Link
Producer
Seq. Cnt = 3, Data
Link
Consumer
Verify
Write to
Data Buffer
Trigger
Send
Update Data
Buffer
Data Arrived
Link
Consumer
Trigger
Send
Link
Producer
Verify Lost
Seq. Cnt = 3
Data=xxx
Seq. Cnt = 3, Data
Write to
Data Buffer
(Data=xxx)
Link
Producer
Link
Consumer
Verify
Update Data
Buffer*
Dup. Arrived
Link
Consumer
Verify
*
Seq. Cnt = 3, Data = xxx
Link
Producer
5126
Class 3 Client Transport

In the client-to-server direction, a class 3 client transport is
responsible for:
Accepting the client applications trigger that it has written a data
packet to the client-side T-PDU transmit buffer
Writing a transport header to the client-side T-PDU transmit
buffer for each packet that the client application writes to it
(NOTE: The transport header for each packet must include a
sequence count.)
Initializing the sequence count in the transport header (for the
first packet transmitted) or incrementing the sequence count (for
subsequent packets of the same transmission)
Triggering the producing node of the network connection to
produce the T-PDU packet on the link and send it to the
consuming node of the network connection
In the server-to-client direction, a class 3 client transport is
responsible for:
Accepting notification from the consuming node of the return
network connection that it has written data (the server transport
instances verification) to the client-side T-PDU receive buffer
Locating and reading the transport header of each data packet that
the consuming node of the return network connection writes to
the client-side T-PDU receive buffer
Notifying the client application that the consuming node of the
return network connection has written data to the client-side
T-PDU receive buffer
5127

The application can update the data buffer or retrigger data before all
of the verifications have been received. If the client transport is
retriggered while waiting for a verification, the previous verification
received register is cleared. This means that the client transport class
will wait for all active consumers to return a verification before
notifying the application.
Nonexistent
Create/
Set Seq. Cnt. = 0
Idle
Delete
Start
Stop
(From any state)
Running
Reset
Write/
Seq. Cnt. = Seq. Cnt. + 1
Trigger/
Store Seq. Cnt. in THeader
Clear Verify Register
Send
Wait for Verify
Write/
Trigger/
Store Seq. Cnt. in THeader
Clear Verify register
Send
All Verifies Rec.

Verify Notify = FALSE
All Verifies Rec.

Verify Notify = TRUE/
Notify Verify Received
Packet Arrived
Rx. THeader =
Tx. THeader/
Update Verify Received
The sequence count is set to 0 by the create service. It is then

incremented after every write event until it reaches a maximum value
of 2161 . After that it rolls over to 0.
5128
State Event Matrix

State Event
Nonexistent
Idle
Running
Wait for verify
Create
1) Seq. Cnt. = 0
2) Transition to Idle
Error
Error
Error
Delete
Error
Transition to
Nonexistent
Error
Error
Start
Error
Transition to
Running
Error
Error
Stop
Error
No Action
Transition to Idle
Transition to Idle
Reset
Error
Error
No Action
Write
Error
No Action
Trigger
Error
No Action
1) Store Seq. Cnt. in TPDU

2) Clear Verify register
3) Send
4) Transition to Wait for Verify
1) Store Seq. Cnt. in TPDU

2) Clear Verify register
3) Send
Packet Arrived
Rx. T header =
Tx. THeader
Error
No Action
No Action
1) Update Verify Register
All Verifies Received

Notification = TRUE
Error
No Action
Error
1) Notify: Verify
2) Transition to Running
All Verifies Received

Notification = FALSE
Error
No Action
Error
"
The STD and SEM for client class 3 are nearly identical.
Acknowledgement has been substituted for verification.
Services
Create Create instance of client transport class 3.

Delete (Optional) Delete instance of client transport class 3.
Reset (Optional) Transition to running. This will cause any
outstanding(Unverified) packets to be discarded.

Write This service is invoked when data is written to the data
buffer. It will cause the sequence count to be incremented.
Trigger This service is invoked when the data in the TPDU
buffer is to be sent. It will store the current sequence count in the
TPDU buffer and invoke the send service in the producer.
Start Transition to running state.
Attributes
State UINT [0 Nonexistent, 1 Idle, 2 Running, 3 Waiting for

Verify]
Sequence Count UINT
Verifies Received [Implementation Specific Size]
5129
Class 3 Server Transport

Transport class 3 starts with the behavior in class 1 and adds a return
connection that verifies that the application has received the packet.
It is the responsibility of the application to verify receipt of data. The
sequence count that is returned with the verify is the same as the
sequence count sent with the data.
The application is required to read the TPDU buffer before
invoking the verify service.
In the client-to-server direction, a class 3 server transport is
responsible for:
Accepting the notification from the consuming node of the
network connection that it has written a data packet to the
server-side T-PDU receive buffer
Locating and reading the transport header of each packet that the
consuming node of the network connection writes to the
Comparing the sequence count of each packet in the server-side
T-PDU receive buffer with that of the previous packet
Notifying the server application that the most recently arrived
packet is a duplicate of the previous one when their sequence
counts match
Notifying the server application that data has been written to the
In the server-to-client direction, a class 3 server transport is
responsible for:
Writing the transport header of the data in the server-side T-PDU
receive buffer to the server-side T-PDU transmit buffer
Correlating that transport header with any data that the server
application wants to send to the client application and has written
to the server-side T-PDU transmit buffer
Triggering the producing node of the return network connection
to produce the T-PDU packet on the link and send it to the
consuming node of the return network connection
"
Data from the application can be returned from the server to the
client along the verification connection.
5130

The send service is invoked when verify is received from an
application or when a duplicate transmission is received while in the
running state. Retransmitting when a previously verified packet has
been received allows this class to recover from lost verifications.
Nonexistent
Create
0
Delete
Idle
Stop
(From any state)
Start
Reset
Ready to Run
Packet Arrived
Data Arrived Notify =
TRUE/
Store Seq. Cnt. in TPDU
Reset
Waiting for verify
Packet Arrived
Rx. THeader <>
Seq. Cnt
TRUE/
Packet Arrived
Rx. THeader =
Seq. Cnt
Dup. Arrived Notify =
TRUE/
Packet Arrived
Rx. THeader <>
Seq. Cnt
FALSE/
Packet Arrived
Rx. THeader <>
Seq. Cnt
FALSE/
Packet Arrived
Rx. THeader <>
Seq. Cnt
TRUE/
Running
Packet Arrived
Rx. THeader =
Seq. Cnt
TRUE/
Send
Packet Arrived
FALSE
Verify/
Send
Packet Arrived
Rx. THeader =
Seq. Cnt
FALSE
Send
5131
State Event Matrix

State
Event
Non
existent
Idle
Ready to Run
Waiting for verify
Running
Create
Transition to
Idle
Error
Error
Error
Error
Delete
Error
Transition to
Nonexistent
Error
Error
Error
Start
Error
Transition to
Ready to Run
Error
Error
Error
Stop
Error
No Action
Transition to Idle
Transition to Idle
Transition to Idle
Reset
Error
Error
No Action
Transition to
Ready to Run
Transition to
Ready to Run
Packet Arrived
Rx. THeader <> Seq.
Count
TRUE
Dup Arrived Notify =
TRUE
Error
No Action
1) Store Seq. Cnt. in

TPDU
2) Notify: Data Arrived
3) Transition to
Waiting for Verify

TPDU

TPDU
3) Transition to
Waiting for Verify
Packet Arrived
Rx. THeader = Seq.
Count
TRUE
TRUE
Error
No Action

TPDU
3) Transition to
Waiting for Verify
1) Notify: Dup. Arrived

2) Send (Implies
Verify)
Packet Arrived
Rx. THeader <> Seq.
Count
TRUE
FALSE
Error
No Action

TPDU
3) Transition to
Waiting for Verify

TPDU

TPDU
3) Transition to
Waiting for Verify
Packet Arrived
Rx. THeader = Seq.
Count
TRUE
FALSE
Error
No Action

TPDU
3) Transition to
Waiting for Verify
No Action
1) Send (Implies
Verify)
Packet Arrived
Rx. THeader <> Seq.
Count
FALSE
TRUE
Error
No Action

TPDU
2) Transition to
Waiting for Verify

TPDU

TPDU
2) Transition to
Waiting for Verify
Packet Arrived
Rx. THeader = Seq.
Count
FALSE
TRUE
Error
No Action

TPDU
2) Transition to
Waiting for Verify

2) Send (Implies
Verify)
Packet Arrived
Rx. THeader <> Seq.
Count
FALSE
FALSE
Error
No Action

TPDU
2) Transition to
Waiting for Verify

TPDU

TPDU
2) Transition to
Waiting for Verify
5132
Packet Arrived
Rx. THeader = Seq.
Count
FALSE
FALSE
Error
No Action

TPDU
2) Transition to
Waiting for Verify
No Action
1) Send (Implies
Verify)
Verify
Error
No Action
No Action
1) Send (Implies Verify)

No Action
Services
Create Create instance of server transport class 3.

Delete (Optional) Delete instance of server transport class 3.
Reset (Optional) Transition to ready to run. (Accept next packet
as new data)
Verify This service is invoked, by the application, to send a
response back to the client. When it is invoked it will store the
current sequence count in the TPDU buffer and invoke the send
service in the producer.
Start Transition to the ready to run state.
Attributes
Data Arrived Notify [TRUE, FALSE]

Duplicate Arrived Notify [TRUE, FALSE]
State UINT [0 Nonexistent, 1 Idle, 2 Ready to Run, 3 Waiting
for Verify, 4 Running]
Sequence Count UINT
Possible uses of transport class 3 include change-of-state inputs and
outputs, asynchronous [independent] block transfers, event
acknowledgements, communication between controllers and operator
interface devices, uploads, downloads, and messaging.
Table NO TAG shows how the transport classes map to specific
product functions.
Unconnected Message
Manager (Single-link
Transport Class)
5133
Setting up a connection requires communication between devices.

These initial communications, require an unconnected message
service. The unconnected message service, which only operates on a
single link, is different from other transports. That is, packets are
queued at each node instead of the normal overwrite. Multiple
connections can, therefore, be established at the same time. This
reduces the overall time needed to set up all the connections in a
typical system.
Although the unconnected message manager (UCMM) service
supports multiple outstanding messages, the number of outstanding
messages supported is implementation specific. As the number of
available outstanding messages increases, the mean waiting time to
transmit a message is reduced. Implementations that support a single
message are valid. Most I/O modules support just a single message
while controllers and adapters support multiple outstanding
messages.
Figure 51.22
Layered View of the Unconnected Message Manager
Input
Download
Upload
Scanner
Application
Transport
Connection
Manager
Message Router
Data Buffer
Transport Services
UCMM
Network
Network Connections
Link/Physical
ControlNet
ICP
DeviceNet
The UCMM provides a single-link unconnected message service that

can support multiple outstanding messages. This service is limited to
a single link and is always bound to the message router in the sense
that every request packet received by the UCMM is always
forwarded to the message router.
5134
The functions of the UCMM are to:

Route forward open connection requests to the UCMM on the
target device
Establish a physical connection to that device
Send messages to and receive messages from UCMM objects on
other devices
Send messages to and receive messages from its local message
router
The figure below shows the functions of both the client and server
UCMMs within the context of an application connection made
between applications on different devices.
Figure 51.23
Data Flow Diagram for the Client and Server UCMMs
Buffer
Out
Buffer
Out
Buffer
Out
Buffer Out
Data
Buffer
Out
Buffer
Out
Buffer
Out
Buffer In
Data
Data
Data
Data Arrived(Transaction Record #)
Dup. Arrived(Transaction Record #)
Write(Transaction Record #)
Packet
Abort(Transaction Record #)
Application
Response(Transaction Record #)
Client
UCMM
Packet
Server
UCMM
Data
Buffer
InIn
Buffer
Buffer
In
Buffer In
Application
Timeout(Transaction Record #)
Timeout(Transaction Record #)
Data
Abort(Transaction Record #)
Response(Transaction Record #)
Data
Data
Buffer
Out
Buffer
Out
Buffer
Out
Buffer Out
5135
Figure 51.24
Sequence Diagram for a UCMM with One Outstanding
Message
Application
Client
UCMM
Server
UCMM
Application
Create(Tr #3)
Write(Tr #3)
Send
Seq. Cnt = 0, Rec# = 03, Request Data
Data Arrived(Tr #2)
ACK
Response
(Tr #3)
Seq. Cnt = 0, Rec# = 03, Response Data
Send
Respond(Tr #2)
ACK
Delete(Tr #3)
2
Create(Tr #3)
Write(Tr #3)
Send
Response
(Tr #3)
Data Arrived(Tr #2)
Seq. Cnt = 0,Rec# = 03, Request Data

ACK
Send
Respond(Tr #2)
ACK
Write(Tr #3)
Send
Response
(Tr #3)
Data Arrived(Tr #2)

ACK
Send
Respond(Tr #2)
ACK
Delete(Tr #3)
3
Create(Tr #3)
Write(Tr #3)
Send
Data Arrived(Tr #2)

ACK
Send
Respond(Tr #2)
Response Lost
Delete(Tr #3)
Resend
ACK
5136
Refer to the following footnotes:

Typical transaction: An instance is created. The request is written.
The response is returned. The instance is deleted.
Two transactions/same instance: In this case the instance is

opened and two requests are sent. Note that the client waits for the
first response to return before issuing a second request using the
same transaction number.
Lost response: In this case the response is lost and the server issues
a retry.
Figure 51.25
Sequence Diagram for a UCMM with Multiple Outstanding
Messages
Application
Client
UCMM
Server
UCMM
Application
Create(Tr #3)
Write(Tr #3)
Send
Seq. Cnt = 0, Req# = 03, Request Data

ACK
Create(Tr #4)
Write(Tr #4)
Data Arrived(Tr #2)
Send
Response
(Tr #4)
Data Arrived(Tr #1)

ACK
Seq. Cnt = 0, Req# = 04, Response Data
Send
Respond(Tr #1)
Send
Respond(Tr #2)
ACK
Response
(Tr #3)
Seq. Cnt = 0, Req# = 03, Response Data
Delete(Tr #4)
ACK
Delete(Tr #3)
Timeout(Tr #2)
Timeout(Tr #1)
Create(Tr #3)
Write(Tr #3)
Write(Tr #3)
Send
Resend
Data Arrived(Tr #2)
ACK lost X
Dup. Arrived(Tr #2)

(Optional)

ACK lost X
Write(Tr #3)
Resend
Timeout
(Tr #3)

ACK lost X
Dup. Arrived(Tr #2)

(Optional)
5137
Refer to the footnotes below:

Multiple outstanding: In this case the client creates two instances
and sends a second request before the first request has completed.
Note that the client uses a different transaction number for the
second request.
Timeout: In this case the server application does not respond and
the client issues a timeout. Note in this case a delete is not required
to close the transaction.
Client Unconnected Message Manager (UCMM)

Applications create an instance of an unconnected message manager
transaction using the create service. They then complete the
transaction record and issue a write service. They may abort the
current write using the abort service. The application must wait for a
response or a timeout notification before invoking an additional
write on the same UCMM transaction.
Client Transaction Record
The client transaction record is implementation specific. A sample
record is shown below.
Table 51.AE
Client Transaction Record
Destination
(Link
Address)
Transaction Sequence
Record
Count
Number
Retry
Count
Retry
Timer
Response
Timer
State
Request
5138
Client Transaction State Transition Diagram (STD)

Nonexistent 0
Initialize/
Inactive
Delete/ (From any state)

Delete Record
Create/
Create Record
Running
Write/
Send Packet
Start Timers
Abort/
Stop Timers
Response Timeout/
Notify: Timeout
Waiting for Response
Response Arrives/
Notify: Response
Retry Timeout/
Resend Packet
5139
Client Transaction State Event Matrix

State
Event
Inactive
Running
Create
1) Create record
2) Transition to
Running
Error
Error
Delete
Error
1) Delete record
2) Increment record Sequence #
3) Transition to Inactive
1) Delete record
2) Increment record Sequence #
Write
Error
1)Send packet
2)Start Response Timer
3)Initialize Retry Count
4)Start Retry Timer
5)Transition to
Error
Abort
Error
No Action
1) Stop Timers
2) Increment Sequence #
Retry Timeout
Request packet
available
Not Applicable
Not Applicable
1) Decrement Retry Count IF Retry Count expired

2) Notify: TimeoutNo ACK
3) Free request buffer
5) Stop Response Timer
6) Transition to Running ELSE.
2) Resend packet
3) Restart Retry Timer
Response
Timeout
Not Applicable
Not Applicable
1) Notify: TimeoutNo
Response
Response
Arrives
Not Applicable
No Action
1) Notify: Response
2) Send ACK_RESP, unless response indicates
no ACK_RESP desired
ACK_REQ Arrives,
sequence number
matches stored value
Not Applicable
No Action
1) Free request buffer

2) Stop retry timer
ACK_REQ Arrives,
sequence number
not equal to stored
value
Not Applicable
No Action
No Action
The sequence number is set to zero at initialization. The sequence

number value is maintained in the inactive state, to be used when the
record transitions to running.
The retry timeout value is fixed for the local network.
The response timeout is the response time provided when the record
is created.
5140
UCMM Services
Create Create instance of client UCMM transaction.

Delete (Optional) Delete instance of client UCMM transaction.
Write The write service is used to send the request message
from the transaction record.
Abort (Optional) The abort service is used to cancel a request
message. The abort causes the UCMM to return to the running
state. The abort service will stop the retry timer and the response
timer; stopping all further retries and timeout messages for this
instance.
Transaction Attributes
State UINT
Destination [Link specific]
Transaction Record Number {10 bits}
SequenceCount {6 bits, used for duplicate detection. Is not
incremented on a retry.}
RetryCount [Link specific] (2 retries suggested)
Response Timer [8 bit floating point] 4 bit mantissa, 4 bit
exponent Range: 10ms 320 sec.
Server Unconnected Message Manager (UCMM)

When a packet arrives at the server an instance of a transaction is
created if resources are available. If resources are not available the
packet is dropped. When the instance is created, a transaction record
is created for that instance. This record is active for the life of this
transaction. The transaction ends when an ACK_RESP is received
after a response was sent, when the response time timer expires or
when a new packet is received after a response was sent.
Server Transaction Record
The server transaction record is implementation specific. A sample
record is shown below.
Table 51.AF
Server Transaction Record
Destination
(Link
Address)
Transaction Sequence
Record
Count
Number
Retry
Count
Retry
Timer
Response
Timer
State
Request
5141
High-end Server Transaction State Transition Diagram (STD)

Inactive
Abort (From any state)

Packet Arrives, New Transaction ID, New Sequence #
Create New Record
Notify: Data Arrive
Response Timer
(From any state)
Packet Arrives
Exisiting Transaction ID
Exisiting Sequence #/
Notify Dup. Arrived
Send ACK_REQ
Packet Arrives
New Sequence #/
Update Record
Notify Data Arrived
Response Sent
Receive ACK_RESP, Seq# OK/

Free Response Buffer
Receive ACK_RESP
Sequence #NG/
Discard ACK_RESP
Retry Timeout/
Resend Response,
if response buffer
not freed
Send Response/
Send Response
Start Retry Timer
Packet Arrives
Existing Sequence #/
Resend Message
5142
High-end Server Transaction State Event Matrix

State
Event
Inactive
Running
Packet arrives
New Transaction ID
and source address
1) Create new record

3) Send ACK_REQ
4) Start Response Timer
5) Transition to
Waiting for App
Response
Not Applicable
Not Applicable
Packet arrives
Existing Transaction ID
and source address
New Sequence #
Not Applicable
No Action
1) Update Record
3) Send ACK_REQ
3) Transition to
Waiting for App
Response
Packet arrives
Existing Sequence #
Not Applicable

(Optional)
2) Send ACK_REQ

(Optional)
2) Resend Response
Message
Response Timer Expires
Not Applicable
1) Notify: Timeout
2) Delete record
1) Notify: Timeout
2) Delete record
Abort
Error
1) Delete record
1) Delete record
Send Response
Error
1) Send Response
2) Start Retry Timer
2) Transition to
Response Sent
Error
Retry Timeout
Not Applicable
Not Applicable
1) Decrement Retry Count IF Retry

Count expired
3) Free Response buffer
4) Stop Response Timer
ELSE
1) Resend Response
message
2) Start Retry Timer
ACK_RESP Attrives,
Error
No Action
1) Delete record
Error
No Action
No Action
sequence number
matches stored value
ACK_RESP Attrives,
sequence number not
equal to stored value
The response time is the response time received in the message header.
5143
Low-end Server Transaction State Transition Diagram (STD)

Inactive
Send Response/
Send Response_No_ACK
Create/
Create New Record
Notify: Data Arrive
Waiting for App Response
Packet Arrives
Exisiting Sequence #/
Notify Dup. Arrived
If you use the low-end server you cannot:

perform response message retries
detect duplicate messages
Low-end Server Transaction State Event Matrix
Use the following State Event Matrix (SEM) when a conflict occurs
with the State Transition Diagram (STD)
State
Event
Inactive
Packet arrives
New Transaction ID
and source address
1) Create new record

3) IF Response not immediately
available,
Send ACK_REQ
4) Transition to
Waiting for App Response
Not Applicable
Packet arrives
and source address
New Sequence #
Not Applicable
No Action
Packet arrives
Existing Sequence #
Not Applicable

(Optional)
Send Response
Error
1) Send
Response_No_ACK
ACK_RESP Attrives
Error
No Action
5144
UCMM Services
Abort (Optional) Deletes transaction record and removes

instance of transaction.
Send Response This service, initiated by the server application,
causes the response to be sent to the client UCMM.
Transaction Attributes
State UINT
Destination [Link specific]
Transaction Record Number {10 bits}
SequenceCount {6 bits, used for duplicate detection. Is not
incremented on a retry.}
Response Time [8 bit floating point] 4 bit mantissa, 4 bit
exponent Range: 10ms 320 sec.
[In addition, any device which participates in making connections
must have a Message Router and connection manager. Most devices
will also support message connections to the Message Router. Each
device can support one or more of the following:
General Application Connections These include connections to
the application which generate realtime inputs or outputs,
diagnostics, or other information.
General Messaging Connections (Server) These are connections
to the Message Router application. With this connection and the
ControlNet messaging protocol, a client application can access
any application within the device.
General Messaging Connections (Client) The client messaging
connection enables direct access via a connection to the message
router in any other module.
Unconnected Messages Although unconnected messages are
routed to the message router, one of their major functions is to set
up connections.
Communication using unconnected messages has restrictions:
Message Size Limit The size of the message is limited to one
packet, and the maximum size of the packet is a function of the
type of module and the type of link. Not all devices can support
the maximum size (508-byte) packet.
Limited to the local link An unconnected message can only be
used on a local link. The message can not be routed from one
link to the next, like a connection. The unconnected message
manager service is a client/server function in which both the
client and server must be on the same link.
For more information on the UCMM, see Chapter 21, ControlNet
Messaging.
5145
UCMM Wire Format

Table 51.AG
UCMM Header
Response Time, 8 Bits
Control, 8 Bits
UCMMProtocolHeader ::=
SEQUENCE
TransactionID, 16
Bits
{
Control ::= [0] IMPLICIT Ucontrol,
Response Time ::= [1] USINT,
TID ::= [2] IMPLICIT UTID,
}
Ucontrol ::=
BIT STRING
{
LSB(0),MSB(7)
ULinkCode(0-2),
reserved(3),
control code
These bits are reserved and

must be set to zero
reserved(4),
Any packets received with

the reserved bits set
reserved(5),
reserved(6),
must be discarded.
This is to ensure backward
compatibility for future
additions.
Priority(7),__priority: 0 = low, 1 = high

}
ULinkCode ::=BIT STRING
{
LSB(0),MSB(7)
0x000 - <reserved>
0x001 - ACK_REQ
0x010 - Request
0x011 - Response
0x100 - Datagram
0x101 - ACK_RESP
0x110 - Response_No_ACK
0x111 - <reserved>
}
UTID ::= BIT STRING
{
LSB(0), MSB(15)
RecordNumber(09),
Identifier for a specific

client Transaction Record.
SequenceNumber(1015), Used for duplicate

detection, not incremented on a retry
}
Only one outstanding message is allowed for a given transaction ID.

If multiple outstanding messages are required then multiple
transaction IDs are required.
5146
UCMM packets received with control codes or bits that are not
recognized by a client or server UCMM must be discarded.
Retry Timers
The retry timer allows a retry packet to be retransmitted at some
periodic rate until an acknowledgement or verification is received
from the server. The retry timer can be used with class 2 or 3 client
transports. It cannot be used with classes 0 or 1 because they do not
support a return connection from the server. The retry timer also
provides a timeout notification to the client application. This event
tells the client that the maximum number of retries has been reached.
All class 3 transports that are used for messaging (connected to a
message router) will use a retry timer.
Retry timers are configured through the connection manager.
Timer
Trigger
Timeout
Trigger
Application
Ack
Verify
Ack
Trigger
Write
Verify
Client
(Class
2 or 3)
Transport
5147

Nonexistent
Create
Delete
Wait for trigger

Trigger_in/
start_timer
Retry_cnt = 0
Reset
Verify
1
Ack
Counting
Max_retry/
Timeout
2
Timer tick/
Trigger_out
Retry Cnt. = Retry Cnt. + 1
Test for Max_retry

State
Event
Nonexistent
Wait for trigger
Counting
Create
Transition to Wait for trigger
Error
Error
Delete
Error
Reset
Error
No Action
Transition to Wait for trigger
Trigger_in
Error
1) Retry_cnt = 0
2) Start_timer
3) Transition to Counting
No Action
Timer Tick
Error
No Action
1) Trigger_out
2) Retry_cnt = Retry_cnt + 1
3) Test for Max_retry
Max_retry
Error
No Action
1) Notify: Timeout
2) Transition to Wait for trigger
Ack
Error
No Action
Verify
Error
No Action
Services
Create Create instance of retry timer.

Delete (Optional) Delete instance of retry timer.
Reset (Optional) Transition to wait for trigger. Retry timer will
stop issuing retries and wait for next trigger.
Attributes
Max_retry UINT
Tick_time [16 bit floating point]
State UINT
5148
Interoperability Of
Transport Classes
The following table shows which server transport classes will work
with different client transport classes. Transport classes 1 and 3
allow passive servers, while transport class 1 does not have any
active servers, since there is no reverse flow of data. Note that active
connections must be of the same transport type. The server cannot
influence the flow of data.
Table 51.AH
Transport Class Interoperability
Active Server Class
Client Class
Passive Server Class
Transport Classes and

Network Connections
The ControlNet system uses a number of different kinds of transports

for various kinds of applications. Each of the transports uses one or
more network connections. The transports supported include:
Class Number
Class Name
Notes
Duplicate detection
Two transports can be established in

one open connection service
Verified
Only one transport can be established

with an open connection service
Transport Class 1 Duplicate Detection

The class 1 transport uses either a point-to-point or multicast
connection. A single open connection service can establish up to two
class 1 transports, one in each direction.
Transport Class 3 Verified

The class 3 transport uses two network connections, one which can
be either point-to-point or multicast, and one which must be
point-to-point. This connection is typically used for a multicast from
the producer and a point-to-point return connection for verification
by a consumer.
Interoperability of Transport Classes and Network Connections

The following is a mapping of the various transports to connections
managed by the connection manager. In each picture two
connections, with connection serial numbers (CSN) A and B, are
being made to the same application.
5149
In the first case two connections are established with the originator
as the producer using a class 1 transport. In the single link case the
single link producer is associated with both connections as shown by
the CSN A and B connected to both the transport and link producer.
In the case using a bridge again both CSN A and B are associated
with the same link producer and transport at the originator and again
at the bridge. The last case using a multiported bridge shows that a
single link consumer in the bridge will have to forward data to two
link producers, one for each port. In this case the CSN is associated
with a single link consumer but with different link producers in the
bridge.
Figure 51.26
Multiple Class 1 Transports with the Originator as the
Producer
Originator
Bridge
Target
CSN
A
Single Link
CSN
A
APP
CSN
B
LC
LC
CSN
B
CSN
A
LP
CSN
B
LC
LC
CSN
A
Bridge
APP
APP
APP
APP
CSN
A
CSN
B
CSN
B
CSN
A
LC
LP
APP
APP
CSN
B
LP
LC
Using a MultiPorted
T
CSN
A
Using a Bridge
APP
APP
CSN
B
LP
CSN
A
LP
CSN
B
LC
LP
LC
APP
T
Application
Transport
LP Link
Producer
CSN
A
Connection
LC Link
Consumer
CSN Connection
B
5150
When the originator is the consumer of a class 1 transport multiple

connections require multiple transports which are connected to the
same application. Notice that CSN A and B are treated as separate
connections in the bridge.
Figure 51.27
Multiple Class 1 Transports with the Originator as the
Consumer
Originator
Target
Bridge
Single Link
CSN
A
T
CSN
A
LC
LP
APP
APP
APP
APP
APP
CSN
B
CSN
B
T
LP
LC
Using a Bridge
CSN
A
T
CSN
A
CSN
A
LC
LP
LP
LC
APP
CSN
B
T
LC
APP
T
CSN
B
CSN
B
LP
Application
Transport
LP
LC
LP
Link
Producer
CSN
A
Connection
LC
Link
Consumer
CSN
B
Connection
In the case where the originator makes multiple class 3 transport

connections using point to point network connections multiple
transports are required. Each transport requires two network
connections.
5151
[If class 1 transports are needed in both directions, they can be set up
using a single open connection service. This is used for setting up
connections to output modules, since each output module uses a
point-to-point class 1 transport for the output data and another
multicast class 1 transport to echo the output data.]
Figure 51.28
Multiple Class 3 Transports at the Originator using
Point-to-Point Connections
Originator
Bridge
Target
Single Link
CSN
A
CSN
A
LC
LP
LP
LC
LC
LP
LP
LC
APP
APP
APP
T
CSN
B
CSN
B
Using a Bridge
CSN
A
CSN
A
CSN
A
LC
LP
LC
LP
LC
LP
LC
LC
LP
LC
LP
LP
LC
LP
LC
LP
APP
APP
APP
T
CSN
B
CSN
B
CSN
B
APP
LP
Application
Link
Producer
Transport
CSN
B Connection
LC Link
Consumer
CSN
A Connection
5152
In the last and most complicated case, an originator makes multiple

class 3 transport connections with one side of the connection being
multicast. In this case only a single transport is needed at the
originator but each connection is associated with a single link
producer and a different link consumer. This complication is also
extended into the bridge where each CSN shares a link producer/
consumer pair for the multicast data and is associated with a different
link producer/ consumer pair for the point to point return path.
Figure 51.29
Point-to-Point and Multicast Connection Types
Originator
Bridge
Target
Single Link
CSN
A
CSN
A
LC
APP
LP
PP
LP
LC
APP
Multicast
CSN
B
LC
T
LC
PP
LP
CSN
B
Using a Bridge
CSN
A
CSN
A
LC
APP
APP
PP
T
LP
CSN
A
LP
LC
LP
LC
LP
LC
Multicast
CSN
B
CSN
B
LC
T
LC
LP
PP
APP
LC
APP
LP
CSN
B
APP
Application
LP
Link
Producer
CSN
A
Connection
Transport
LC
Link
Consumer
CSN
B
Connection
The same complexity arises at the target if multiple class 3 transports

are connected to the same target node. Again a CSN is associated
with single multicast producer and different point to point
consumers.
5153
Figure 51.30
Point-to-Point and Multicast Connection Types
Originator
Bridge
Target
Single Link
CSN
A
APP
CSN
A
LC
LP
PP
LC
LP
Multicast
LC
CSN
B
T
LC
APP
APP
LP
PP
CSN
B
Using a Bridge
CSN
A
CSN
A
LC
APP
CSN
A
LP
LC
LP
LC
LP
LC
PP
T
LP
Multicast
CSN
B
CSN
B
LC
PP
LP
APP
LC
T
LC
APP
LP
CSN
B
APP Application
T
Transport
Link Producer
CSN
A
Connection A
LC Link Consumer
CSN
B
Connection B
LP
5154
Transport Class/Network Connection Interoperability Matrix

The following table shows which network connections will work
with different transport classes. Because class 1 is unidirectional,
there are no servertoclient connections.
Table 51.AI
Transport Class/Network Connection Interoperability
Connection Direction
Class
lass
Client to Server Network Connection
Server to Client
Point to Point
Point to Point
UCMM
Multicast
Priority
Sched
High
Low
Multicast
Sched
High
Low
The unconnected message manager will always use the low or

medium priorities and point to point transfers.
A ControlNet application connection is a logical connection

between two applications, and is made at the application layer of
the ControlNet communication model. An application connection is
built on one or two transport connections. The originating
application is responsible for creating and binding the client
transport instance to the originating application, and the target
application is responsible for creating and binding the server
transport instance to the target application. An application
connection includes the transport connection which, in turn, includes
the producers and consumers involved in the network connection.
Since the unidirectional class 0 and 1 transports require a single
network connection, two unidirectional transports can be established
within a single connection. The two unidirectional transports do not
have to be coordinated at either of the applications, but will be linked
in any of the bridges.
The application connection can also include additional parameters or
data. A target application, for example, may need information on
electronic keying, ownership verification, or the detailed
configuration to establish the connection. Such information is sent as
a structure in a data segment as part of the connection path. The data
segment is forwarded by the intermediate nodes and delivered to the
target application as additional segments in the APP_OPEN
message. The data segment will be interpreted by the target
application.
5155
[The target application would check the module type in the

electronic key, check or save the ownership information, and use the
configuration information to set up the device. Success and reply
information or failure and a reason for the failure can be returned in
the ControlNet message reply. The format of the data segment,
which is a function of the target application, is not covered in this
document.]
Production Trigger, Transport Class and EPR

A client application uses the transport class, trigger type and EPR to
determine when to sample and send data.
The ControlNet system supports three types of triggers for the
production of data: cyclic, change of state, and application-triggered.
These triggers only apply to the client application.
The triggers are used in conjunction with the transport class and EPR
to control when data are sampled and sent on the link. The following
table shows how these factors relate to each other in determining
when data are produced.
5156
Notes:
5157
5158
Allen-Bradley, a Rockwell Automation Business, has been helping its customers improve productivity and quality for more than 90 years. We design, manufacture and support a broad range
of automation products worldwide. They include logic processors, power and motion control
devices, operator interfaces, sensors and a variety of software. Rockwell is one of the worlds
leading technology companies.
Worldwide representation.
Argentina Australia Austria Bahrain Belgium Brazil Bulgaria Canada Chile China, PRC Colombia Costa Rica Croatia Cyprus Czech Republic Denmark
Ecuador Egypt El Salvador Finland France Germany Greece Guatemala Honduras Hong Kong Hungary Iceland India Indonesia Ireland Israel Italy
Jamaica Japan Jordan Korea Kuwait Lebanon Malaysia Mexico Netherlands New Zealand Norway Pakistan Peru Philippines Poland Portugal
Puerto Rico Qatar Romania RussiaCIS Saudi Arabia Singapore Slovakia Slovenia South Africa, Republic Spain Sweden Switzerland Taiwan Thailand
Turkey United Arab Emirates United Kingdom United States Uruguay Venezuela Yugoslavia
Allen-Bradley Headquarters, 1201 South Second Street, Milwaukee, WI 53204 USA, Tel: (1) 414 382-2000 Fax: (1) 414 382-4444

Supersedes Publication 9220-6.5.1 September 1996
PN 95512817
Copyright 1996 Allen-Bradley Company, Inc. Printed in USA
5159
Allen-Bradley
ControlNet
Network
(Cat. No. 9220PDG51)
Product
Developers
Guide

ControlNet Network For Developers

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

ControlNet Network For Developers

Hochgeladen von

Copyright:

Verfügbare Formate

Allen-Bradley

Because of the variety of uses for the products described in this

ATTENTION: Identifies information about practices

Attention statements help you to:

Identifies information that is critical for successful

ControlNet is a trademark; PLC is a registered trademark of Allen-Bradley Company, Inc.

ControlNet Network Protocol

The ControlNet Network Mission . . . . . . . . . . . . . . . . . . . . . . . . . .

The Media Access Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

ControlNet Physical Media

Overview Of The ControlNet

Planning A ControlNet Cable

Publication 92206.5.1 January 1997

ControlNet Release 0.91 (Preliminary)

Determining Trunk-Cable Section Lengths . . . . . . . . . . . . . . . . . . .

Installing A ControlNet Cable

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

Connecting Cable Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Adjusting The Cable Strip

ControlNet Cable System

Installing The ControlNet

Installing The ControlNet

Installing The ControlNet

Publication 92206.5.1 January 1997

About The Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Verifying Package Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Release 0.91 (Preliminary)

Selecting Where To Mount The Tap . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Coax Physical

ControlNet Physical And

The Physical Layer As A Component . . . . . . . . . . . . . . . . . . . . . .

Selecting And Using LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

Publication 92206.5.1 January 1997

ControlNet Release 0.91 (Preliminary)

ControlNet Object Overview

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

Path Segment Type (Path_Seg_Type) . . . . . . . . . . . . . . . . . . . . . .

Publication 92206.5.1 January 1997

ControlNet Release 0.91 (Preliminary)

Originating Application Uses the Connection . . . . . . . . . . . . . . .

Physical Compliance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

Using The ControlNet

Network And Port

Publication 92206.5.1 January 1997

Understanding The Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Purpose Of The Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Network And Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

ControlNet Release 0.91 (Preliminary)

redundancy: Redundancy Control (USINT) . . . . . . . . . . . . . . . .

Who Command (For Active

ControlNet Release 0.91 (Preliminary)

Publication 92206.5.1 January 1997

Network Change Description . . . . . . . . . . . . . . . . . . . . . . . . . .

Publication 92206.5.1 January 1997

Adding A Device To An Existing Network . . . . . . . . . . . . . . . . . . . .