DNMaster V0202

DEVICENET® MASTER STACK
Integration Guide Version 2.02

Source Code Version 2.02
REAL TIME AUTOMATION

2825 N. MAYFAIR RD. SUITE 11
WAUWATOSA WI 53222
414-453-5100 (V) 414-453-5125 (F)
www.rtaautomation.com
DeviceNet is a trademark of Open Device Vendors Association (www.odva.org)

DEVICENET MASTER – 493DM Revision 2.02
Revision History
Date Name Revision Description
1/24/2000 JDW 0.10 Preliminary Revision
7/12/2000 JDW 1.00 Release Revision
9/14/2001 JDW 1.01 Document Recertification
3/03/2004 JDW 1.02 Added PCAN USB adapter for sample application.
2/18/2005 JDW 2.01 Added Pass through Explicit Messaging
Updated stack to match file format used with slave stack
9/08/2006 JDW 2.02 Added Network Who functionality
Added I/O Automap and Menu Driven Code to sample
Added option to add to poll list without knowing the size of
the Consume and Produce data.
Added functions to Enable/Disable UCMM Allocation
(Group2 Only)
Added function to read the scan list Identity information
and Connection sizes (used on Network Who)
Added Configuration Consistency Value read to Identity
object read code
©2006 Real Time Automation Page 2 of 24

Table of Contents
1. DeviceNet Overview .................................................................................. 4
1.1 “What is DeviceNet, and why do I need it in my product?” ........................................... 4
1.2 A Technical Summary of DeviceNet and CIP................................................................. 4
1.3 Messaging Types ............................................................................................................. 4
1.4 What is the CIP protocol?................................................................................................ 5
Required Objects ..................................................................................................................... 6
Application Objects ................................................................................................................. 6
Vendor Specific Objects.......................................................................................................... 6
2. DeviceNet Master Introduction .................................................................. 7
2.1 General Description......................................................................................................... 7
2.2 Special Features............................................................................................................... 7
2.3 Device Requirements....................................................................................................... 7
2.4 List of Files...................................................................................................................... 7
3. Customization ............................................................................................. 9
3.1 Common Structure Definitions........................................................................................ 9
3.2 Data Type Definitions ................................................................................................... 10
3.3 User Written Functions (called by RTA code) .............................................................. 10
3.4 RTA Written Functions (called by user code)............................................................... 13
4. Quick Start Instructions ............................................................................ 17
4.1 SAMPLE APPLICATION: ........................................................................................... 17
4.2 WRITE USER FUNCTIONS (if not using the sample application): ............................ 17
4.3 SAMPLE APPLICATION ............................................................................................ 18
4.4 SAMPLE MAIN CODE:............................................................................................... 21
5. Limited Warranty...................................................................................... 22
6. License Agreement ................................................................................... 23
6.1 Software Product License.............................................................................................. 23

1. DeviceNet Overview
1.1 “What is DeviceNet, and why do I need it in my product?”
DeviceNet is a low-level industrial application layer protocol for industrial automation

applications. Built on CAN (Controller Area Network), it uses all the traditional CAN
hardware to define an application layer protocol that structures the task of configuring,
accessing and controlling industrial automation devices.
What has caused this enthusiasm for DeviceNet?
It’s no secret that proprietary fiefdoms have dominated the automation business ever
since people started networking PLC’s. Hundreds of protocols have come and gone, and
the dominant ones (Remote I/O, DataHighway, Genius I/O, Modbus Plus and others)
have protected the turf of the PLC manufacturers.
This has resulted in considerable angst from two groups: 1) users, who are tired of being
locked into a whole series of decisions just because they bought a PLC; 2) smaller
vendors, who often make innovative, advanced products, but are locked out by
proprietary protocols.
DeviceNet is a very important technology, not only because it addresses most of the
technical concerns of Industrial Networking, but also because it is backed by Rockwell /
Allen-Bradley. This gives it an automatic advantage in the marketplace.
1.2 A Technical Summary of DeviceNet and CIP
The DeviceNet protocol is an application layer protocol based on the Control and
Information Protocol (CIP) layer also used in EtherNet/IP™ and ControlNet™. Devices
are represented on industrial networks using the identical object model structure as EIP
and ControlNet devices. The Object Model structure, the way a device presents itself to
the network, is in fact one of the real keys to the growing popularity of EtherNet/IP. For
the first time, there can be a common infrastructure between the Sensor, Control and
Information networks of an installation. With this common messaging structure a device
can just as easily request data from another EtherNet/IP device as a device on DeviceNet
or ControlNet.
1.3 Messaging Types
Polling: The DeviceNet scanner asks each device to send or receive an update of its
status. An outgoing message and incoming message are required for each node on the
network. Strobing: The scanner broadcasts a request to all devices for a status update.
Each device responds in turn, starting with node 1 and going up from there. Node
numbers can be assigned to prioritize messages. Polling and Strobing are the most
common messaging formats used.
Cyclic: Devices automatically send messages on scheduled intervals. This is sometimes

