DeviceNet Example Code (Cat. No DNEXP) Release 1.4 User Manual

Transcription

1 User Manual

2 Because of the variety of uses for the products described in this publication, those responsible for the application and use of this control equipment must satisfy themselves that all necessary steps have been taken to assure that each application and use meets all performance and safety requirements, including any applicable laws, regulations, codes and standards. The illustrations, charts, sample programs and layout examples shown in this guide are intended solely for purposes of example. Since there are many variables and requirements associated with any particular installation, Allen-Bradley does not assume responsibility or liability (to include intellectual property liability) for actual use based upon the examples shown in this publication. Allen-Bradley publication SGI-1.1, Safety Guidelines for the Application, Installation, and Maintenance of Solid-State Control (available from your local Allen-Bradley office), describes some important differences between solid-state equipment and electromechanical devices that should be taken into consideration when applying products such as those described in this publication. Reproduction of the contents of this copyrighted publication, in whole or in part, without written permission of Allen-Bradley Company, Inc., is prohibited. Throughout this manual we use notes to make you aware of safety considerations:! ATTENTION: Identifies information about practices or circumstances that can lead to personal injury or death, property damage or economic loss. Attention statements help you to: identify a hazard avoid the hazard recognize the consequences Identifies information that is critical for successful application and understanding of the product. Motorola is a registered trademark of Motorola, Inc. Intel is a registered trademark of the Intel Corporation. Archimedes is a tradmark of Archimedes Software, Inc.

3 The following code enhancements are included in Release 1.4: COS/Cyclic support was added for the 68HC05x4 platform. Revised routines that read/write the CAN registers in order to reduce missed message packets. Non compliancies to the new ODVA Testware were remedied. Please refer to the enclosed file change14.txt for a detailed summary of changes. Important: All changes made to this document based on Release 1.3 are marked with a revision bar at the edge of the page.

4 Table of Contents

5 Table of Contents

6 Table of Contents

7 Read this manual before you implement the example code provided. This document provides an overview of the code included on the disk, and previews the comments contained within the code. Included are two types of example implementations: the Slave portion of the Predefined Master/Slave Connection Set, which is a subset of the DeviceNet protocol that uses a set of predefined connections the dynamic establishment of connections required for peer to peer communication, which implements the full Communication Model defined in The DeviceNet Specification. This document is divided into two sections to describe each type of code. To make a distinction between the two sets of code, this document uses the following terms to identify each set: Your disk contains three subdirectories: i

8 Under the subdirecties SLAVEx4 and SLAVE592, there are two additional subdirectories (SOURCE and INC). a:\ SLAVE592 SLAVEx4 SOURCE INC SOURCE INC DYNAMIC Allen-Bradley assumes no patent liability for the use of software described in this document. It is provided under the terms of the included warranty, and its use is your responsibility. Reproduction of the contents of this document, in whole, or in part, without written permission of the Allen-Bradley Company is prohibited. We assume that you: are familiar with the DeviceNet Specification know your application-specific product design know the C programming language are involved in the product development process In this manual, we use the following terms: ii

9 Before reading this manual, you should read the following: ODVA DeviceNet Communication Model and Protocol, Volume I Release 1.3 ODVA DeviceNet Device Profiles and Object Library, Volume II Release 1.2 iii

10 Notes iv

11 The example code you have purchased will assist you in developing firmware for your DeviceNet product. You are free to use any or all of it to develop the firmware in your product. Chapters 1 through 3 describe the example Predefined Master/Slave Connection Set device communication firmware and provide instructions for integrating this example firmware into your DeviceNet device. The example Slave code provided makes up the communication stack of a Slave device s firmware. Use it as an example of a fully functional implementation of the the Predefined Master/Slave Connection Set protocol defined in The DeviceNet Specification. This chapter contains descriptions of: features of the firmware scope of the firmware modifications you must make customizing the code the intended platform for this example code portability of the code This firmware includes the following features: code size as small as 2.8K bytes ROM and 60 bytes RAM 1 configurable via # define statements implements a Group 2 Only Server (Slave) 1This requirement is based upon the ISIL compilier with the 68HC05x4 microprocessor. Code size varies depending upon the compilier and options used. This is also dependent on the configuration options chosen. See Table 3.A. 1-1

