📄 main.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"><title>Copley Motion Library: Copley Motion Library</title><link href="doxygen.css" rel="stylesheet" type="text/css"></head><body><!-- Generated by Doxygen 1.4.4 --><div class="qindex"><a class="qindexHL" href="main.html">Main Page</a> | <a class="qindex" href="hierarchy.html">Class Hierarchy</a> | <a class="qindex" href="classes.html">Alphabetical List</a> | <a class="qindex" href="annotated.html">Class List</a> | <a class="qindex" href="dirs.html">Directories</a> | <a class="qindex" href="files.html">File List</a> | <a class="qindex" href="functions.html">Class Members</a> | <a class="qindex" href="globals.html">File Members</a></div><h1>Copley Motion Library </h1><p><h2><a class="anchor" name="intro">Introduction</a></h2>The Copley Motion Library is a collection of C++ objects which are intended to simplify the development of CANopen based products. These libraries allow low level access to the CAN and CANopen networks, while also providing high level methods for easy development of network based motion control applications.<h3><a class="anchor" name="platforms">Supported platforms</a></h3>The Copley Motion Library is designed to be highly platform independent. The only requirements of a platform are: <ul><li>C++ must be supported. The Copley Motion Library makes heavy use of the object oriented features of the C++ language. Porting it to standard C would require significant effort. </li><li>Multi-tasking. The library uses multiple threads of execution to communicate over the CANopen network. For this reason, some type of multi-tasking operating system is required. A real time operating system is highly desirable. </li><li>CAN hardware. Some sort of CAN hardware must be available.</li></ul>The majority of the library code should be easily portable across platforms, even to those systems that do not have a very complete C++ implementation. In particular, the standard C and C++ libraries have been avoided to the extent possible.<h3><a class="anchor" name="mt">Multi-tasking support</a></h3>The C++ language does not define any standard method for multi-tasking, so a generic multi-tasking layer has been defined for use by this library. Three classes have been defined in the header file <a class="el" href="CML__Threads_8h.html">CML_Threads.h</a> which define the multi-tasking interface. These classes are; <ul><li><a class="el" href="classThread.html">Thread</a>: An independent thread of execution. </li><li><a class="el" href="classMutex.html">Mutex</a>: A mechanism used to provide mutually exclusive access to a variable or system resource. </li><li><a class="el" href="classSemaphore.html">Semaphore</a>: A mechanism used to control access to a resource pool. This object allows threads to pend on it with timeouts.</li></ul>When porting the library to a new environment, these three objects will need to be implemented for that environment. The libraries currently support multi-tasking under posix compatible operating systems (most Unix varieties), and MS Windows.<h3><a class="anchor" name="canhardware">CAN hardware support</a></h3>The Copley Motion Libraries have been designed to use a generic interface to the low level CAN network hardware. This makes porting the libraries to new CAN hardware very straight forward. All CAN hardware access is routed through the <a class="el" href="classCanInterface.html">CanInterface</a> object defined in the header file <a class="el" href="CML__Can_8h.html">CML_Can.h</a>. This object defines generic methods to open, close, read from, and write to the CAN network. Adding support for new CAN interface hardware is as simple as implementing a new <a class="el" href="classCanInterface.html">CanInterface</a> object derived from this class.<h2><a class="anchor" name="CANopenBasics">CANopen basics</a></h2>CAN (Control Area Network) is a serial network originally developed for use in the automotive industry. The physical layer of CAN consists of a two wire differentially driven bus, typically terminated with 120 Ohm resisters on each end. The maximum bit rate supported by CAN is 1,000,000 bits/second for up to 25 meters. Lower bit rates may be used for longer network lengths.<p>Communication over the CAN bus takes the form of network packets. Each packet consists of an identifier, some control bits, and zero to eight bytes of data. Each packet is sent with CRC information which allows the CAN controllers on the network to identify and re-send incorrectly formatted packets.<p>The identifier sent with each CAN packet identifies the type of packet being sent, as well as the priority of the packet. If two or more devices on the network attempt to transmit packets at the same time, the one sending the higher priority packet will succeed. The device sending the lower priority packet will detect the network collision and automatically back off the network and re-try the transmission later. The fact that the higher priority packet is transmitted when a network collision occurs allows very high network bandwidth utilization. Other network technologies (such as Ethernet) would require both transmitting devices to abort their transmissions if a network collision was detected.<p>CANopen is a high level protocol used to communicate over a CAN network. It allows blocks of data larger then the eight byte CAN limit to be transmitted as a single entity. Additionally, CANopen defines a standard framework for device operation which simplifies communication between dissimilar devices.<p>In most cases a CANopen network consists of one master device, and multiple slave devices (also called network nodes). Each of the nodes on the network has a 7-bit node ID number associated with it in the range 1 to 127 (the node ID 0 is reserved, and should not be used). The Copley Motion Libraries are designed to run on the CANopen network master.<h3><a class="anchor" name="od">CANopen Object Dictionary</a></h3>One of the central concepts defined by the CANopen protocol is the notion of an object dictionary. This is essentially a collection of parameters on each device which define it's configuration and status. Most communication over the CANopen network consists of uploading data to, and downloading data from the object dictionaries of the various devices.<p>Each entry in the object dictionary is accessed using a 16-bit index value. Most entries in a device's object dictionary are simple atomic types (16-bit integers, 32-bit integers, strings, etc), however entries may be defined as complex types (records or arrays). In this case, the individual elements in the record or array are accessed using an additional 8-bit sub-index. It is not possible for these objects to be of complex types, so nesting of structures is not allowed.<h3><a class="anchor" name="sdo">SDO</a></h3>The majority of traffic over the CANopen network consists of the network master reading and writing to the object dictionaries of the slave devices (nodes) on the network. The primary mechanism through which this is accomplished is the Service Data Object (SDO).<p>Each node on the CANopen network is required to implement at least one SDO. The SDO is essentially a channel that can be opened between a network master and a slave for the purpose of reading from and writing to the slave's object dictionary.<p>SDO transfers are always initiated by the master, and always confirmed by the slave. The synchronous nature of the SDO makes error detection very straight forward. However, since every transfer using an SDO takes at least two CAN messages (one from the master to the slave, one from the slave to the master) they can be somewhat slow for the transfer of real time information.<p>For example, for the network master to update an object which holds an eight byte long value, six CAN messages will be required: <ul><li>1.The master sends a message to the slave indicating it's intentions to update the object. In this message it sends the object's index and sub-index values. It also passes the size (in bytes) of the data that will be transferred. </li><li>2.The slave responds to the master indicating that it is ready to receive the data. </li><li>3.The master sends the first 7 bytes of data. SDO transfers use one byte of the CAN message data for header information, so the largest amount of data that can be passed in any single message is 7 bytes. </li><li>4.The slave responds indicating that it received the data and is ready for more. </li><li>5.The master sends the remaining byte of data. </li><li>6.The slave responds indicating success.</li></ul><h3><a class="anchor" name="pdo">PDO</a></h3>A second method of accessing the data in the node's object dictionaries is defined by CANopen. This method is called the Process Data Object (PDO) and is primarily used to transfer frequently changing real-time data.<p>Unlike an SDO, a PDO can be initiated by either the network master, or the slave device. In fact, unlike SDO transfers, PDO transfers do not really follow a master - slave model. Any device on the network can initiate a PDO transfer, and a PDO message can be received and processed by multiple devices on the network.<p>Every PDO message consists of exactly one CAN message. Unlike SDO transfers, there is no confirmation with PDO transfers. This has the benefit of making much better use of the CAN network bandwidth, but since there is no response to a PDO, some other mechanism must be found to determine if the message was received successfully.<p>For example, updating the value of an 8-byte long variable in a device's object dictionary using a PDO can be accomplished in one CAN message, unlike the 6 messages that it required using SDO transfers. <ul><li>1.The master sends a CAN message containing the 8-bytes of data. No additional header information is passed in the message, and no response is sent.</li>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -