AllenBradley

DeviceNet
RS232
Reference
Interface
Module
Manual
Communication
Protocol
(Cat. No. 1770KFD)
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 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 which 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 make notes to alert you to possible

injury to people or damage to equipment under specific
circumstances.

ATTENTION: Identifies information about practices

or circumstances that can lead to personal injury or
! death, property damage, or economic loss.

Attention helps you:

• Identify a hazard.
• Avoid the hazard.
• Recognize the consequences.

Important: Identifies information that is especially important for

successful application and understanding of the product.
Important: We recommend you frequently backup your application
programs on appropriate storage medium to avoid
possible data loss.

IBM is a registered trademark of International Business Machines, Incorporated.

All other brand and product names are trademarks or registered trademarks of their respective companies.
 Table of Contents

Using This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Document Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
What to Expect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Assumptions About You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
How to Use This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Manual Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Module Communication Basics . . . . . . . . . . . . . . . . . . . . . 11

Chapter Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
About the Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Serial Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
LinkLevel Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
DF1 FullDuplex Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
PCCC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
DeviceNet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
The Module's Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15
ModuleSupported Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

FullDuplex DF1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
About DF1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Character Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Transmission Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Message Packet Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Block Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
TwoWay Simultaneous Operation . . . . . . . . . . . . . . . . . . . . . . . . 25
Environment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
How the Transmitter Operates . . . . . . . . . . . . . . . . . . . . . . . . . 26
How the Receiver Operates . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Host/Module Message Transmission Examples . . . . . . . . . . . . . . 212
Normal Message Transmission . . . . . . . . . . . . . . . . . . . . . . . . 212
When a Message Transfer Fails . . . . . . . . . . . . . . . . . . . . . . . 213
When a Retransmission is Requested . . . . . . . . . . . . . . . . . . . 214
ii Table of Contents

Module Communication Over the DF1 Link . . . . . . . . . . . . 31

Chapter Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Module SerialLink Autobaud . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The RS232 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Host and Module Local Connections . . . . . . . . . . . . . . . . . . . . . . 32
Accessing Local Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Inside the DeviceNet Message . . . . . . . . . . . . . . . . . . . . . . 34
Before Network Communication . . . . . . . . . . . . . . . . . . . . . . . . . 34
Stop Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Configure Node Address and Baud Rate . . . . . . . . . . . . . . . . . 35
Start Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Communication On The DeviceNet Network . . . . . . . . . . . . . . . . . 35
Sending and Receiving Unconnected DeviceNet Messages . . . . 36
Sending DeviceNet Messages . . . . . . . . . . . . . . . . . . . . . . . . . 36
Receiving Connected DeviceNet Messages . . . . . . . . . . . . . . . 37

Link Communication Example . . . . . . . . . . . . . . . . . . . . . . 41

Chapter Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Initializing Your Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Module Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
SerialLink Autobaud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Stop Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Set Node Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Set Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Start Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Creating Screeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Deleting Screeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Module Supported Objects . . . . . . . . . . . . . . . . . . . . . . . . A1

Appendix Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1
DeviceNet Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1
Instance Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1
MAC ID: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2
Baud Rate: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2
1770KFD DF1 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3
Instance Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3
Identity Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4
Class Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4
Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
Device Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
Product Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
 Table of Contents iii

Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
Serial Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5
Link Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6
Class Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6
Instance Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6
Power Management Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7
Instance Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7
Instance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7
RS232 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7
Instance Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B1
Appendix Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B1
Troubleshooting the Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . B2
 Preface

Using This Manual

Document Objectives The purpose of this reference manual is to aid you in:
• writing applications that use the 1770-KFD interface module
• communicating with the 1770-KFD over the RS-232 serial-link
• preparing the 1770-KFD to be an interface module to the
DeviceNet network

What to Expect This manual explains how to communicate with the 1770-KFD
interface module over an RS-232 serial-link. The protocol used to
accomplish this includes:
• 1770-KFD specific, full-duplex DF1 protocol
• PCCC protocol
• DeviceNet protocol
Please note that this manual covers communication between your
host computer and the 1770-KFD only. It does not explain how to
communicate on the DeviceNet network.

Assumptions About You We assume that you are a product developer or technical user and:
• have a general familiarity with communication protocols
• have a knowledge of RS-232
• have access to the DeviceNet Specifications Volumes I and II
• have some knowledge of object-oriented modelling concepts

How to Use This Manual This manual can be divided into four main sections as shown below.

Chapter 1 Chapter 2 Chapter 3 Chapter 4 Appendix A Appendix B

Module FullDuplex Module Link Module Troubleshooting
Communication DF1 Protocol Communication Communication Supported
Basics Over the Example Objects
DF1 link

Introduction to Detailed information on how Detailed examples of Reference information needed in

how your communication between how to initialize your coding messages and
module works your hostcomputer and module, create troubleshooting errors
module is structured screeners and delete
screeners (screeners are
for connected messages)

17706.5.22
 ii Using This Manual

Document Conventions

Often you will see icons in the left margin of a page. These icons are
designed to call your attention to more sources of information
concerning the subject about which you are reading.

The more icon is placed beside paragraphs that refer you to other
publications for additional information.

Reference The reference icon gives you a page number within this document
Go to page: where more information about what you are reading can be found.

Manual Terminology

The table below lists terms, and their respective definitions, that are
frequently used in this manual.

Frequently used term Definition

BCC block check character
hex hexadecimal format
a hostcomputer
host
it can be a desktop, laptop, or notebook personal computer
the physical communication layer between your
linklevel
hostcomputer and the 1770KFD interface module
module the 1770KFD RS232 interface module
in this document, the term network always refers to the
network
DeviceNet network
Programmable Controller Communication Commands
an applicationlevel command set that AllenBradley
PCCC
programmable controllers use to communicate
across networks
the RS232 serial connection between your hostcomputer
seriallink
and the 1770KFD interface module

Related Publications Publication name Publication number

DeviceNet RS232 Interface Module
17705.6
Installation Instructions
DeviceNet Specification  Volume I available through ODVA*
 Volume II available through ODVA*
Data Highway/Data Highway Plus/DH485
Communication Protocol and Command Set 17706.5.16
Reference Manual
*ODVA is the Open DeviceNET Vendors Association. To obtain the specifications, contact:
ODVA
Attn: Bill Moss
8222 Wiles Road, Suite 287
Coral Springs, FL 33067
voice: (305) 3405412
fax : (305) 3405413
email: [email protected]

17706.5.22
 Chapter 1
Module Communication Basics

Chapter Contents This chapter introduces the 1770-KFD module as a RS-232 interface
using the full-duplex DF1 communication-protocol. In addition, this
chapter explains applicable DeviceNet objects.

For information about See page

serial connection 13
link level communication 13
module supported objects 16

About the Module The 1770-KFD module is an interface to the DeviceNet network for
a host computer. The module connects to the host computer through
a standard RS-232 serial communication-port and to the network via
DeviceNet cable. Through the module, a host computer can connect
to the network anywhere along its cable. This connection can be
permanent or may be removed and reconnected as needed. In
addition, the module can connect directly to a device via DeviceNet
cable for a physical point-to-point connection.

device 1770KFD
module
DeviceNet RS232
cable cable
host
computer
connects directly to
a single device
or

connects to a
multidevice network
1770KFD
module
DeviceNet RS232
cable cable
host
computer

DeviceNet network devices

17706.5.22
 1-2 Module Communication Basics

The module can also provide access to a DeviceNet network

remotely through a modem. You can connect the module to two
types of standard modems:
• DTE-controlled answer
• auto-answer
1770KFD
module modem modem
DeviceNet RS232 telephone RS232
cable cable line cable
host
computer

DeviceNet network devices

Detectable baud rates for the module include:
• 1200 • 19200
• 2400 • 38400
• 4800 • 57600
• 9600
As illustrated below, the module contains all the components needed
to make it a stand-alone, portable interface.

5pin unsealed DeviceNet connector

Network
Status Indicator
NETWORK
STATUS
Module
Status Indicator
MODULE
DeviceNet CONTROLLER STATUS
DC
IN
(9V)

DeviceNET

PROCESSOR RS-232

RS232
STATUS
RS232
Status Indicator
RS232 PORT
1770KFD

9pin Dshell
RS232 connector

17706.5.22
 Module Communication Basics 1-3

Serial Connection The module can connect to any PC compatible desktop, laptop, and
notebook computer that is equipped with an RS-232 serial
communication-port. In addition, the module can connect to any
RS-232 device, which can include devices such as embedded
controls and RS-232 sensor products. During normal operation, a
connection between the host computer and the module is
continuously open.

The RS-232 link is limited in bandwidth when compared to the

DeviceNet network; however, the module has the ability to buffer
incoming network data so that nothing is lost. The speed of data
transfer between the host and module, or baud rate, is determined by
the host; the module autobauds to match this baud rate.

LinkLevel Communication The module uses a layered link-protocol, illustrated below, to

facilitate communication between your host and module. The
protocol layers described in the following sections make up the
required protocol between a host and module over the RS-232
serial-link.

1. The first two bytes of 3. The DeviceNet portion of

the protocol is this protocol contains a
fullduplex DF1 code CAN ID and a DeviceNet
that indicates the start message.
of a message.

DF1 PCCC DeviceNet DF1

2. The next five bytes is 4. The final three bytes of the

PCCC code. With the 1770KFD protocol is DF1
exception of the command code that terminates the
and packet counter bytes message and performs a
(transaction word, TNSW), validity check.
the module does not use
this code.

17706.5.22
 1-4 Module Communication Basics

DF1 FullDuplex Protocol

Reference Full-duplex combines features of subcategories D1 (data

Go to page: transparency) and F1 (two-way simultaneous transmission with
21 embedded responses) of ANSI x3.28. All communication between
the host and the module uses this protocol.

PCCC Protocol
PCCC protocol is descriptive data after the DF1 segment, which is
placed at the beginning of a DeviceNet message. Four of the five
inserted fields do not change; none of the fields need to be
manipulated. However, the fifth field is a packet counter that must be
incremented with each message. Note that each field is one byte long
except for this fifth field which is two bytes.

DeviceNet Protocol

Reference The DeviceNet protocol pertains to the actual network data

embedded inside a message exchanged between the module and host.
Go to page:
This information is being sent or received on or from a DeviceNet
32
network. In some cases, this information is destined for the module
only.

When the module receives a DeviceNet message from the network, it

attaches this packaging to the data before sending it to the host.
Before transmitting a DeviceNet message onto the network, the
module strips away the DF1 and PCCC packaging.

17706.5.22
 Module Communication Basics 1-5

The Module's Message Format

A basic DeviceNet message is packaged with DF1 and PCCC prefix

data and DF1 suffix data as illustrated below. For message
transmission between your host and module, the 1770-KFD protocol
uses the following message format:

Layer Name Type Description

DLE USINT DLE = 10hex
DF1
STX USINT STX = 02hex
DST USINT Destination = 0 (unused)
SRC USINT Source = 0 (unused)
Command = 0Chex
CMD USINT
PCCC (DeviceNet message)
STS USINT Status = 0 (unused)
packet counter (incremented
TNSW* UINT
The first two bytes of the every message)
data field contain an 11 CAN Indentifier (DeviceNet
bit CAN identifier. CAN ID UINT
format)
Data
CAN Data (DeviceNet format,
Data array of USINT
8 bytes maximum)
DLE USINT DLE = 10hex
DF1 ETX USINT ETX = 03hex
BCC USINT Block Check Character
Shading indicates values that do not change. They are listed for verification purposes only.
The TNSW (transaction word) is two bytes long.
For more information about the 8 bit Unsigned Short Integer
(USINT) and the 16 bit Unsigned Integer (UINT), refer to the Data
Management portion of the DeviceNet Specification, Volume I.

17706.5.22
 1-6 Module Communication Basics

ModuleSupported Objects There are several module-supported objects:

Object Function
used to provide the module's configuration and
status data
DeviceNet Object
the DeviceNet object is always created but
cannot be deleted
used to provide diagnostic data about the
DF1 Object
DF1 link
Reference used for general identification as a DeviceNet
Identity Object
network device
Go to page:
used to configure and maintain CAN identifier
A1 Link Object screeners which facilitate connected
networkmessaging
used to provide information about and to
Power Management Object
configure the product power supply
used to provide information about and to
RS232 Object
configure the seriallink's baud rate

Important: Devices on the network cannot directly access these

objects within the module. They can be accessed only
through the host over its RS-232 port.

17706.5.22
 Chapter 2
FullDuplex DF1 Protocol

Chapter Contents This chapter describes the data link-layer protocol your host and
module use to communicate. In addition, this chapter provides
full-duplex asynchronous link-protocol information as well as
information on data link-layer message-packet fields.

Because you are connecting an asynchronous interface-module to a

computer, you must program the computer to understand and to issue
the proper protocol-character sequences. Use this information to
determine how to program your host so that it can communicate with
your module.

For information about See page

character transmission 22
transmission symbols 22
message pakcet fields 23
twoway simultaneous operation 25
environment definition 25
host/module message transmission examples 212

This chapter explains how to use DF1 protocol to communicate with

the 1770-KFD interface module. However, it is not a comprehensive
explanation. For more information about DF1 protocol, refer to the
Data Highway/Data Highway Plus/DH-485 Communication
Protocol and Command Set reference manual.

About DF1 Protocol DF1 protocol is an Allen-Bradley link protocol that combines
features of subcategories D1 (data transparency) and F1 (two-way
simultaneous transmission with embedded responses) of
ANSI x3.28.

DF1 protocol:
• is used over a point-to-point link to facilitate two-way
simultaneous transmission
• is intended for high performance applications that require the
highest possible throughput from the available medium

17706.5.22
 2-2 Full-Duplex DF1 Protocol

Character Transmission The module sends data serially over the RS-232-C/RS-422-A
interface, one byte at a time. The transmission format conforms to
ANSI x3.16, CCITT V.4, and ISO 1177. Your computer should
conform to this mode of transmission:
• link protocol = full-duplex, DF1
• message type = asynchronous
• data size = eight bits
• parity = none
• stop bit = one
• validity check = block check character (BCC)

Transmission Symbols Full-duplex protocol is character-oriented. It uses the ASCII control

characters in the following table, extended to eight bits by adding a
zero for bit 7. DF1 combines these characters into control and data
symbols.

For the standard definition of these characters, refer to ANSI x3.4,

CCITT V.3, or ISO 646.

Abbreviation Hexadecimal value Binary value

STX 02 0000 0010
ETX 03 0000 0011
ENQ 05 0000 0101
ACK 06 0000 0110
DLE 10 0001 0000
NAK 15 0000 1111

The following symbols are used for communication between your

host and module:

Symbol Type Meaning

DLE STX control symbol sender symbol that indicates the start of a message
DLE ETX
control symbol sender symbol that terminates a message
BCC
response symbol that signals when a message is
DLE ACK control symbol
successfully received
response symbol that signals when a message is not
DLE NAK control symbol
successfully received
sender symbol that requests retransmission of a
DLE ENQ control symbol
response symbol from the receiver
single character data values between 000F and
APP DATA data symbol 11FF. Includes data from application layer including
user programs and common application routines
DLE DLE data symbol symbol that represents the data value 10hex

17706.5.22
 Full-Duplex DF1 Protocol 2-3

Message Packet Fields A data link-layer message packet starts with DLE STX and ends
with DLE ETX BCC, with application layer data in between. Data
symbols are only inside a message packet. Response symbols (DLE
ACK and DLE NAK) can also be transmitted inside a message
packet even though they are not considered part of it. Response
symbols transmitted within a message packet are referred to as
embedded responses.

Figure 2.1 shows the format of a full-duplex message packet and the
layer at which each portion is implemented. Note the BCC field at
the end of each message packet.

Figure 2.1
Packet Format for FullDuplex Protocol

From User
DST CMD STS Command Data Application
Program

From Common
DST * SRC * CMD* STS* TNSW
Data Application
00hex 00hex 0Chex 0Chex (From Application Layer) Routines

* these fields are

predefined values
for the module.

Data from BCC Data Link

DLE STX DLE ETX
Application Layers Field Layer Packet

Block Check

The block-check character (BCC) is a way of checking each

message-packet transmission’s accuracy. It is the two’s complement
of the eight-bit sum (module-256 arithmetic sum) of all application
layer data-bytes between a DLE STX and a DLE ETX BCC. It does
not include response symbols.

A message packet containing 08, 09, 06, 00, 02, 04, and 03
(decimal), appears as:
10 02 08 09 06 00 02 04 03 10 03 E0
DLE STX APP DATA DLE ETX BCC

The sum of the application data bytes in this message packet is 32

decimal or 20hex. The BCC is the 2’s complement of this sum, or
E0hex as shown in the binary calculation below:

0010 0000 20hex

1101 1111 1's compliment
+1

1110 0000 2's compliment (E0hex)

17706.5.22
 2-4 Full-Duplex DF1 Protocol

To quickly determine a BCC value, add up the application-layer

byte’s hex values. If the total is greater than 100hex, drop the most
significant digit. Then, subtract the result from 100hex. This should
give you the BCC. For example, the sum of 20hex, then:

100hex
20hex
____
E0hex

Important: To transmit the value 10hex, you must use the data
symbol DLE DLE. However, only one of these DLE
data bytes is included in the BCC sum. For example, to
transmit the values 08, 09, 06, 00, 10, 04, and 03hex,
you would use the following message symbols:
10 02 08 09 06 00 10 10 04 03 10 03 D2
DLE STX APP DATA (DLE DLE) DLE EXT BCC

In this case, the sum of the application-layer data bytes is 2Ehex

because only one DLE byte is included in the BCC; therefore, the
BCC is D2hex.

Important: The BCC algorithm provides only a medium level of

data security. It cannot detect transposition of bytes
during transmission of a packet. It also cannot detect the
insertion or deletion of the value zero within a packet.

17706.5.22
 Full-Duplex DF1 Protocol 2-5

TwoWay Simultaneous To communicate with full-duplex protocol, the network uses two
Operation physical circuits (cable systems) for two-way simultaneous message
transmission. Figure 2.2 shows an example of two-way
simultaneous operation.

Figure 2.2
Data Paths for TwoWay Simultaneous Operation

Path 1
Transmitter A Receiver B
Path 2

Path 3
Receiver A Transmitter B
Path 4

On the first circuit, transmitter A sends messages to receiver B (data

path 1) and receiver A sends response control symbols (DLE ACK,
DLE NAK) to transmitter B (data path 3).

On the second circuit, transmitter B sends messages to receiver A

(data path 4) and receiver B sends response control symbols (DLE
ACK, DLE NAK) to transmitter A (data path 2).

All messages and symbols on the first circuit are traveling in the
same direction (node A to node B) and all messages and symbols on
the second circuit are traveling in the opposite direction (B to A).

To implement four data paths with only two physical circuits, a

software multiplexer is needed to combine the message symbols with
the response symbols going in the same direction.

At the other end of the link, a software separator divides the message
symbols from the response symbols. The internal software sends the
message symbols to the appropriate receiver and the response
symbols to the appropriate transmitter.

Environment Definition To fully define the environment’s protocol, the transmitter needs to
know where to get the message it sends, and the receiver must have a
means of disposing of messages. These are
implementation-dependent functions which are respectively called
the message source and the message sink.

We assume that the message source:

• supplies one message at a time upon request from the transmitter
• requires notification of the success or failure of the transfer
before supplying the next message

17706.5.22
 2-6 Full-Duplex DF1 Protocol

When the message source is empty, the transmitter waits in an

inactive state until a message is available.

Whenever the receiver has received a message successfully, it

attempts to give it to the message sink. If the message sink is full, the
receiver must be notified.

Figure 2.3 shows the protocol environment for message symbols

from transmitter A to receiver B (path 1) and response codes from
receiver B to transmitter A (path 2).

Figure 2.3
Protocol Environment

Packet Packet
Path 1
Transmitter Receiver
Source Sink
A B

Path 2
Packet Status Sink Full

How the Transmitter Operates

Whenever the message source can supply a message and the

transmitter is not busy, it sends a message packet. It then starts a
timeout, and waits for a response symbol.

When a DLE ACK is received, the message has been successfully

transferred. After signaling the message source that the message was
successfully transmitted, the transmitter proceeds with the
next message.

If a DLE NAK is received, the message is retransmitted. The

transmitter restarts the timeout and waits again for a response. This
can be repeated several times. You can set a limit to the number of
times a message can be retransmitted for each module. If this limit is
exceeded, the message source is informed of the failure and the
transmitter proceeds with the next message.

If the timeout expires before a response is received, the transmitter

sends a DLE ENQ to request a retransmission of the last response. It
restarts the timeout and waits for a response.

You can also set a limit on the number of timeouts that are allowed
per message. If the enquiry (ENQ) limit is exceeded, the transmitter
signals the message source that the transmission has failed, and the
transmitter proceeds to the next message.

17706.5.22
 Full-Duplex DF1 Protocol 2-7

Since there are only two response symbols defined, all other symbols
are undefined or invalid. If an invalid or undefinedresponse symbol
is received, the transmitter ignores it. A more precise and detailed
description of the actions of the transmitter appears in the following
structured English procedure.

TRANSMITTER is defined as
loop
Message=GET-MESSAGE-TO-SEND
Status=TRANSFER(Message)
SIGNAL-RESULTS(Status)
end loop
TRANSFER (Message) is defined as
initialize nak-limit and enq-limit
SEND(Message)
start timeout
loop
WAIT for response on path 2 or timeout.
if received DLE ACK then return SUCCESS
else if received DLE NAK then
if nak-limit is exceeded then return FAILURE
else
begin
count NAK re-tries;
SEND-MESSAGE(message);
start timeout
end
else if timeout
if enq-limit is exceeded then return FAILURE
else
begin
count ENQ re-tries;
send DLE ENQ on path 1;
start timeout
end
end loop
SEND (message) is defined as
begin
BCC = 0
send DLE STX on path 1
for every byte in the message do
begin
add the byte to the BCC;
send the corresponding data symbol
on path 1
end
send DLE ETX BCC on path 1
end
GET-MESSAGE-TO-SEND
This is an operating-system-dependent interface
routine that waits and allows the rest of the
system to run until the message source has supplied
a message to be sent.
SIGNAL-RESULTS
This is an implementation-dependent routine that
gives the message source the results of the
attempted message transfer.
WAIT
This is an operating-system-dependent routine
that waits for any of several events to occur
while allowing other parts of the system to run.

17706.5.22
 2-8 Full-Duplex DF1 Protocol

Figure 2.4 is a flowchart of the software logic for implementing

the transmitter.

Figure 2.4
Software Logic for Implementing Transmitter

T
Retransmit Same Message

Message Packet

DLE STX Data DLE ETX BCC Field

Timeout Loop

Received No No No
Received
DLE ACK? Timed out?
DLE NAK?

Yes Yes Yes

3* NAKs Yes Yes

received for this P 3* timeouts for
message? this message?

Legend:
No No
T = Ready to Transmit Next Message

P = Recovery Procedure DLE ENQ

* Default Values used by the Module

Important: Depending on data-traffic and saturation level, you may

need to wait for a reply from the remote node before
transmitting the next message. You should implement
an option that lets the user choose the maximum
amount of outstanding messages that can exist at one
time. We suggest a selectable range of one to
three messages.

How the Receiver Operates

The receiver must be capable of responding to many adverse

situations. Many problems can arise.

17706.5.22
 Full-Duplex DF1 Protocol 2-9

Some of the problems that can occur are:

• the message sink may be full, leaving the receiver with nowhere
to put a message
• a message may contain a parity error
• the BCC may be invalid
• the DLE STX or DLE ETX BCC may be missing
• the message may be too long or too short
• a spurious control or data symbol may occur outside a message
• a spurious control symbol may occur inside a message
• the DLE ACK response may be lost, causing the transmitter to
send a duplicate copy of a message already passed to the
message sink
The receiver keeps a record of the last response sent to the
transmitter. The value of this response is either ACK or NAK. It is
initialized to NAK. When a DLE ENQ (enquiry) is received from the
transmitter, the receiver sends the value of the last response.

The receiver ignores all input until receiving a DLE STX or a DLE
ENQ. If anything other than a DLE STX or DLE ENQ is received on
path one, the receiver sets the last response variable to a NAK.

If Then
the last response is sent and the receiver
a DLE ENQ is received from the transmitter
continues waiting for input
the BCC and message buffer are reset - and the
a DLE ACK is received
receiver starts building the message

While building a message, all data symbols are stored in the message
buffer and added to the BCC. If the buffer overflows, the receiver
continues summing the BCC, but the data is discarded.
If Then
any control symbols other than a DLE ETX BCC the message is aborted and a DLE NAK is sent
are received to the transmitter
the error flag (the BCC), the message size, and
a DLE ETX BCC is received
the address (optional) are all checked
the BCC, message size, or address
a DLE NAK is sent
test fails
duplicate message detection is enabled, the
the duplicate message is discarded without being
message is valid, and its header is the same as
executed and a DLE ACK is sent
the previous message
duplicate message detection is enabled, the
message is valid, but the header is not the same the messagesink's state is tested
as the previous message
if the message sink is full a DLE NAK is sent
the message is forwarded to the
message sink, the header information
if the message sink is not full
is saved for the duplicate message
detector, and a DLE ACK is sent

17706.5.22
 2-10 Full-Duplex DF1 Protocol

GETCHAR is defined as an RECEIVER is defined as

implementationdependant variables
function that returns one byte LAST-HEADER is 4 bytes copied out of the last good message
of data from the link RESPONSE is the value of the last ACK or NAK sent
interface hardware BCC is an 8-bit block check accumulator
LAST-HEADER = invalid
LAST RESPONSE = NAK
loop
reset parity error flag
GET-SYMBOL
if DLE STX then
begin
BCC = 0
GET-SYMBOL
while it is a data symbol
begin
if buffer is not overflowed put
data in buffer
GET-SYMBOL
end
if the control symbol is not a DLE ETX then send DLE
NAK
else if error flag is set then send DLE NAK
else if BCC is not zero then send DLE NAK
else if message is too small then send DLE NAK
else if message is too large then send DLE NAK
else if header is same as last message send a DLE ACK
else if message sink is full send DLE NAK
else
begin
send message to message sink
send a DLE ACK
save a last header
end
end
else if DLE ENQ then send LAST-RESPONSE
else LAST-RESPONSE = NAK
end loop
GET-SYMBOL is defined as
loop
GET-CHAR
if char is not DLE
begin
add char to BCC
return the char and data flag
end
else
begin
GET-CHAR
if char is a DLE
begin
add char to BCC
return DLE and data flag
end
else if char is an ACK or NAK send it to the transmitter
else if char is an ETX
begin
GET-CHAR
add char to BCC
return ETX with a control flag
end
else return char with a control flag
end
end loop
GET-CHAR is defined as an implementation-dependant function that returns one byte
of data from the link interface hardware

17706.5.22
 Full-Duplex DF1 Protocol 2-11

Figure 2.5 is a flowchart of the software logic for implementing

the receiver.

Figure 2.5
Receiver for FullDuplex Protocol

RCVE

LAST = NAK

Received Yes
DLE
ENQ?

No

No
Received
message?

Yes

No
BCC LAST = NAK
OK?

Yes

LAST = ACK

Send DLE LAST

17706.5.22
 2-12 Full-Duplex DF1 Protocol

Host/Module Message The following sections illustrate basic message transmissions and
Transmission Examples responses between a host and its module. The purpose of these
examples is to illustrate how DF1 protocol is used; therefore, the
DeviceNet message within is unimportant at this point. Chapter 4
illustrates the nested DeviceNet messages that are used to access the
module’s local objects.

Important: PCCC protocol is not illustrated in the following

figures. However, it resides in each of these local
messages (between the DF1 prefix data and the
DeviceNet message).

Normal Message Transmission

An example of a normal message transfer, shown below in Figure

2.6, illustrates a DeviceNet message wrapped in DF1 protocol.

Figure 2.6
Normal Message Transfer
Source (host) Transmitter Link Receiver Sink (module)
Note: xxxx = DeviceNet message
Command xxxx
DLE STX xxxx DLE ETX BCC
In this figure: not full
• the transmitter sends the xxxx
message to the receiver DLE ACK
OK
• the sink sends a
not full" message
(Sometime Later ...)
• the receiver sends the message
to the sink and sends a DLE ACK DLE STX xxxx DLE ETX BCC
to the transmitter not full
• the transmitter tells the source Reply xxxx
that the message was delivered
• reply is successfully returned DLE ACK
from the network OK

17706.5.22
 Full-Duplex DF1 Protocol 2-13

When a Message Transfer Fails

Figure 2.7 illustrates what happens when the module receives

corrupted data, shown as “??.”

Figure 2.7
Message Transfer with NAK
Source (host) Transmitter Link Receiver Sink (module)
Note: xxxx = DeviceNet message
Command xxxx
In this figure: DLE STX x??x DLE ETX BCC
• the transmitter sends a corrupted DLE NAK
message to the receiver and the DLE STX xxxx DLE ETX BCC
receiver responds with a DLE NAK not full
• the transmitter retransmits; the xxxx
transmission is successful
DLE ACK
• reply is successfully returned from OK
the network
(Sometime Later ...)
DLE STX xxxx DLE ETX BCC
not full
Reply xxxx
DLE ACK
OK

In addition to the example above, a DLE NAK can occur if:

• a reply is corrupted
• the receiving device’s buffers are full
Both the host and module use a DLE NAK. If the module sends your
host an invalid message, your host will reply with a DLE NAK.

17706.5.22
 2-14 Full-Duplex DF1 Protocol

When a Retransmission is Requested

In some cases, as illustrated in Figure 2.8, the host or module can

request a message retransmission.

Figure 2.8
Message Transfer with Retransmission
Note: xxxx = DeviceNet message Source Transmitter Link Receiver Sink

In this figure: Command xxxx

• Noise destroys the DLE ACK DLE STX xxxx DLE ETX BCC
• The transmitter timesout waiting not full
for the response and sends a xxxx
DLE ENQ which is also destroyed DL???CK
by noise. (Timeout)
• because of the invalid characters, ???
the receiver changes its last (Timeout)
response to a DLE NAK
• since the DLE ACK was DLE ENQ
destroyed, the transmitter sends
a DLE ENQ (enquiry), and the DLE NAK
receiver returns the DLE NAK DLE STX xxxx DLE ETX BCC (duplicate message)
• the transmitter retransmits the OK DLE ACK
message and the receiver sends (Sometime Later ...)
an ACK
• the receiver discards the DLE STX xxxx DLE ETX BCC
duplicate message (if duplicate not full
message detection is enabled on
Reply xxxx
your module)
DLE ACK
• reply is successfully returned OK
from the network

17706.5.22
 Chapter 3
Module Communication Over
the DF1 Link

Chapter Contents This chapter explains each of the components needed for
communication between the host and module over the DF1
protocol link.

For information about See page

The RS232 heartbeat 32
Host and module local connections 32
Before network communication 34
Communication on the DeviceNet network 35

Module SerialLink Autobaud Your module needs to detect the baud rate between it and the host
upon power-up or when the heartbeat between your host and module
stops. To accomplish this, your host must send the following
message until the module responds.

hexadecifmal value 10 05
symbol DLE ENQ
hexadecifmal value 10 05
symbol DLE ENQ
The module returns the following message to your host when
serial-link autobaud is complete. This message indicates to your host
that the module is ready to communicate.
hexadecifmal value 10 15
symbol DLE NAK

NETWORK
STATUS
The Module Status Indicator flashes green
when your module is in the seriallink
MODULE autobaud detectionstate and turns solid
STATUS green when the baud rate is acquired.
DC
IN
(9V)

DeviceNET

RS-
232

17706.5.22
 3-2 Module Communication Over the DF1 Link

The RS232 Heartbeat Since there is no DF1-level heartbeat, the DCD signal at the
module’s RS-232 port is used to indicate that the host is active. If the
DCD is lost for 500 milliseconds or more, the module:
• drops DTR for 1 second
• disables the CAN network
• deletes all connection links
• returns to serial-link autobaud state

Host and Module Local To communicate with the module over a predefined
Connections local-connection, the host wraps DeviceNet protocol with DF1 and
PCCC protocol and uses the invalid CAN ID:
FFFFhex

The message’s body format is set to DeviceNet 8/8:

Class = 8 bit integer Instance ID = 8 bit integer

Layer Name Description

DLE DLE = 10hex
DF1
STX STX = 02hex
DST Destination = 0 (unused)
SRC Source = 0 (unused)
Command = 0C hex
PCCC CMD
(DeviceNet message)
STS Status = 0 (unused)
TNSW Packet Counter

FFFFhex CAN Indentifier (DeviceNet

CAN ID
format)
Data
CAN Data (DeviceNet
Data
format, 8 bytes maximum)
DLE DLE = 10hex
DF1 ETX ETX = 03hex
BCC Block Check Character

For more information about DeviceNet protocol, refer to the

DeviceNet Specification, Volume 1.

17706.5.22
 Module Communication Over the DF1 Link 3-3

Accessing Local Objects

The purpose of using FFFF to address the module is to access objects

residing within the module. Each of the module-supported objects,
listed in chapter 1, have a specific function. These functions range
from maintaining the host/module local connection to facilitating
communication on the DeviceNet network. Objects make it possible
for the module to perform its duties as the host’s interface to the
network. The code used to manipulate these objects is inside the
DeviceNet message.

The example below illustrates how the host accesses local objects
within the module. In this particular example, the host is resetting the
module’s RS-232 object.
Indicates the beginning This ID indicates this DeviceNet Indicates the end of
of the message message is for the module the message

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 10 03 8D
value

symbol DST SRC CMD STS TNSW

This particular DeviceNet message
hexadecimal 00 00 0C 00 5D 00 3E 05 C8 01 is telling the module's RS232
value object, instance 1 to reset.

hex value description

3E This is the node address. 3E in
decimal is 62. This value is arbitrary.
05 This is the service code. 05 means Reset.
C8 This is the class code. It identifies which
object the host is trying to access. C8 is
the RS232 object.
01 This value is indicating an instance of
the selected object. 01 is instance 1.

17706.5.22
 3-4 Module Communication Over the DF1 Link

Inside the DeviceNet Message

When the FFFF address is used, the module reads the DeviceNet
message to follow; it does not pass the message to the network. The
following list is the structure of a DeviceNet message sent from a
host to a module.
• the module’s node address
• service-code (the command you give to the specified object)
• class-code of the object for which the service-code is sent
• the object’s instance for which the service-code is sent
• the instance’s attribute for which the service-code is sent (only
when applicable)
• the value you need to apply to the specified attribute (only when
applicable)
Important: All code in any message between the host and module
is hexadecimal, including the values within the
DeviceNet message.
The following table is a listing of hexadecimal common-service
codes that are used to manipulate your module’s objects.

Hexadecimal
Service name
service code
get_attribute_single 0E
set_attribute_single 10
reset 05
start 06
stop 07
create 08
delete 09

Before Network Before you can use the module to communicate on the network, you
Communication must first access the appropriate objects within the module to:
• stop the module if you need to re-initialize
• configure node address and baud rate
• start the module

Stop Service

If your module has already been activated, we recommend that you

send a stop service to the module’s DeviceNet object. This makes
sure that your module is not actively receiving and sending messages
and is ready to be configured.

17706.5.22
 Module Communication Over the DF1 Link 3-5

Configure Node Address and Baud Rate

Reference Before your module can communicate on a DeviceNet network, you

Go to page: must configure the node address and baud rate. This is done by
45 sending the set_attribute_service to the module’s DeviceNet object
(Class DeviceNet, Instance 1, Attributes 1 and 2).

Important: The module uses two baud rates. The first is the rate at
which data is exchanged between it and the host; this is
where the serial-link autobaud function is applied. The
second is the rate at which data is sent to and received
from the devices on the DeviceNet network; this is
where the set_attribute_service to the DeviceNet object
is applied.

Start Service

To activate DeviceNet network communication you must send a

start service to the module’s DeviceNet object. Upon receiving this
message, the module:
• validates the node address and baud rate
• initializes and starts the CAN chip
• performs a duplicate node address check
When the Network-Access State Machine is completed the module
returns a response. The duration between sending the start service
message and receiving the start response is arbitrary; however, this
time is never less than two seconds.

For more information about the Network-Access State Machine,

refer to the DeviceNet Specification, Volume 1.

Communication On The As an interface for your host, the module sends messages to and
DeviceNet Network receives messages from devices on the network. It passes messages
from your host to the network and determines which DeviceNet
messages to accept from the wire. The module also supports
unconnected messages by passing them through to the host’s
Unconnected Message Manager (UCMM).

17706.5.22
 3-6 Module Communication Over the DF1 Link

Sending and Receiving Unconnected DeviceNet Messages

Before a connection has been established, a device may contact the

host through its UCMM. A DeviceNet device, when online, always
has two unconnected message ports available, one for receiving and
one for sending UCMM messages. A UCMM object resides in the
host and not in the module; therefore, any unconnected message the
module receives is passed directly to the host. It is through this
unconnected messaging that a connection is established between the
host and a DeviceNet device.

1. Device 22 needs to set up a connection

with the host (device 62). Device 22's
UCMM sends an unconnected message
(openconnection request) via the
DeviceNet network.
Device 62
2. The unconnected message is accepted
1770KFD RS232 Link Host through the module's UCMM
Device 22 receive port.
3. The unconnected message travels
through the module, over the RS232
1 2 3 seriallink, and to the host's
UCMM UCMM object.
UCMM
6 5 4 4. The host sends a connectionrequest
response via the module.
5. Through the module's UCMM transmit port, the
response is sent over the network to the
7 requesting device.
6. Device 22 receives the openconnection
response from the host through its UCMM.
7. A connection is created. This connection will
remain as long as Device 22 and the module
are online. All consequent communication
between Device 22 and the host will occur
over this connection unless either the module
or device goes offline. If either component
goes offline , the connection must be
renegotiated through the UCMM function.

Sending DeviceNet Messages

The module transmits onto the network any DeviceNet message it is

given by the host, provided the CAN ID is valid. Messages bound for
the network do not pass through screeners or any other similar
objects in the module.

17706.5.22
 Module Communication Over the DF1 Link 3-7

Receiving Connected DeviceNet Messages

Reference After a connection has been established, the host must create
screeners in the module. Screeners are created for every device
Go to page:
connection from which you need to receive messages, other than
48
unconnected messages. A different screener is created for each of
these device connections. Each screener is responsible for
recognizing a particular CAN ID; they pass any message with a
matching CAN ID to the host. Screeners can be created and deleted
as needed.

To create a screener, the host sends a create service message to the

module’s link object, class code = CBhex, instance 00hex. The CAN
ID that you want screened becomes the first part of the create
service. Screeners stay in place until deleted by the host using the
delete service or when the module goes offline.

17706.5.22
 Chapter 4
Link Communication Example

