canopen协议栈源代码canopen开发

Software PACkage for the development of CANopen slave or simple CANopen master devices

• Comprehensive range of functions based on the CANopen® specification CiA® 301
• Support of status displays according to CiA 303-3
• Support for Layer Setting Services according to CiA 305
• Enables quick and easy development of CANopen devices (slave or master)
• Modular software structure with comprehensive configuration and scaling possibilities
• High efficiency with minimum resource requirements
• Clearly structured, simple programming interface for connection of the application program
• Easy portability to alternative micro controllers
• Multi-channel support

Overview of functions

• Scalability and hardware-specific adaptation: To insure a high degree of scalability and adaptability, the software package is configured via central files. One configuration file allows to optimally adapt the CANopen functionality provided by the protocol stack to the given application, thus using the available resources more effectively. This enables extreme resource-saving implementations. The core functionality of the CANopen software is implemented independent of the architecture of the individual CAN controller. The CAN driver itself is fully encapsulated in a separate software module. Adaptation to the micro controller type used (e.g. interrupts, timer) is performed centrally in a separate header file.
   
• Multi-channel support: Upon request, the IXXAT CANopen Protocol Software is available as a multi-channel version.
  This version allows the user to implement multiple, independent CANopen devices within one field device. NMT master or slave functionality can be configured independently on each of the channels with fully independent object dictionaries. It also supports the parallel operation of different CAN controllers on each of the channels.
• Object dictionary and programming interface: The object dictionary represents the interface between the application and the communication interface. Each object dictionary entry can be directly allocated a reference to a variable with application data. PDOs and SDOs directly access these application variables. Therefore, no changes to an existing application are required in order to integrate a CANopen protocol stack. User-specific call-back functions can be connected to each application object and enable event-controlled signaling to the application when these objects are accessed. This mechanism allows direct, application-specific reaction to changes in the application data triggered on the bus-side. In addition, the possibility of saving and restoring configured data is also supported.
   
• Process-(PDO) and service-data-objects(SDO): The CANopen Protocol Software supports asynchronous (with or without event timer), synchronous (cyclic and acyclic) and on request (RTR) PDO transfer types. PDO-mapping may be implemented statically or dynamically, depending on available resources and the required reaction times. In addition, the protocol software supports multiplex PDOs including scanner and dispatcher lists. Dummy mapping as well as variable inhibit times are also possible. Objects can be mapped into several PDOs simultaneously. With SDOs, the transfer types expedited, non-expedited (segmented) and block transfer are supported. The SDO response can be delayed at application level for both read and write access. The application can check the data written by SDOs for consistency before the target variables are overwritten. The SDO transfer can be aborted if necessary.
   
• Network management: The CANopen software supports the boot-up defined in CiA 301 with all network services including node guarding with or without life guarding (master monitoring), and, the heartbeat mechanism with producer monitoring.
   
• Identifier allocation: By default, identifiers are allocated according to the predefined I/O connection set, but, they can also be assigned by altering the relevant object dictionary entries.
   
• Master functionality: Smaller CANopen systems frequently require only a simple master device to start the system, instead of a full CANopen manager. Therefore this CANopen software package enables the implementation of such a simple CANopen master with its own object dictionary. A CANopen device implemented on this basis can work in a system either as a slave or as a master and can be configured via the object dictionary with the aid of configuration tools. 
  The software provides all required services that enable the user to implement an optimized network management control functionality.
  The software package "CANopen Manager Software" is the appropriate basis for the implementation of full or more complex CANopen manager devices, and, for the development of programmable devices and controls (PLC).
   
• Optional functionality: To supplement the CANopen standard software, the following optional functions are available on request:
  - Flying master, startup-capable device or NMT-master-
  capable device according to CiA 302 
  - SDO manager (SDM), SDO requesting device (SRD)  
  according to CiA 302