called a 'heartbeat' and is often used in tandem with Change of State messaging to assure
that the device is still functional.

Change of State: Devices send messages only when their states change. This occupies an
absolute minimum of time on the network, and a large network using Change of State can
often outperform a polling network operating at several times the speed. This is the most
time efficient but can be the least precise way to obtain information from devices because
throughput and response time becomes statistical instead of deterministic.
Explicit Messaging: The explicit-messaging feature is generally used for configuration

instead of process data. For example, complex devices like drives and controllers use
explicit messages to download parameters that change from time to time but do not
change as often as the process data itself.
Fragmented Messages: For data that requires more than DeviceNet's maximum 8 bytes
of data per node per scan, the data can be divided into any number of 8 bytes segments
and re-assembled at the other end. This requires multiple messages to send or receive one
complete message.
UCMM (Unconnected Message Manager): DeviceNet UCMM is essentially peer-to-

peer communication. Unlike the Master/Slave configuration, each UCMM capable device
can communicate with another directly, without having to go through a master first.
User and
Application Device Vendor
Required
Layer Specific Specific
Objects
Objects Objects
Transport Layer CIP Communications: Connected, Unconnected, I/O, Explicit
Encapsulation Layer
Data Link DeviceNet ControlNet UDP TCP
Layer
Communicatio
Link Layer Link Layer IP
ns (CAN) CSMA Link Layer
Communications
PHYSICAL CAN ControlNet ETHERNET

LAYER Physical Layer Physical Layer Physical Layer
Figure 1 - Data Layers for DeviceNet, ControlNet and EtherNet/IP in context
1.4 What is the CIP protocol?
The Communications and Information Protocol (CIP) is a communications protocol for

transferring automation data between devices. In the CIP Protocol, every network device
represents itself as a series of objects. Each object is simply a grouping of the related data

values in a device. For example, every CIP device is required to make an Identity Object
available to the network. The Identity Object contains related identity data values called
attributes. Attributes for the Identity Object include the vendor ID, device type, device
serial number and other identity data. CIP does not specify at all how this object data is
implemented, only what data values or attributes must be supported and that these
attributes must be available to other CIP devices. The Identity Object is an example of a
required object. There are three types of objects defined by the CIP protocol:
Required Objects
Objects required by the specification to be included in every CIP device. These objects
include the Identity Object, a Message Router object and a Network object.
Application Objects
Objects that define the data encapsulated by the device. These objects are specific to the
device type and function. For example, a Motor object on a Drive System has attributes
describing the frequency, current rating and motor size. An Analog Input object on an I/O
device has attributes that define the type, resolution and current value for the analog
input. Just as in DeviceNet, these application layer objects are predefined in a Device
Profile for a large number of common device types. A large number of profiles for many
device types have been defined. Supporting a device profile allows a user to easily
understand and switch between vendors with common device types.
A device vendor can also group Application Layer Objects into Assembly Objects. These
super objects contain attributes of one or more Application Layer Objects. Assembly
Objects form a convenient package for transporting data between devices. For example, a
vendor of a Temperature Controller with multiple temperature loops may define
assemblies for each of the temperature loops and an assembly with data from both
temperature loops. The user can than pick the assembly that is most suited for the
application and how often to access each assembly. For example, one temperature
assembly may be configured to report every time it changes state while a second may be
configured to report every one-second regardless of a change in state.
Vendor Specific Objects
Objects not found in the profile for a device class are termed Vendor Specific. A vendor
includes these objects as additional features of the device. CIP provides access to these
vendor extension objects in exactly the same method as application and required objects.
This data is strictly of the vendors choosing and is organized in whatever method makes
sense to the device vendor.

2. DeviceNet Master Introduction

2.1 General Description
The DeviceNet® Master Protocol Stack provides a small, microprocessor-oriented source
stack for building DeviceNet Master devices on an embedded device, such as a robotic
controller.
DeviceNet is a widely supported, CAN-based application layer protocol for industrial

automation applications. Built on the popular Controller Area Network (CAN) silicon,
DeviceNet defines an application layer protocol that structures the task of configuring,
accessing and controlling industrial automation devices.
This software must be customized for your application. Customization includes linking
the core DeviceNet software with your CAN interface, including your product data and
adding your application layer functionality.
2.2 Special Features

Support for Polled I/O messaging
Support for Explicit Messaging
Separate timers for each Slave device
Automatic reconnect if Slave device times out
Fully functionally sample application
Single thread application
2.3 Device Requirements

10-millisecond ticker Interrupt Service Routine (1-millisecond preferred)
2.4 List of Files
File Name Customization Description

Required?
DNETM_CIP.C NO Explicit Message Processing
DNETM_IOMSG.C NO I/O Message Processing
DNETM_RTASYS.C NO Most functions the user code calls
DNETM_TIMER.C NO Timer subsystem
DNETM_USERCAN.C YES User defined CAN functions
DNETM_USEROBJ.C YES User defined Object Model functions
DNETM_USERSYS.C YES User defined System functions
DNETM_USERTASK.C YES Sample main( ) code
RTA_UTILS.C NO RTA memory manipulation functions
DNETM_CIP.H NO CIP Definitions
DNETM_PROTO.H NO Function definitions