Chapter Contents This chapter presents full-duplex, DF1-communication examples

between a host and module. There is an example of each major task
you perform to enable network communication via the 1770-KFD
interface module. These include:
• initializing your module
• creating screeners
• deleting screeners
This chapter’s examples were created with the following
assumptions in mind.
• The hexadecimal value, 3e (decimal value = 62) is your host’s
node address.
Important: Your host’s node address is completely arbitrary. You
can set its ID to whatever value fits your structure and
the DeviceNet network’s specifications.
• PCCC protocol, which is not included in these examples, is
present during communication between a host and module.
• The PCCC protocol packet-counter (TNSW), though not shown,
is incremented in each message.
• The DF1 block check character, though not shown as a true value
in these examples, is calculated for each message exchanged
between a host and module.
For information about See page
Initializing your module 42
Creating screeners 48
Deleting screeners 49

17706.5.22
 4-2 Link Communication Example

Initializing Your Module To initialize your module, perform the processes listed below.

Important: If you are re-initializing your module, you must begin

by resetting your module. If you are initializing your
module for the first time, skip the module reset and
begin with the serial-link autobaud function.
Object's
To reinitialize your Hexadecimal Corresponding
module, begin here. Process Command class code
value local object
(in hex)
module reset reset 05 RS232 C8
If you are initializing seriallink
your module for the DLE ENQ 10 05 N/A N/A
autobaud
first time, begin here.
stop service stop 07 DeviceNet 03
set node set_attribute_
10 DeviceNet 03
address single
set_attribute_
set baud rate 10 DeviceNet 03
single
start service start 06 DeviceNet 03

This step is for Module Reset

reinitialization only.
Since you will be configuring your module, you need to clear the
module by resetting it. To reset your module, send the reset
command to the module’s RS-232 object, instance 1.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
05 reset

C8 RS23 object

01 instance 1

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
85 reset response

17706.5.22
 Link Communication Example 4-3

SerialLink Autobaud

So that your host and module can communicate properly, the module
must set its serial-link baud rate to match your host. To accomplish
this, repeatedly send a response-retransmission request (10 05hex) to
the module. You will know the module has acquired the proper baud
rate when it returns a message non-acknowledgment (10 15hex) and
its module-status indicator is solid green.
message sent from your host to your module over the RS232 seriallink

Only these DF1 hex These portions of a message are not

values are needed needed for the seriallink autobaud
to initiate the function. No object instance
seriallink autobaud is accessed.
function.

symbol DLE ENQ PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 05
value

message sent from your module to your host over the RS232 seriallink

symbol DLE NAK

hexadecimal 10 15
value
Important: After transmitting the 10 05hex, your host needs to wait
a reasonable amount of time for the module to respond
before your host retransmits this message. In a
“worst-case-scenario,” this amount of time could range
from 50 to 100 milliseconds.

17706.5.22
 4-4 Link Communication Example

Stop Service

When you send a stop message to your module, the module ceases
all network activities; it prepares the module for configuration. To
stop your module, send a stop message to its DeviceNet object’s
instance 1.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
07 stop

03 DeviceNet object

01 instance 1

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
87 stop response

17706.5.22
 Link Communication Example 4-5

Set Node Address

Since the module is one part of the overall device (the host and
module together constitute one device) you set the module’s node
address to match your host. To set your module’s node address, send
a set_attribute_single with the ID value to the DeviceNet object’s
instance 1, attribute 1.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
10 set_attribute_single

03 DeviceNet object

01 instance 1

01 attribute 1

3E 62

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
90 set_attribute_single
response

17706.5.22
 4-6 Link Communication Example

Set Baud Rate

You set the baud rate at which you would like to communicate on the
DeviceNet network via the DeviceNet object. To set the baud rate at
which your module will communicate on the network, send a
set_attribute_single with the baud rate value to the DeviceNet
object’s instance 1, attribute 2.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
10 set_attribute_single

03 DeviceNet object

01 instance 1

02 attribute 2
There are three allowable baud 00 baud rate
rates that are represented by
hexadecimal values.
• 00hex = 125 kbps
• 01hex = 250 kbps
• 02hex = 500 kbps

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
90 set_attribute_single
response

17706.5.22
 Link Communication Example 4-7

Start Service

The final step of initialization is to start the module. You start the
module by sending a start service-code (06hex) to its DeviceNet
object’s instance 1.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
06 start

03 DeviceNet object

01 instance 1

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
86 start response

17706.5.22
 4-8 Link Communication Example

Creating Screeners Screeners facilitate connected message transfers between your host
and devices on the network. To communicate with a network device
via connected messages, you must create a screener for the device
within the Link object. This is accomplished by sending a create
service-code to the Link class. In this example, we are creating a
screener for a network device with the node address 22.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
08 create

CB Link object

00 instance 0

0616 Group 3, message ID 0

from device 16hex.
(16hex = 22 dec)

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
88 create response

0100 the created link object's

instance ID

17706.5.22
 Link Communication Example 4-9

Deleting Screeners You can delete screeners for devices with which you no longer need
to communicate via connected messages. To delete a screener, send a
delete service-code to the Link object. In this example, we are
deleting the screener we created in the previous example.

message sent from your host to your module over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
09 delete

CB Link object

01 instance 1

16 node address
(16hex = 22dec)

message sent from your module to your host over the RS232 seriallink

8 byte maximum
symbol DLE STX PCCC data CAN ID DeviceNet data DLE ETX BCC

hexadecimal 10 02 FFFF 3E node address 62 10 03 XX

value
09 delete response

17706.5.22
 Appendix A
Module Supported Objects

Appendix Contents This appendix describes each module-supported object, covering

only those attributes and services specific to the module.

Important: Except for the Link object, the module does not support
class-level attributes or services of its objects.
For information about See page
1770KFD DF1 object A3
Identity object A4
Link object A6
Power Management object A7
RS232 object A7

Because this appendix is specific to the 1770-KFD interface-module,

much detail on the objects described here is omitted. For more
information about object definitions, refer to the DeviceNet
Specification, Volumes I and II.

DeviceNet Object The DeviceNet object provides the configuration and status for a
physical attachment to the DeviceNet network. Each physical
network-attachment in a device (there can be more than one per
Class ID Code: 03hex device) has one and only one DeviceNet object. This is a required
object for all DeviceNet devices.

Instance Services

Codehex Name Description

used to read a DeviceNet Object
0E get_attribute_single
attribute value
used to modify a DeviceNet Object
10 set_attribute_single
attribute value

Instance Attributes

Access
ID Name Data Type Description Value
Rule
node
1 get/set MAC ID USINT range 063
address
2 get/set baud rate USINT baud rate range 02

17706.5.22
 A-2 Module Supported Objects

MAC ID:
The host and the module together constitute one device. The MAC
ID for this device is held in the module’s DeviceNet object.

To modify the MAC ID, you must delete all connection objects and
re-execute the Network Access State Machine. To accomplish this,
you must:

1. Send a stop service.

2. Reconfigure.
3. Send a start service (restart).

Baud Rate:
The baud rate attribute indicates the selected rate as listed below:

Value Meaning
00 125 kbps
01 250 kbps
02 500 kbps

To modify the baud rate you must delete all connection objects and
re-execute the Network Access State Machine. To accomplish this,
you must:

1. Send a stop service.

2. Reconfigure.
3. Send a start service (restart).

17706.5.22
 Module Supported Objects A-3

1770KFD DF1 Object The host uses the module’s DF1 object to track communication on
the RS-232 serial-link. It logs all DF1 communication on this link
and can be accessed by sending a get_attribute_single. Different
Class ID Code: C9hex bytes carry specific counters. These bytes are what the host reads to
obtain the desired data, such as how many ACKs were received.

Instance Services

Codehex Name Description

0E get_attribute_single retrieves information stored in a DF1 counter

Instance Attributes

Access
ID Name Data Type Description Value
Rule
DF1 error tracks serial link
5 get USINT[34] see Table A.A
counters communication