12 This example implements the Slave portion of the Predefined Master/Slave Connection Set, which easily facilitates the movement of I/O and configuration data in a Master/Slave type architecture. The compact structure of the Master/Slave Connection Set allows you to base your products on low-end (low cost), CAN-based microcontrollers with limited ROM and RAM resources, and limited hardware screening capabilities. This example demonstrates that the DeviceNet protocol can be implemented on a low-end, 8-bit microprocessor, for simple devices. This code is intended to be used with only a few required alterations. To locate places requiring modifications, perform a text search for the locator USER_MODIFIED. Read the comments within the code to understand the scope of each modification. You can easily customize this code for your product by configuring a set of pre-compile switches (located in the header file DNET_CFG.H) and then re-compiling. See Chapter 3, Implementing the Example Slave Firmware. The Example Code found in the subdirectory SLAVEx4 is based on the Motorola 68HC05x4 eight-bit microprocessor. This platform has the following limitations: Both communications and application-specific protocol must fit within the 4K of onboard maskable or one-time programmable ROM. All dynamic memory (e.g., stack, global variables) must fit within the 176 bytes of onboard RAM. Only one mask-and-match screener is available for use. Screening that cannot be accommodated by the single screener must be performed in software. The 68HC05x4 is a register-lean processor (one 8-bit accumulator and one 8-bit index register) with a limited instruction set. 1-2

13 Because of limited RAM and ROM resources, extremely low-end devices will have the following functionality limits: No support for fragmentation in I/O Connections (Explicit Messaging Connections do support fragmentation). Connections that support fragmentation require larger data buffers (RAM). In order to accommodate the additional COS code, some changes are required in the 68HC05x4 code. Among these are the removal of the parameter object and configuration to remove fragmented explicit messaging. Also, the code is written assuming that when configured for a COS connection, no other IO connections are available. Note: The source file PARAMS.C is included and the object could easily be added by placing a call to the object in MSG_ROUT.C The Example Code found in the subdirectory SLAVE592 is based on the Philips 8xC592 eight bit microprocessor. This platform has fewer limitations than those listed above. This example library does not support COS/Cyclic connections or the Ack Handler Object. However, you can easily port this code from the SLAVEx4 code. Most of this firmware code is written in the C language, which makes it easily portable to any platform you choose. When using a high level language like C in an embedded environment you need to use a cross compiler. This code in the subdirectory SLAVEx4 was compiled with an ISIL Systems compiler, which is distributed by Motorola as shareware. You can use this cross compiler or another one. Important: The ISIL Systems cross compiler, is only partially ANSI C compliant. Partial ANSI C compliancy is the result of the limited registers and limited assembly instruction set of the 68HC05x4. Examples of this compiler s limitations include: Two dimensional arrays are not supported Indexing into arrays of structures longer than one byte is not supported Data types longer than one byte are not supported SLAVE592 code can be compiled by 2 compilers: Archimedes C 51 version 4.X or IAR Systems 8051 C version 5.X. Note: Newer versions of the Archimedes compiler are not directly compatible with the code. 1-3

14 Two make batchfiles are included: MAKEARCH.BAT and MAKE_IAR.BAT. Important: Allen-Bradley does not distribute the ISIL, Archimedes, or the IAR compilers. If you want to allow a COS connection to be created along with other IO connections and you are porting to platform with more memory, changes would be required. Most of the changes would be simple and related to the handling of various connection attributes. For example, when configured for COS, the code assumes that all references to connection instance 2 never refer to the POLL connection. The only substantial change would pertain to the allocation of the COS connection set (normally instances 2 and 4) after the allocation of a polled connection (instance 2). To assist you in making changes while porting this code to another platform, markers and comments have been placed in each file containing a portability issue. Perform a text search for the locator NON_ PORTABLE to identify files you will have to alter. Read the comments within the code for further explanation of each non-portable file. 1-4

15 This chapter describes the firmware components of a typical DeviceNet Slave device and defines the example code in terms of: File organization File description A typical DeviceNet Slave device s firmware contains two primary components: Application Code Communication Stack The example code provided makes up the Communication Stack. You are responsible for: providing the Application Code integrating the Application Code with the Communication Stack to form your product s firmware (see Chapter 3, Implementing the Example Slave Firmware, for instructions). 2-1