File Name Customization Description

Required?
DNETM_REVISION.H NO Stack revision history
DNETM_STRUCT.H NO System structure definitions
DNETM_SYSTEM.H NO General definitions for the DeviceNet
Master
DNETM_USERCAN.H YES User defined CAN definitions
DNETM_USEROBJ.H YES User defined Object Model definitions
DNETM_USERSYS.H YES User defined General definitions
DNETM_VAR.H NO File to easily define global variables
RTA_PROTO.H NO Function prototypes for RTA memory
manipulation functions

3. Customization
3.1 Common Structure Definitions
typedef struct
{
uint16 header; // 11-bit CAN header
uint8 dlc; // data length code (0-8)
uint8 buf[8]; // 8 byte data buffer
}DNETM_CANMSG_STRUCT; // CAN Message Structure
typedef struct
{
uint8 ServiceCode; // service code request
uint16 ClassID; // class id
uint16 InstID; // instance id
uint8 ServiceData[DNETM_MAX_EMBUF_SIZ]; // service code data
uint16 SizOfData; // service code data size
}DNETM_EMREQ_MSG_STRUCT;
typedef struct
{
uint8 ServiceCode; // response service code
uint8 *ServiceData; // response service code data
uint16 SizOfData; // response service code data size
}DNETM_EMRSP_MSG_STRUCT;
typedef struct
{
// ID OBJECT // ID Object Parameters
uint16 IDObjVendor; // Attribute 1
uint16 IDObjDevType; // Attribute 2
uint16 IDObjProdCode; // Attribute 3
uint16 IDObjMajRev; // Attribute 4
uint16 IDObjMinRev; // Attribute 4
uint32 IDObjSerialNum; // Attribute 6
uint8 IDObjProdName[DNETM_SHORTSTRING_SIZE]; // Attribute 7
uint16 IDObjCfgConsistVal; // Attribute 9
// CNXN OBJECT // CNXN Object Parameters

uint16 CNObjConsSize; // Consume Size (Master Produce)
uint16 CNObjProdSize; // Produce Size (Master Consume)
}DNETM_NETWHO_ENTRY_STRUCT;

3.2 Data Type Definitions
uint8 – unsigned 8 bit integer

int8 – signed 8 bit integer
3.3 User Written Functions (called by RTA code)
FILE NAME: dnetm_usercan.c

FUNCTION NAME: void dnetm_usercan_init (uint8 init_type);
PARAMETERS: init_type
- DNETMINIT_NORMAL (normal reset)
- DNETMINIT_OUTOFBOX (go to out of box settings)
RETURNS: N/A
DESCRIPTION: This function initializes user's CAN parameters.