Table A.A
ModuleSpecific Counter Bytes
Counter byte Counts
35, 36 number of times the node attempted to send a message
messages that were successfully transmitted
37, 38
and ACKed
39, 40 ACKs that were received
42 NAKs received
45 ENQs sent
46 messages that could not be successfully sent
48, 49 messages received
50, 51 ACKs sent
52 NAKs sent
53 ENQs received
55 STXs received
57 messages that were aborted by receipt of DLE ENQ
messages that were aborted by the receipt of an
58
unexpected control code other than DLE ENQ
60 times DLE NAK was sent because there was no buffer
67 times that DCD was lost

17706.5.22
 A-4 Module Supported Objects

Identity Object The identity object provides general information about its device.
This object must be present in all DeviceNet products.

Class Code: 01hex

Class Services

Codehex Name Description

returns the contents of the specified
0E get_attribute_single
attribute
05 reset invokes the Reset service for the device.

Instance Attributes

Access
ID Name Data Type Description
Rule
identification of each
1 get vendor UINT
vendor by number
indication of general type
2 get device type UINT
of product
identification of a particular
3 get product code UINT product of an
individual vendor
4 get revision STRUCT of
revision of the item the
major revision USINT identity object represents
minor revision USINT
5 get status WORD summary status of device
6 get serial number UDINT serial number of device
SHORT human readable
7 get product name
STRING identification
8 get state USINT present state of the device

17706.5.22
 Module Supported Objects A-5

Vendor
If the returned attribute equals zero, it means “Unknown.”

Device Type

Every DeviceNet vendor uses the same list of device types to:
• register assembly-object instance definitions
• provide a scope for the product-code numbers
If the returned attribute equals zero, it means “Generic Device.” An
explanation of the generic device must be supplied in the
vendor documentation.

For a listing of the presently defined Device Types, refer to the

DeviceNet Specification, Volume II.

Product Code
The product code identifies a product among a particular device
type. Each vendor assigns this code to each of its products. The
product code should map to a catalog/bulletin number.

The value zero is reserved to mean “Unassigned.” If the returned

attribute equals zero, it means “Generic Vendor Product.”

Revision
The revision attribute, which consists of major and minor revisions,
identifies the revision of the item this object represents.

If the returned attribute equals zero, it means “Unknown.”

The major and minor attributes, referred to above, are sometimes

called a series and revision, respectively. The major-revision
attribute is limited to seven bits. The eighth bit is reserved by the
DeviceNet network and must have a default value of zero.

Status
This attribute represents the current status of the entire device. Its
value changes as the state of the device changes.

Serial Number
This attribute is a number used in conjunction with the vendor
number to form a unique identifier for each device on a
DeviceNet. network

State
This attribute is an indication of the present state of the device.

17706.5.22
 A-6 Module Supported Objects

Link Object You create CAN ID screeners in the link object. These screeners
make it possible for the module to receive messages from selected
network devices and pass that message on to your host. Screeners are
Class Code: CBhex similar to a list of passwords. When the module detects a message on
the network, it checks its CAN ID and compares it to its screeners in
the link object. If the message has a matching password (CAN ID)
then it is accepted and passed on the host.

Class Services

Codehex Name Description

08 create configures ID screener
09 delete deletes all screeners

Instance Services

Codehex Name Description

deletes a specified,
09 delete
single sreener

Instance Attributes

Access
ID Name Data Type Description Value
Rule
sets CAN ID to
1 get/set screened ID WORD 11 bit identifier
screen on
There can be a maximum of 128 screeners created.

17706.5.22
 Module Supported Objects A-7

Power Management Object The power management object holds information about the module’s
network power supplying function. In addition, it facilitates
terminating resistor configuration.

Class Code: CAhex Instance Services

Codehex Name Description

used to access data indicating status of the
0E get_attribute_single
power settings
modifies the attribute responsible for the
10 set_attribute_single
terminating resistor

Instance Attributes

Access
ID Name Data type Description
Rule
indicates whether or not the
1 get supply network power USINT module is supply network
power
indicates whether or not
2 get network power USINT
network power is present
indicates if the terminating
3 get/set terminating resistor USINT resistor is on. Toggles the
resistor on or off

Values for
Definition
Attribute 1
0 network
1 power supply
2 batteries

RS232 Object The RS-232 object maintains the module’s serial-link autobaud
function before and after acquiring that rate. However, it only
maintains the rate of data exchange between the host and module. Do
Class Code: C8hex not confuse this object’s function with the DeviceNet object. The
DeviceNet object acquires and maintains the DeviceNet network
baud rate. In addition, you access the RS-232 object before
initializing the module; you send a reset command to this object to
clear the module before configuring it, which includes “serial-link
autobauding.”

Instance Services

Codehex Name Description

clears the instance in preparation for the
05 reset
seriallink autobaud function

17706.5.22
 Appendix B
Troubleshooting

Appendix Contents This appendix lists problems you may encounter when working with
your 1770-KFD module on the link layer. It covers the most
commonly encountered errors.

Status-indicator lights on the module can point to several types of

errors. The lights may appear in a number of different states to
indicate different problems or processes.

RS232 Status Indicator

condition status
off no activity, link OK
flickering green activity, link OK
RS232 Status solid red link failed (critical fault)
Module Status indicator
indicator flashing red link failed (noncritical fault)
Network Status Network Status Indicator
indicator
condition status
off offline
flashing green online
solid red link failed (critical fault)
solid green online, communicating
Module Status Indicator
condition status
off no power
solid green device OK
flashing green not configured
solid red critical fault
flashing red noncritical fault

17706.5.22
 B-2 Troubleshooting

Troubleshooting the Module The following table lists common errors encountered when
communicating with your module on the link layer. The first column
in each category describes a “symptom” that is then followed by a
list of status-indicator states, probable causes, and recommendations
on how to correct the error.

Important: Due to the wide range of hardware and software

combinations used by developers, this troubleshooting
section cannot be a comprehensive list of errors.
However, we recommend that when you encounter an
error, check here before calling technical support.
Error Category Where To Look Possible Cause Recommendation
RS232 status indicator An incorrect baud rate or Be sure that your PC's baud
is flashing red. parity error has rate is module supported (see
been detected. page 12). Be sure there is no
parity used and that the
character size is 8 bits.
Module status indicator No baud rate has Initiate autobaud.
is flashing green. been detected.
Module status indicator The module has an Replace your
is solid red. unrecoverable fault. 1770KFD module.
No communication occurring
between your PC and the the RS232 cable G Cable is not connected G Be sure to securely attach
module. properly to the PC the cable to the PC and
or module. module's respective
G Cable does not have the RS232 serial ports.
proper internalwire G Replace cable with an
crossover. AllenBradley approved
RS232 serial cable.
your software Your software is not asserting Refer to your particular
DTR (dataterminalready). software application's user
manual or programming
instruction guide.

17706.5.22
 Troubleshooting B-3

Error Category Where To Look Possible Cause Recommendation

Network status indicator The module is offline because G Activate your module on
is off. its DeviceNet cable may not the DeviceNet network by
be properly connected sending the start service.
G Check the network and its
devices to be sure they
have been
properly installed.
G Be sure the DeviceNet
cable connecting the
module to the network is
properly installed, including
No communication occurring the 5position connector at
between the module and the the module's
DeviceNet network. DeviceNet port.
Network status indicator The module has not been Create screeners within the
is flashing green. configured for connected module's link object
messages (no screeners set (see page 48).
up to receive connected
DeviceNet messages).
Network status indicator The module has detected an Be sure that all of your
is solid red. error that is prohibiting devices are set to the correct
communication on the link. baud rate. In addition, be sure
This could include detection that no two nodes are set to
of a duplicate node address the same node address
or network configuration error. (MAC ID).