16 You can find the files for the Slave firmware code in the following two subdirectories under each of the subdirectory SLAVEx4 and SLAVE592: SOURCE INC The individual files have been organized to contain one object and all associated object services whenever possible. Object data is defined as either one or two structures in the header file OBJ_DEF.H. This section provides a brief description of each file included in this particular DeviceNet implementation. Refer to comments within the code for detailed file descriptions. Important: Only the source files and one of the include files are described here. The remaining include files should not be modified. The Example Code supports the following object classes: 2-2

17 Figure 2.1 represents the object model of the firmware. Use it for reference as you read the individual file descriptions. Both subdirectories contain the following files. In addition to these common files, each subdirectory contains other files as well. SLAVEx4 SLAVE592 This file contains two instances of the Assembly Class: an I/O assembly instance a configuration assembly instance 2-3

18 The I/O assembly instance groups I/O data as a block. The configuration assembly instance provides a means of uploading and downloading all configuration data in a bulk fashion. This file contains the CAN error handler routine. You may have to modify this file to customize it for a particular product. This file contains the CAN interrupt. It contains three modules responsible for: software identifier screening initial processing of received data processing of the CAN transmit interrupt If, after software screening, it is determined that the received message is destined for this node, then the message will be allowed to enter the node, and processing of the received message begins. Because there are only two ways to enter a device (either connected or unconnected), the CAN interrupt modules route the valid messages to either a Connection Instance or the Unconnected Request Port. Screening takes place for Group 2 messages only. Because this code implements a Group 2 Only device, only Group 2 messages will make it past the maskand-match hardware screener. This file contains the Connection Class and modules that manage the state of onboard connection instances. Object instance services supported by this object class are: Get_Attribute_Single Set_Attribute_Single Reset Both the SLAVE592 and SLAVEx4 code sets can be configured for an Explicit Messaging connection and any combination of Polled I/O and Bit Strobed I/O connections. The SLAVEx4 code can be also configured for an Explicit Messaging connection and a COS/Cyclic I/O connection (instances 2 and 4). Many of the connection instance attributes are known at pre-compile time and may be stored in ROM. See The DeviceNet Specification for Connection Class instance attributes and services, as well as for definitions of these services. 2-4

19 This file contains the link consumer modules, which consume both Explicit Messaging and I/O packets from the network. The consume side of the explicit messaging fragmentation state machine is implemented here. This header file contains all the pre-compile switches necessary to customize the Communication Stack to fit your product. These pre-compile switches allow you to configure your firmware in the following ways: Select support for the I/O connections Set the length of your device s configuration data Set the length of your device s I/O data Set attributes of the DeviceNet Object that are stored in ROM Set attributes of the Identity Object that are stored in ROM Set attributes of the Connection Objects that are stored in ROM Refer to the instructions for each of the pre-compile switches, which are located in the header file. Simply read the instructions and fill in the blanks. This file contains the DeviceNet Object, which is responsible for the configuration and status of physical attachments to DeviceNet. It also allocates and releases onboard connection instances. Services implemented by the DeviceNet Object are: Allocate_Master/Slave_Connection_Set Release_Master/Slave_Connection_Set Get_Attribute_Single Set_Attribute_Single The Allocate and Release services are the only ways to create and delete connection instances within the Predefined Master/Slave Connection Set protocol implementation. See The DeviceNet Specification for definitions of these services. This file contains the modules necessary to implement the Duplicate MAC ID Detection algorithm. 2-5

20 This file contains the Identity Object, which provides specific information about the identity of a DeviceNet node. The following services are supported by this object: Get_Attribute_Single Reset All of the Identity Object attributes (except the Serial Number attribute) are known at pre-compile time and may be loaded in ROM (see the file DNET_CFG.H). This file contains the routines necessary to initialize the microprocessor, the CAN bit-stream-processor, the connection instances, and the DeviceNet object. This file contains the main() function. This is the primary location for placing application-specific code. This file contains the Message Router Object. Its only responsibility is to route received Explicit Messages to appropriate target objects. This file contains the Parameter Object Class, which provides a standard means for device configuration. This object class provides only one example instance intended for reference only. Note: Although the PARAMS.C appears in SLAVEx4, the module currently does not appear in LGO.S in order to save space for Change of State code. If COS/Cyclic behavior is not desired, PARAMS.C can be reintroduced. This file contains routines that handle link production, which transmit both Explicit Messaging and I/O packets from the network. The produce side of explicit messaging fragmentation state machine is implemented here. This file contains only RAM variable declarations. This file contains the routine that builds the mask necessary to extract the node s strobe data bit from the bit strobe request message. If your device 2-6