FUNCTION NAME: void dnetm_usercan_process (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function handles CAN processing (non-interrupt based).

FUNCTION NAME: uint8 dnetm_usercan_CanTx (DNETM_CAN_MSG_STRUCT *
CanMsg);
PARAMETERS: CanMsg - pointer to CAN message to transmit
RETURNS: SUCCESS - the message was sent successfully
FAILURE - the message didn't send or we are the only
node on the network.
DESCRIPTION: This function tries to transmit the CAN message. FAILURE is
returned if the transmit fails. If we are the only node on the
network, automatically resend the message.

FUNCTION NAME: uint8 dnetm_usercan_BusPowerPresent (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function returns TRUE if bus power is present and FALSE if
bus power isn't present. This function always returns true if the
device is powered by the CAN bus.
FILE NAME: dnetm_userobj.c

FUNCTION NAME: void dnetm_userobj_init (uint8 init_type);

RETURNS: N/A
DESCRIPTION: This function initializes user object parameters.

FUNCTION NAME: void dnetm_userobj_process (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function handles processing user object variables.

FUNCTION NAME: uint32 dnetm_userobj_getSerialNumber (void);
PARAMETERS: N/A
RETURNS: a unique 32-bit number
DESCRIPTION: This function returns a unique 32-bit number for every product
that shares a vendor id.

FUNCTION NAME: uint8 dnetm_userobj_getMacId (void);
PARAMETERS: N/A
RETURNS: our MAC ID (0-63)
DESCRIPTION: This function returns the MAC ID of the master.

FUNCTION NAME: void dnetm_userobj_pollDataRcvd (uint8 node_id, uint16 length);
PARAMETERS: node_id – node id of slave
length – length of slave data
RETURNS: N/A
DESCRIPTION: This function is called when poll data is received.


FUNCTION NAME: void dnetm_userobj_process_em_passthrough (uint8 node_id,
DNETM_EMRSP_MSG_STRUCT * emrsp);
emrsp – pointer to explicit message response data
RETURNS: N/A
DESCRIPTION: This function is called when an explicit response is received for a
pass through message requested by the user.
If a timeout occurs, the following error code message is returned:

emrsp->ServiceCode = SC_ERROR_RESPONSE;
emrsp->SizOfData = 2;
emrsp->ServiceData[0] = ERR_CONNECTIONLOST;
emrsp->ServiceData[1] = ERR_NOADD_ERRCODE;
FILE NAME: dnetm_usersys.c

FUNCTION NAME: void dnetm_usersys_init (uint8 init_type);
RETURNS: N/A
DESCRIPTION: This function initializes user system parameters.

FUNCTION NAME: void dnetm_usersys_process (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function handles processing user system variables.

FUNCTION NAME: void dnetm_usersys_fatalError (char * function_name, int16
error_num);
PARAMETERS: function name – string of function that caused the error
error_num – error number
RETURNS: N/A
DESCRIPTION: This function turns all LED's RED and stops running. If you need
to still process your code, make sure you return from this state.


FUNCTION NAME: void dnetm_usersys_statusUpdate (uint8 node_id, int16
status_code);
status code (defined in dnetm_system.h)
RETURNS: N/A
DESCRIPTION: This function is called when the major status of the node changes.
This happens when the I/O connection times out, gets allocated or
if there is a problem with the allocation process.
3.4 RTA Written Functions (called by user code)
FILE NAME: dnetm_rtasys.c

FUNCTION NAME: void dnetm_rtasys_init (uint8 init_type);
RETURNS: N/A
DESCRIPTION: This function initializes all parameters.
WHEN TO CALL: Once at power up. This should be the first function called.

FUNCTION NAME: void dnetm_rtasys_process (uint32 ticks_passed_since_lastcall);
PARAMETERS: ticks_passed – number of ticks passed since the last time this
function was called.
RETURNS: N/A
DESCRIPTION: This function process the timers and user code
WHEN TO CALL: Once during every main loop.

FUNCTION NAME: void dnetm_rtasys_CanRx (DNETM_CAN_MSG_STRUCT *
canmsg);
PARAMETERS: canmsg – pointer to received CAN message
RETURNS: N/A
DESCRIPTION: This function process the received CAN message.
WHEN TO CALL: When ever an 11-bit standard CAN message is received.

FUNCTION NAME: void dnetm_rtasys_onBusOff (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function handles the BUS OFF condition.
WHEN TO CALL: When a BUS OFF occurs.


FUNCTION NAME: void dnetm_rtasys_setMode (uint8 mode);
PARAMETERS: mode (0 = IDLE, 1 = RUN)
RETURNS: N/A
DESCRIPTION: This function changes the mode of the master from IDLE to RUN
and back. IDLE mode doesn't send output data to the slave's, but
still returns input data from the slaves. RUN mode both sends
output data and returns input data from the slaves.
WHEN TO CALL: Call when the mode changes. If you are an embedded master, you
should set the mode to RUN after the scan list is built.

FUNCTION NAME: int16 dnetm_rtasys_getState (uint8 node_id);
RETURNS: current state, DNETM_SLVSTATE_NOTINUSE on errror
DESCRIPTION: This function returns the current state of the requested node.
WHEN TO CALL: Call periodically if the current state is needed. If only the
connection status is needed, this function doesn’t need to be
called.

FUNCTION NAME: int8 dnetm_rtasys_addNode (uint8 node_id, uint16 epr, uint16
consSize, uint8 *consPtr, uint16 prodSize, uint8 *prodPtr);
PARAMETERS: macid – slave’s MAC ID
consSize – slave’s consume size (in bytes)
consPtr – byte pointer to slave’s consume data
prodSize – slave’s produce size (in bytes)
prodPtr – byte pointer to slave’s produce data
RETURNS: DNETM_ERRCODE_SUCCESS (Success)
DNETM_ERRCODE_NODEIDUSED (Node ID is already used)
DNETM_ERRCODE_INVNODEID (Node ID is greater than 63)
DNETM_ERRCODE_INVCONSPTR (Cons Ptr is NULL, size > 0)
DNETM_ERRCODE_INVCONSSIZE (Cons Size is too large)
DNETM_ERRCODE_INVPRODPTR (Prod Ptr is NULL, size > 0)
DNETM_ERRCODE_INVPRODSIZE (Prod Size is too large)
DNETM_ERRCODE_MASTERNODEID (Node ID is the Master's)
DESCRIPTION: This function attempts to add a node to the poll list.
WHEN TO CALL: Call this function once all initialization is completed and the
master passes the Duplicate MAC ID check. Upon calling this
function, the master immediately attempts to allocate the slave
device.


FUNCTION NAME: int8 dnetm_rtasys_removeNode (uint8 node_id);
DESCRIPTION: This function removes the requested node from the polling list. If
the node is the master id, an error code is returned.
WHEN TO CALL: Call to remove a node from the scan list. With a fixed embedded
application, this function is never called.

FUNCTION NAME: void dnetm_rtasys_disableGroup2Only (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function enables UCMM devices. When enabled, all slaves
can be allocated, but the overall allocation process is slower.
WHEN TO CALL: Call once at power up if UCMM devices are supported.

FUNCTION NAME: void dnetm_rtasys_enableGroup2Only (void);
PARAMETERS: N/A
RETURNS: N/A
DESCRIPTION: This function enables Group2Only Master functionality. When
enabled, only Group2Only slaves can be allocated. The overall
allocation time is cut in half.
WHEN TO CALL: Call once at power up if only Group2Only devices are supported.

FUNCTION NAME: int8 dnetm_rtasys_networkWho (void (*callback) (void));
PARAMETERS: callback – pointer to void callback function with no parameters
DNETM_ERRCODE_DATAPTRNULL (callback pointer is NULL)
DNETM_ERRCODE_EMMODE (NetWho already in progress)
DESCRIPTION: This function starts the Network Who. When the Who is
complete, the scan list is empty and the device state is set to
IDLE. The user passes a callback funtion pointer. RTA calls the
function when the who is complete.
WHEN TO CALL: Call to scan the network for attached nodes. With a fixed
embedded application, this function is never called.


FUNCTION NAME: int16 dnetm_rtasys_get_netwho_entry (uint8 node_id,
DNETM_NETWHO_ENTRY_STRUCT *who);
DNETM_ERRCODE_DATAPTRNULL (who pointer is NULL)
DNETM_ERRCODE_NODENOTINUSE (Node ID isn’t in use)
DESCRIPTION: This function fills in the data to the passed pointer is the node
exists.
WHEN TO CALL: Call after Network Who is complete to identity which nodes are
on the network.
FILE NAME: dnetm_cip.c

FUNCTION NAME: int16 dnetm_cip_em_passthrough (uint8 node_id,
DNETM_EMREQ_MSG_STRUCT * emreq, uint16
timeout_inms);
emreq – pointer to explicit request
timeout – message response timeout in milliseconds
RETURNS: DNETM_ERRCODE_INVNODEID (Node ID is greater than 63)
DNETM_ERRCODE_DATAPTRNULL (emreq pointer is NULL)
DNETM_ERRCODE_EMOFFLINE (slave node isn’t connected)
DNETM_ERRCODE_EMINPROG (explicit request in progress)
DNETM_ERRCODE_SUCCESS (Success)
DESCRIPTION: This function sends the request to the passed node. Only one
message can be outstanding at any time.
WHEN TO CALL: Call this if an explicit message needs to be processed.

4. Quick Start Instructions

4.1 SAMPLE APPLICATION:
The sample application, written with Microsoft Visual C++ 6.0 uses a Phytec USB to CAN
adapter (http://www.phytec.com/can/hardware/pccaninterface/peakusb.htm). Modify the poll list
to match your application or use the Network Who functionality to dynamically build a poll list.
4.2 WRITE USER FUNCTIONS (if not using the sample application):
All functions described in section 3.3 “User Written Functions” need to be written.

4.3 SAMPLE APPLICATION
Figure 2 - Sample Application Help Menu
The sample application provides functionality to scan the network for attached device, connect to
the devices, display input bytes, modify output bytes and send explicit messages. Since the
application is designed with a simple user interface, the first attached node is often used to show
how functions work.
Case
Keyboard Sensitive? Description
Spacebar NO Clear the screen
C NO Clear the scan list
g YES Disable Group2 Only Master functionality. UCMM Allocations are tried first, then Group2.
(Default)
G YES Enable Group2 Only Master functionality. Only Group2 Only devices can communicate.
H or ? NO Print the Help Menu
l YES Disable printing all CAN traffic (Default)
L YES Enable printing all CAN traffic
0 YES Decrement value stored in byte 0 of the output table (used by first node with output data (consume
data)).
O YES Increment value stored in byte 0 of the output table (used by first node with output data (consume
data)).
P NO Print the current scan list
Q NO Quit the application. Nodes should be freed of their connections within 10 seconds of exiting the
application.
S NO Statically add the first node in the Network Who scan list to the DeviceNet Master scan list. This
shows how to add nodes without using the Network Who command.
W NO Start Network Who. All nodes on the network are allocation and queried for their Identity Object
parameters and Polled I/O Connection sizes.
X NO Send an explicit message to the Identity Object of the first node in the Network Who scan list.
This message reads the first 9 attributes of the Identity Object and displays the raw hexadecimal
results to the screen.

SAMPLE APPLICATION SCREEN SHOTS
Figure 3 - Starting the Network Who
Figure 4 - Network Who Results

Figure 5 - Polled Connection are Allocated (first 16 bytes shown)
Figure 6 - Send an Explicit Message
The DeviceNet Master is capable of sending Explicit Messages to all nodes. Only one message
can be outstanding at any one time. Explicit Messages cannot be sent until the I/O connection is
established since the DeviceNet Master is using the Explicit Message Connection to allocate and
validate the I/O connection.

4.4 SAMPLE MAIN CODE:
The purpose of including this snippet of code is to illustrate the simple nature of the main
DeviceNet Master processing. Only the sections in bold are required. You also need to write code
to build the scan list, process the I/O data and control the CAN functionality.
/* ====================================================================
Function: main
Parameters: N/A
Returns: N/A
This function drives the DeviceNet Master code.

======================================================================= */
void main (void)
{
uint8 i;
// clear out the I/O data tables

memset(input_data, 0x00, sizeof(input_data));
memset(last_input_data, 0xFF, sizeof(last_input_data));
memset(output_data, 0x00, sizeof(output_data));
// clear out the processing structure

memset(Slave, 0, sizeof(Slave));
memset(&node_1_struct, 0, sizeof(node_1_struct));
node_1_id = NODE_ID_NOT_USED;
// call RTA init code (DNETMINIT_NORMAL or DNETMINIT_OUTOFBOX)

proc_status_flag = 0;
dnetm_rtasys_init(DNETMINIT_NORMAL);
// print help menu

local_print_help();
// get a base time

local_get_passed_ticks(); /* get a base time */
// main processing
for(;;)
{
// call the RTA processing
dnetm_rtasys_process(local_get_passed_ticks());
// monitor state transitions for the used nodes

for(i=0; i<DNETM_MAX_NUM_NODES; i++)
{
if(Slave[i].state != dnetm_rtasys_getState(i))
{
Slave[i].state = dnetm_rtasys_getState(i);
local_print_state (i, Slave[i].state); // print the state for the user
}
}
// process the user input

if(_kbhit())
{
local_process_menu(_getch());
} // END -> look for keyboard hit
} // END -> while(1)
} // END -> main()

5. Limited Warranty
RTA Warrants that this software is free from defects and will properly function as the software core of an DeviceNet
Master application.
EXCEPT AS SPECIFICALLY SET FORTH ABOVE, RTA DISCLAIMS ALL OTHER WARRANTIES, BOTH
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR APPLICATION. THIS LIMITED WARRANTY
GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY ALSO HAVE OTHER RIGHTS, WHICH VARY FROM
STATE TO STATE.
The examples and diagrams in this manual are included solely for illustrative purposes. Because of the many variables
and requirements associated with any particular application, Real Time Automation cannot assume responsibility or
liability for actual use based on the examples and diagrams. Except as specifically set forth above, RTA and it's
distributors and dealers will in no event be liable for any damages whatsoever, either direct or indirect, including but
not limited to loss of business profits, income or use of data. Some states do not allow exclusion or limitation of
incidental or consequential damages, therefore, the limitations set forth in this agreement may not apply to you.
No patent liability is assumed by Real Time Automation with respect to use of information, circuits, equipment, or
software described in this manual.
Government End-Users
If this software is acquired by or on behalf of a unit or agency of the United States Government, this provision applies:
The software (a) was developed at private expense, is existing computer software, and was not developed with
government funds; (b) is a trade secret of RTA for all purposes of the Freedom of Information Act; (c) is "restricted
computer software" submitted with restricted rights in accordance with subparagraphs (a) through (d) of the
Commercial "Computer Software-Restricted Rights" clause at 52.227-19 and its successors; (d) in all respects is
proprietary data belonging solely to RTA; (e) is unpublished and all rights are reserved under copyright laws of the
United States. For units of the Department of Defense (DoD), this software is licensed only with "Restricted Rights":
as that term is defined in the DoD Supplement of the Federal Acquisition Regulation 52.227-7013 (c) (1) (ii), rights in
Technical Data and Computer Software and its successors, and: Use, duplication, or disclosures is subject to
restrictions as set forth in subdivision (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at
52.227-7013. RTA, 2825 N. Mayfair Rd., Suite 11, Wauwatosa, WI 53222. If this software was acquired under GSA
schedule, the U.S. Government has agreed to refrain from changing or removing any insignia or lettering from the
Software or documentation that is provided or from producing copies of the manual or media.

6. License Agreement
THIS REAL TIME AUTOMATION LICENSE AGREEMENT (“LICENSE AGREEMENT”) IS A LEGAL
AGREEMENT BETWEEN YOU AND REAL TIME AUTOMATION, FOR THE SOFTWARE PRODUCT. BY
USING THE SOFTWARE PRODUCT, YOU ARE AGREEING UNCONDITIONALLY TO BE BOUND BY THE
TERMS OF THIS LICENSE AGREEMENT, EVEN IF THIS LICENSE AGREEMENT IS DEEMED A
MOFIDICATION OF ANY PREVIOUS ARRANGEMENT OR CONTRACT. IF YOU DO NOT AGREE TO THE
TERMS OF THIS LICENSE AGREEMENT, DO NOT USE THE SOFTWARE PRODUCT. INSTEAD, YOU MAY
RETURN THE SOFTWARE PRODUCT TO THE PLACE YOU OBTAINED IT FOR A FULL REFUND (IF
APPLICABLE).
6.1 Software Product License

The Software Product is protected by copyright laws and international copyright treaties, as well as other intellectual
property laws and treaties. The Software Product is licensed, not sold.
For purpose of this License Agreement, “Software Product” refers to the computer software and associated media,
printed materials, and “online” or electronic documentation, including without limitation any and all executable files,
add-ons, stencils, templates, symbols, filters, tutorials, help files and other files, that accompany the Real Time
Automation product identified above or in the accompanying documentation; “Use” means storing, loading (whether
into temporary memory (i.e., RAM) or into permanent memory (e.g., hard disk, CD-ROM or other storage device)),
installing, executing or displaying the Software Product; and “You” means the company, entity or individual whose
funds are used to pay the license fee or who has otherwise acquired the Software Product.
1. Grant of License
Software Product. Real Time Automation grants You the non-exclusive, non-sublicensable, limited license to the
Software Product, subject to the terms and conditions of this License Agreement.
2. Ownership
Title, ownership rights and intellectual property rights in and to the Software Product shall remain in Real Time
Automation and its suppliers and are protected by US and international copyright laws and international copyright
treaties, as well as other intellectual property laws and treaties. The Software Product is licensed, not sold. There is no
transfer to You of any title or ownership of the Software Product and the license granted under this License Agreement
should not be construed as a sale of any right in the Software Product. All rights not specifically granted under this
License Agreement are reserved by Real Time Automation.
3. Description of Other Rights and Limitations

Transfer of Software Product. You may transfer all Your rights under this License Agreement on a permanent basis
only, provided You retain no copies, You transfer the License Agreement, the corresponding serial number (if
applicable) and all the Software Product (including without limitation all component parts, media and printed materials,
and any upgrades) and the recipient agrees to all the terms and conditions of this License Agreement. If the Software
Product is an upgrade product, any transfer must include the latest release, all prior versions and any prior products
used to obtain the Software Product.
Termination. This License Agreement is in effect until terminated. You may terminate it at any time by destroying the
Software Product and all copies You have made. Unauthorized copying or duplication of the Software Product will
result in automatic termination of this License Agreement. Without prejudice to any other rights, Real Time
Automation may terminate this License Agreement if You fail to comply with any term or condition of this License
Agreement. Upon termination of this License Agreement, You agree to destroy the Software Product an all copies You
have made.
Not For Resale (“NFR”) Software Product. If the Software Product is identified as “Not For Resale” or “NFR”, then,
notwithstanding any other terms and conditions of this License Agreement, You may not, for value or other
consideration, distribute, resell, dispose of, or transfer the Software Product.
Support Services. Real Time Automation may provide You with customer and technical support services related to the
Software Product (“Support Services”). Use of Support Services is governed by the Real Time Automation policies and
programs described in the user manual, in “online” or electronic documentation, and/or in other Real Time Automation
provided materials. Any supplemental software code provided to You as part of the Support Services shall be

considered part of the Software Product and subject to the term and conditions of this License Agreement. With
respect to any technical information You provide to Real Time Automation as part of the Support Services, Real Time
Automation may use such information for its business purposes, including product support and development. Real
Time Automation will not utilize such technical information in a manner that personally identifies You.
4. Report and Audit Rights

You shall institute reasonable measures to ensure compliance with the terms and conditions of this License Agreement.
Upon Real Time Automation’s reasonable request, You agree to provide reports relating to Your Use of the Software
Product as necessary to demonstrate Your compliance with the terms and conditions of this License Agreement. You
further agree that Real Time Automation has the right, upon reasonable prior notice, to audit Your records and inspect
Your facilities to verify Your compliance with the terms and conditions of this License Agreement.
5. US Government Restricted Rights

The Software Product and documentation are provided with RESTRICTED RIGHTS. Use, duplication or disclosure by
the Government is subject to restrictions as set forth in the subparagraph (c) (1) (ii) of The Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of the Commercial Computer
Software-Restricted Rights at 48 CFR 52.227-19, as applicable. The contractor/manufacturer is Real Time
Automation, 2825 N Mayfair Rd., Suite 11, Wauwatosa, WI 53222, USA.
6. Export Restrictions
You may not export or reexport the Software Product or any underlying information or technology except in full
compliance with all United States and other applicable laws and regulations. In particular, but without limitation, none
of the Software Product or underlying information or technology may be exported or reexported (a) into (or to a
national or resident of) Cuba, Haiti, Iran, Iraq, Libya, Serbia, Montenegro, North Korea, Sudan or Syria or (b) to
anyone on the US Treasury Department’s list of Specially Designated Nationals or the US Commerce Department’s
Table of Deny Orders, as such countries, lists and orders may be amended or modified from time to time. By Using the
Software Product, You are specifically agreeing to the foregoing and You are representing and warranting that You are
not located in, under the control of, or a national or resident of any such country or on any such list.
7. Entire Agreement; Governing Law

This License Agreement constitutes the entire agreement between Real Time Automation and You with regard t the
subject matter hereof and supersedes any and all prior agreements, understandings and representations, whether written
or oral, concerning the subject matter of this License Agreement. This License Agreement shall not be modify except
by a written agreement executed by a duly authorized representative of each of Real Time Automation and You.
Nothing in this License Agreement is intended to exclude, modify or restrict the operation of any applicable statute or
other law, the provisions of which cannot lawfully be excluded, modified or restricted. If any court of competent
jurisdiction determines that a provision of this License Agreement is illegal, invalid or unenforceable in an jurisdiction,
then such provision shall be deemed modified to the minimum extent necessary to make it comply with the applicable
statute or law of such jurisdiction, and the remaining provisions of this License Agreement shall continue in full force
and effect. Any such modification shall not effect any provisions of this License Agreement in any other jurisdiction
where this License Agreement governs the Use of the Software Product.
If You acquired the Software Product in Canada, You agree to the following: Each of Real Time Automation and You
hereby confirm, desire and agree that this License Agreement has been and shall be written solely in the English
Language.
IF YOU ACQUIRED THE SOFWARE PRODUCT IN THE UNITED STATES, THIS LICENSE AGREEMENT IS
GOVERNED BY THE LAWS OF THE STATE OF WISCONSIN, USA, EXCEPT FOR THAT BODY OF LAW
DEALING WITH CONFLICTS OF LAW, WITHOUT REFERNCE TO THE 1980 UNITED NATIONS
CONVENTION ON THE INTERMATIONAL SALE OF GOODS.
IF YOU ACQUIRED THE SOFTWARE PRODUCT OUTSIDE THE UNITED STATES, THIS LICENSE
AGREEMENT IS GOVERNED BY THE LAWS OF THE REPUBLIC OF IRELAND.

DNMaster V0202

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DNMaster V0202

Transféré par

Droits d'auteur :

Formats disponibles

DEVICENET® MASTER STACK

Integration Guide Version 2.02

REAL TIME AUTOMATION

DeviceNet is a trademark of Open Device Vendors Association (www.odva.org)

©2006 Real Time Automation Page 2 of 24

©2006 Real Time Automation Page 3 of 24

DeviceNet is a low-level industrial application layer protocol for industrial automation

What has caused this enthusiasm for DeviceNet?

1.2 A Technical Summary of DeviceNet and CIP

1.3 Messaging Types

Cyclic: Devices automatically send messages on scheduled intervals. This is sometimes

©2006 Real Time Automation Page 4 of 24

Explicit Messaging: The explicit-messaging feature is generally used for configuration

UCMM (Unconnected Message Manager): DeviceNet UCMM is essentially peer-to-

Transport Layer CIP Communications: Connected, Unconnected, I/O, Explicit

PHYSICAL CAN ControlNet ETHERNET

Figure 1 - Data Layers for DeviceNet, ControlNet and EtherNet/IP in context

1.4 What is the CIP protocol?

The Communications and Information Protocol (CIP) is a communications protocol for

©2006 Real Time Automation Page 5 of 24

Vendor Specific Objects

©2006 Real Time Automation Page 6 of 24

2. DeviceNet Master Introduction

DeviceNet is a widely supported, CAN-based application layer protocol for industrial

2.2 Special Features

2.3 Device Requirements

2.4 List of Files

File Name Customization Description

©2006 Real Time Automation Page 7 of 24

File Name Customization Description

©2006 Real Time Automation Page 8 of 24

// CNXN OBJECT // CNXN Object Parameters

©2006 Real Time Automation Page 9 of 24

3.2 Data Type Definitions

uint8 – unsigned 8 bit integer

3.3 User Written Functions (called by RTA code)

FILE NAME: dnetm_usercan.c

FILE NAME: dnetm_usercan.c

FILE NAME: dnetm_usercan.c

FILE NAME: dnetm_usercan.c

FILE NAME: dnetm_userobj.c

©2006 Real Time Automation Page 10 of 24

FUNCTION NAME: void dnetm_userobj_init (uint8 init_type);

FILE NAME: dnetm_userobj.c

FILE NAME: dnetm_userobj.c

FILE NAME: dnetm_userobj.c

FILE NAME: dnetm_userobj.c

©2006 Real Time Automation Page 11 of 24

FILE NAME: dnetm_userobj.c

If a timeout occurs, the following error code message is returned:

FILE NAME: dnetm_usersys.c

FILE NAME: dnetm_usersys.c

FILE NAME: dnetm_usersys.c

©2006 Real Time Automation Page 12 of 24

FILE NAME: dnetm_usersys.c

3.4 RTA Written Functions (called by user code)

FILE NAME: dnetm_rtasys.c

FILE NAME: dnetm_rtasys.c

FILE NAME: dnetm_rtasys.c

FILE NAME: dnetm_rtasys.c

©2006 Real Time Automation Page 13 of 24

FILE NAME: dnetm_rtasys.c