94hex response after The module is set at an Access the DeviceNet object
you send start service. incorrect node address to set the appropriate node
(MAC ID). address for the module
(see page 45).
The module is set at an Access the DeviceNet object
Error response received from
incorrect network baud rate. to set the appropriate baud
start service (06hex). Note
rate for the module
that a good response is 86hex
(see page 46).
while an error response
is 94hex. There is no response to The module is not properly Be sure the DeviceNet cable
the start service. connected to the network via connecting the module to the
the DeviceNet cable. network is properly installed,
including the 5position
connector at the module's
DeviceNet port.

Link object The module has not been Create screeners for each
Not receiving connected
configured for connected CAN ID from which you want
DeviceNet network messages
messages (no screeners set to receive messages
(this excludes any
up to receive connected (see page 48)
unconnected messages).
DeviceNet messages).

The number of There can only be a Delete unnecessary links.

Create link failed
links created maximum of 128 links.

17706.5.22
 Index

Numbers delete, service, 34

message, 37
1770KFD. See module
DeviceNet
message, 34
A object, 16
baud rate, A2
ACK, 22 definition for module, A1
ANSI x3.16, 22 MAC ID (node address), A2
set_attribute_single (baud rate), 46
ANSI x3.28, 14, 21
setattributesingle (node address),
autobaud, 31, 42, 43 45
start service, 47
stop service, 44
B protocol, 13, 14
baud rate, 42, 46 receiving connected messages, 37
configure, 35 sending connected messages, 36
specification Volume I & II, A1
baud rates, 12
DF1, 15
BCC, 23 about, 21
See also block check character character transmission, 22
block check character, 15, 22, 23 communication example, 41
calculating, 23 environment definition, 25
fullduplex message packet, 23
fullduplex protocol, 14, 21
C how the receiver operates, 28
CAN ID, 15, 32, 36, 37 how the transmitter operates, 26
link object, A6 message, format, 33
message transmission examples, 212
CCITT V.4, 22 module communication, 31
character, transmission, 22 object, 16
CMD, 15, 23 definition for module, A3
protocol, 13
communication response symbol, 26
DeviceNet, 35 timeout, 26
example (DF1 linklayer), 41
local, 32 DLE, 15, 22, 23
ENQ, 42
computer
See also host DST, 15, 23
mode of transmission, 22 DTE controlled answer, 12
connections, pointtopoint, 21 DTR, 32
control, symbols, 22
create, service, 34 E
message, 37
ENQ, 22
DLE ENQ, 42
D errors, general, B2
data ETX, 15, 22, 23
size, 22
symbols, 22
DCD, 32
I–2 Index

F message
create service, 37
FFFF (hex), 32 delete service, 37
full duplex DeviceNet, 34
DF1 protocol, 21 failing, 213
message packet, 23 format, 32, 33
fullduplex packet, 23
normal transmission, 212
G packet fields, 23
problems in receiving, 29
get_attribute_single
receiving connected messages, 37
DeviceNet object, A1
retransmission request, 214
service, 34
sending connected messages, 36
sending/receiving via UCMM, 36
H sink, 25
source, 25
hexadecimal service codes, 34 transmission examples, 212
host, communication with module, 22, transmitting, 26
32 type, 22
message transmission examples, 212 message format, module, 15
minor (revision), identity object, A5
I modem, 12
autoanswer, 12
identity, object DTE controlled answer, 12
definition for module, A4 initializing, 42
device type, A5
module
product code, A5
1770KFD protocol, 15
revision, A5
about, 11
serial number, A5
autobaud, 31, 42, 43
state, A5
basics, 11
status, A5
baud rate, 42, 46
vendor, A5
baud rates, 12
initializing your module, 42 communication over the DF1 link, 31
ISO 1177, 22 communication with host, 22
errors, general, B2
message, format, 15
L node address, 42, 45
physical connections, 11
link
pointtopoint, 11
communication example, 41
remote via modem, 12
linklayer protocol, 21
reset, 42
linklevel communication, 13
start service, 47
object, 16, 37
status indicator, 31
creating screeners, 48
state definitions, B1
definition for module, A6
status indicators, 12
deleting screeners, 49
stop service, 44
protocol, 22
supported objects, 16, A1
local communication, 32
module status indicator, 12
local objects, accessing, 33 state definitions, B1

M N
MAC ID (node address), A2 NAK, 22, 23
major (series), identity object, A5
 Index I–3

network status indicator, 12 RS232 serial cable, 11

state definitions, B1 RS232 status indicator, 12
node address, 45 state definitions, B1
configure, 35
set, 42
S
screeners
O
creating, 48
object deleting, 49
accessing local, 33 link object, A6
DeviceNet, 16 serial connection, 13
definition for module, A1
DF1, 16 services, 34
definition for module, A3 set_attribute_single
identity, A5 DeviceNet object, A1
definition for module, A4 service, 34
link, 16, 37 setattribute_single, 42
definition for module, A6 baud rate, 46
power management, 16
setattributesingle, node address, 45
definition for module, A7
RS232, 16 SRC, 15, 23
definition for module, A7 start, service, 34, 35, 42, 47
objects, module supported, 16, A1 status indicator, module, 31
status indicators, 12
state definitions, B1
P
stop, service, 34, 42, 44
parity, 22
stop bit, 22
PCCC, 15
protocol, 13, 14 STS, 15, 23

physical circuits, 25 STX, 15, 22, 23

physical connections, 11

pointtopoint connection, 11, 21 T
power management, object, 16 timeout, 26
definition for module, A7
TNSW, 15, 23
protocol layers, 13
transmitter, 25
how it operates, 26
logic flowchart, 28
R
structured English procedure, 27
receiver, 25 troubleshooting, B1
how it operates, 28
logic flowchart, 211 twoway simultaneous operation, 25
problems in receiving messages, 29
structured English procedure, 210
U
reset, 42
service, 34 unconnected message manager,
sending/receiving messages, 36
response symbol, 26
unconnected message manager (UCMM),
RS232 35
See also serial connection
heartbeat, 32
object, 16 V
definition for module, A7
reset, 42 validity check, 22
 AllenBradley
Publication Problem Report
If you find a problem with our documentation, please complete and return this form.

Pub. Name DeviceNet RS232 Interface Module Communication Protocol Reference Manual

Cat. No. 1770KFD Pub. No. 17706.5.22 Pub. Date October 1995 Part No. 95512207

Check Problem(s) Type: Describe Problem(s): Internal Use Only

Technical Accuracy text illustration

Completeness procedure/step illustration definition info in manual

What information is missing? example guideline feature (accessibility)
explanation other info not in
manual

Clarity
What is unclear?

Sequence
What is not in the right order?

Other Comments
Use back for more comments.

Your Name Location/Phone

Return to: Technical Communication, AllenBradley Co., 1 AllenBradley Drive, Mayfield Hts., OH 44124 Phone: (216)6463166
FAX: (216)6464320

Publication ICCG5.21August 1995 PN 95510782

 PLEASE FASTEN HERE (DO NOT STAPLE)

Other Comments

PLEASE REMOVE
PLEASE FOLD HERE

NO POSTAGE
NECESSARY
IF MAILED
IN THE
UNITED STATES

BUSINESS REPLY MAIL

FIRST-CLASS MAIL PERMIT NO. 18235 CLEVELAND OH
POSTAGE WILL BE PAID BY THE ADDRESSEE

Technical Communication
1 ALLEN BRADLEY DR
MAYFIELD HEIGHTS OH 44124-9705
 AllenBradley, 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
world's 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 • Russia-CIS • Saudi Arabia • Singapore • Slovakia • Slovenia • South Africa, Republic • Spain •
Sweden • Switzerland • Taiwan • Thailand • Turkey • United Arab Emirates • United Kingdom • United States • Uruguay • Venezuela • Yugoslavia

AllenBradley Headquarters, 1201 South Second Street, Milwaukee, WI 53204 USA, Tel: (1) 414 3822000 Fax: (1) 414 3824444

Publication 17706.5.22 October 1995 PN95512207

Copyright 1995 AllenBradley Company, Inc. Printed in USA