21 will not support the Bit Strobed I/O connection instance, then you may remove this file. The file TIMERS.C contains the routines that handle the connection instance inactivity timers The module HWTIMERISR () is tied to the real time interrupt, which has been configured with an 8 ms clock tick. Porting this routine to another platform will be easier if you maintain the 8 ms clock tick. If you choose to alter the clock tick interval, then you must notify the routines that Get and Set the Expected_Packet_Rate attribute of the connection instances (see the file CNXN_CLS.C for further detail). This file contains the Unconnected Request Port. Request to allocate new connection instances can come through this port. This port may also be used to release connection instances. 2-7

22 In addition to the files contained in both subdirectories, subdirectory SLAVEx4 contains these files. This file contains the ack handler object along with other routines related to the COS/Cyclic I/O connection. This file contains the value of the Mask Option Register, which is a parameter associated with the 68HC05x4 microprocessor. Discard this file when porting to another platform. The file REGISTER.C contains all of the 68HC05x4 register declarations. Discard this file when porting to another platform. This file contains the reset() skeleton for the 68HC05x4 firmware implementation. Modify this file when porting to another platform. The stack variables file contains another set of RAM variable declarations. However, these declarations differ from those made in the RAMVARS.C file in that they have been declared at the bottom of the stack. Because the instruction set for the 68HC05x4 does not support stack manipulation, this firmware uses global variables instead of local variables (stack resident). These global variables reside at the bottom of the 64 byte stack. Using the global variables lets you directly address local variables, and ultimately, provides for shorter, faster code. Important: This scheme requires that the user keep track of the stack space required and leave that portion unoccupied. The VECTOR.S file contains the vector routines, which call the interrupt service routines. This file, along with VTABLE.S, pertains to the 68HC05x4 microprocessor. If you port this code to another processor, alter this file. If you are using a cross-compiler other than the ISIL cross-compiler, this file may not be necessary. 2-8

23 The VECTOR.S file is in this code because the ISIL cross-compiler cannot make the distinction between functions (rts at the end) and interrupt routines (rti at the end). If your cross-compiler can make the distinction, then you may discard this file. This file contains the vector table declaration, which also pertains to the 68HC05x4 microprocessor. Modify this file if you port this code to another processor. In addition to the files contained in both subdirectories, subdirectory SLAVE592 contains these files: This file contains the 8xC592 reset() skeleton. This file is the Archimedes version 4.x linker command file. This file is the IAR version 5.x linker command file. This is the Archimedes make file. This is the IAR make file. 2-9

24 Notes 2-10

25 After you have copied the disk provided with this manual to your working directory, implementing the example code is a four-part process: Code your application Customize the example code to fit your application Integrate your application-specific code with the example code Compile and link all the code This chapter provides specific instructions for completing each of these steps. We assume that your application code is: object-oriented a routine or sequence of routines that is looped through continuously In addition, we assume that your application code performs one or more of the following functions: reads input data writes output data performs operations on the I/O data Important: Place the loop of application code in the main() routine, which is located in the file MAIN.C. Communication with the application code will take place via the connection instances (see the file CNXN_CLS.C). 3-1

26 You can easily customize the example code for your product by configuring a set of pre-compile switches located in the header file DNET_CFG.H, and then re-compiling. You can customize such variables as: which I/O connections supported configuration data size I/O producer and consumer data sizes device identity data To customize, go to the DNET_CFG.H file and follow the instructions for each configurable parameter and pre-compile configurables. The extent to which you customize the code will influence the amount of ROM and RAM resources the code will consume. For example, the table below, which pertains to code found in the SLAVEx4 subdirectory provides an approximate figure of onboard resources that are consumed by typical code configurations: 3-2

27 Once you have designed your application code and customized (if you choose) the example code provided, you must integrate the two sets of code. As discussed in Chapter 2, Describing the Example Slave Firmware, the figure below represents the object model of a typical DeviceNet Slave device. Typical DeviceNet Slave device The shaded classes are already implemented in this code. The unshaded classes, labeled Application Classes, represent either open or vendor-specific classes that your device will require in addition to the ones present in the Example Code. Instances of these classes could represent I/O data or an application-specific function. As the figure illustrates, you can access objects within your device model by sending Explicit Messages across the Explicit Messaging Connection. The Message Router Object routes these Explicit Messages and distributes them to the target object specified in the message. Once a message reaches the specified object, the object s services will perform the function requested in the message. 3-3

28 Follow these steps to integrate your two sets of code: 1. Select the open or vendor-specific objects your device requires to implement its functionality. Important: A specification of open Application Objects is included in Volume II of The DeviceNet Specification. 2. Code your objects. 3. Make the objects you have coded accessible by adding function calls to them in the Message Router switch case structure. Add these new function calls in the routine msgrouter() located in the file MSG_ROUT.C. See this file for examples and additional comments. 4. Tie your I/O data to the connection instance data buffers. The I/O connection is the port through which a device s I/O data is read from and written to the DeviceNet bus: Output data to your application will be read from the I/O connection s consumed data buffer (c_data). Input data from your application will be written directly into the connection s produced data buffer (p_data). Each time the Bit Strobe or Poll command message is received, the data in the connection instance p_data buffer is placed onto the network. 3-4

29 For an example of this operation, refer to the module main() in the file MAIN.C. 5. Customize the configuration Assembly Object (instance #2) in the file ASSEMBLY.C. The configuration Assembly Object found in this file provides a compact means of configuring a device. Though you may always configure a device by accessing it s configuration data attributes individually, it is easier to download a chunk of data that represents the entire configuration. The configuration Assembly Object performs this function. See the file ASSEMBLY.C for examples and additional comments. 6. Place some or all configuration data in non-volatile memory. As the developer, you know where that memory is mapped, and will have to write the memory driver routine(s). Important: Place the following two DeviceNet Object attributes in non-volatile memory: MAC ID (if not dip-switch settable) Baud Rate (if not dip-switch settable) Use your discretion for any other open object attributes you may need to place in non-volatile memory. 3-5

30 Because writing data to non-volatile memory could take a significant amount of time (EEPROM writes), you may not want to do so within the CAN interrupt service routine. If you want I/O interrupts to continue during configuration downloads, then you may want to: copy the configuration data to a temporary buffer; and set a flag indicating that a non-volatile memory write should take place within main(). See the example within this routine. 7. Code the Network, Module, and I/O indicator drivers for your device. Place function calls to these drivers throughout the firmware. To locate specific places for these indicator drivers, perform a text search for USER_MODIFIED. 3-6

31 After you have integrated your application code with the example code, the final step in the implementation process is to compile and link your files. If you use a cross compiler other than ISIL, follow the instructions provided by the manufacturer. If you choose to use the ISIL compiler, follow the steps outlined here to begin compiling. Important: Allen-Bradley does not distribute the ISIL compiler. We mention it here and include instructions to help you get started quickly. 1. Edit the file STARTUP.S in the main ISIL directory (c:\oe\startup.s). The macrr statements should reference the processor you will be using. For example, if you are using the 68HC05x4, then the line starting with it% should read:. it% macrr ( pp ) >oe>hc5} Make similar changes to the remaining lines. 2. Go to the Source code directory and type: c:\oe\ie 2 5 to load the ISIL environment. As a shortcut, you can also go to the Source directory and type: isl [return] to access the batch file ISL.BAT, which will implement the line c:\oe\ie 2 5 for you. Important: The ISIL compiler requires 3 megabytes of extended memory. Important: If you have TSR (Terminate and Stay Resident) routines running, the ISIL compiler will not load! Remove the TSRs from your operating environment before loading the compiler. You may want to create a temporary set of CONFIG.SYS and AUTOEXEC.BAT files for use with the ISIL compiler. Important: The ISIL compiler requires that the following lines be included in CONFIG.SYS: FILES = 30 BUFFERS = Load the C compiler by typing: cc_comp [return] at the (instead of c:>) prompt. 4. Load the linker by typing: tt [return]. 3-7

32 5. Compile and link your code: At the prompt, type: ic lgo[return] to compile the linker command file LGO.S, which is supplied in the Source directory of the disk. Run the linker command file to compile the link code by typing: lgo [return]. You may exit the ISIL environment at any time by typing: exit[return]. To re-enter the ISIL environment, type: exit[return] again, and the prompt will reappear. Before shutting down your PC, remove the ISIL environment from memory by typing:.(period)[return]. 3-8

33 Chapters 1 through 3 described an example implementation of the predefined Slave connections. This chapter describes the second set of code, which provides example routines that implement the dynamic establishment of connections within the DeviceNet Communication Model, as well as the Duplicate MAC ID algorithm. These routines provide the means to implement peer to peer communication over the DeviceNet network. Use this example code as a resource library and a reference for writing your own code. It is intended to provide an easily understood, generic example upon which a product implementation can be based. This example code is not optimized for size and/or speed! You are free to use any or all of the code to develop your product. This chapter contains descriptions of: the scope of this code functional units within this example code CAN driver interface variable naming conventions 4-1

34 This example code is implemented using the C language. It is a collection of C source and include files that executes as a non-interruptible process which services events in a serial manner. Because it is intended for example only, there are no provisions in this example code for handling the disabling and enabling of task scheduling and/or product interrupts. As Figure 4.1 illustrates, the example code works in conjunction with your application-specific objects, a CAN chip driver, and your operating system. 4-2

35 Figure 4.2 illustrates the two functional units contained within this Dynamic Connection software example: Explicit Messaging Client Routines Explicit Messaging Client Routines generate and transmit Explicit Request Messages and process Explicit Response Messages. You can find these in the file CLTAPP.C. Explicit Messaging Server and I/O Routines process Explicit Request Messages, and implement the logic associated with I/O Connections. You can find these in the file IDN.C. The file IDN.C also contains the routines that implement the Duplicate MAC ID Detection Protocol and the associated Network 4-3

36 The Example Dynamic Connection Code invokes a user-provided routine (IDNUP_driverTransmit()), which transmits a message. When this routine returns, the software assumes that the message has been successfully transmitted. In a real implementation, the routine that delivers the transmit request to a CAN chip will return before the message is actually sent. Important: Because this software is intended for example only, it does not accommodate typical product issues such as transmit/receive-queue management or interrupt service routines. When we developed this example code, we used the following naming conventions for routines: All routines with the prefix IDNTK_ (e.g., IDNTK_cnxnManagerDelete()), are provided by the Example Dynamic Connection Code. Application-specific software invokes these routines to initiate or respond to a particular event. While this software presents a library of routines for you to reference as necessary, note that the prefix IDNTK_ highlights major functions or features. All routines with the prefix must be provided by the target system ( UP represents User Provided). These routines are invoked by the example code. All routines with the prefix OE, Operating Environment (e.g., must be provided by the target system. These routines interface to functions usually provided by an Operating System. All other routines are internal to the example code. Use Table 4.A as a quick reference to these naming conventions. 4-4

37 For variables, we used these naming conventions: All variables with the prefix g_ (e.g., g_msgrx) are global variables. All variables with the prefix p_ are pointers. The following abbreviation definitions will help you when you read the example code: 4-5

38 Notes 4-6

39 This chapter contains descriptions of application-specific, user provided routines that the Example Dynamic Connection Code invokes. The routines defined here are not part of the Example Dynamic Connection Code. If you include any portion of this example within your product, then you may have to implement these routines. The example code uses this routine to request that a timer be started. This routine contains the following parameters: For the unsigned long time input: If the underlying service cannot provide the exact resolution requested, then use the next highest time value. For example: If 7 milliseconds is requested and the timer resolution is 5 milliseconds per tick, then input 10 milliseconds. 5-1

40 The Example Dynamic Connection Code invokes this routine to cancel a timer started via the OE_TIMER_RQ() call. This routine contains the following parameter: Output: If the timer has already expired when this routine is invoked, the NULL value is returned. The Example Dynamic Connection Code invokes this routine The Example Dynamic Connection Code invokes this routine if it detects a module on the network with a duplicate MAC ID. This routine places the device in the Communication Faulted state. It has no parameters. The Example Dynamic Connection Code invokes this routine when it has successfully completed the Duplicate MAC ID Check portion of the Network Access State Machine, and has transitioned to the On-Line state. After making the transition to the On-Line state, the application is free to transmit/receive messages. This routine has no parameters. 5-2

41 The Example Dynamic Connection Code invokes this routine from the IDNTK_cnxnClassDelete() routine to inform the application that a Connection Object is going to be deleted. It contains the following parameter: The Example Dynamic Connection Code invokes this routine from the watchdogtimeout() routine when the Inactivity/Watchdog Timer associated with a Connection Instance expires. If an Explicit Messaging Connection has experienced a watchdog timeout, then the example code will automatically delete it after this routine returns. The Example Dynamic Connection Code invokes this function when the Transmit Trigger Timer associated with a Connection expires. Expiration of the timer is an indication that a transmission may need to occur across the connection so the server does not time out. You may choose how to process this event in your application. The Example Dynamic Connection Code invokes this routine from the uncreqtimeout() to inform the application that it has timed out while waiting for a response to a previously issued Unconnected Explicit Messaging Request. 5-3

42 For the input T_CLIENT_UNC_TRANS *p_uncreq: The application can examine the servicecode and transid members to obtain the Service Code and Transaction ID associated with the request that timed out. Important: Do not alter the contents of the structure this parameter references. The Example Dynamic Connection Code invokes this routine from cnxnbasedreqtimeout() to inform the application that it has timed out while waiting for a response to a previously issued Connection Based Explicit Messaging Request The Example Dynamic Connection Code invokes this routine to inform the application of the response to a Connection Based request. The Example Dynamic Connection Code invokes this routine to inform the application that it has received a Close Response. You can use servermacid as an index into the g_unctrans array to obtain more information concerning the Close Request. 5-4

43 The Example Dynamic Connection Code invokes this routine to inform the application that an Open Explicit Messaging Connection Response has been received. You can use servermacid as an index into the g_unctrans array to obtain more information about the Messaging Connection that was just opened. The Example Dynamic Connection Code invokes this routine to inform the application that an Unconnected Error Response has been received. The Example Dynamic Connection Code invokes this function to inform the application that a Connection Object is about to transition to the Established state. It calls this function when: the connection is initially established (either Messaging or I/O); and Make this call with the state member of the T_CNXN_INSTANCE structure set to its current value. When this function returns, the state member is set to CNXN_ESTABLISHED and all associated timers are activated. 5-5

44 This routine is invoked from cnxnclassreqhandler() when a device receives an Apply Attributes Request directed towards a Connection Object Instance. The Example Dynamic Connection Code invokes this function to deliver the Connection Instance to the application so the application can verify the attribute information. Important: The application must verify the validity of the following information for the Application Object specified by the Connection Object s produced and consumed connection path attributes: 1. The produced and/or consumed_connection_size attributes (prodsize, conssize members) 2. The produced and/or consumed_connection_size attributes (prodsize, conssize members) 3. The transportclass_trigger attribute (xportclasstrigger member) 4. The expected_packet_rate attribute (expectedpacketrate member) Be sure to make the distinction between this function (IDNUP_applyCnxnAttributes(p_cnxnInst)) and the function IDNUP_cnxnToEstablished(): Void IDNUP_applyCnxnAttributes(p_cnxnInst) has the following parameter: Outputs: You must set g_serverrsp.generrcode to 0 to indicate that the Connection Object Attributes are valid and the requested connection can be established. Set g_serverrsp.generrcode to something other than 0 (a General Error Code) that will be returned in an Error Response Message if an error is detected. 5-6

45 When an I/O message is consumed, the Example Dynamic Connection Code invokes this routine to deliver the message to the application. This routine rounds to a higher value a requested setting of the expected packet rate attribute of a Connection Object. It rounds up based on the available clock tick rate. For Example: If 5 milliseconds is requested and the product provides a 10 millisecond clock tick, then round the 5 up to 10. If the requested rate is a multiple of the available clock tick, then return the requested value. Important: If the value zero is requested, DO NOT round it up! Just return the zero. The Example Dynamic Connection Code invokes this routine to transmit a message. This routine interfaces to a CAN chip in a real product. 5-7

46 Notes 5-8

47

48 Index I 2

49