main.html

美国COPLEY驱动器,程序开发工具之一.

</ul>
Of course, since all 8 bytes of the CAN message data were used to hold the object's value, there is no place the transmit the index / sub-index of the object being updated. This information must be implied based on the CAN message ID associated with the PDO. To create this association, a PDO must be mapped to one or more objects in a device's object dictionary before it can be used. This is accomplished by using SDO transfers, and effectively tells the device which object(s) a particular PDO transfer will access.<p>
The result is that sending a PDO like in the above example requires a bit of setup using SDO transfers. It's therefore not useful to use a PDO transfer to update an object's value just once, since this could be more efficiently done using a single SDO transfer. However, if a particular object needs to be updated repeatedly, then the overhead of mapping a PDO to it makes more sense.<p>
Aside from efficiency issues, PDO transfers have some other useful features. SDO transfers are inherently one master to one slave. PDO transfers can be used to broadcast a message to multiple other devices on the network. This is useful for synchronizing the start of a multi-axis move, for example.<p>
Additionally, a slave device can be configured to transmit the value of one (or more) of the objects in it's object dictionary either at a set frequency, or when some internal event occurs. This would also be accomplished using PDO transfers.<h3><a class="anchor" name="nmt">
Network management</a></h3>
Most communication over the CANopen network consists of reading and writing values to a device's object dictionary using either SDO or PDO transfers. There are however several other message types which are required by the CANopen protocol.<p>
Network management messages are used to control the state of the devices on the CANopen network. Every CANopen device implements a simple state machine which is controlled through the use of these messages. The following states are defined: <ul>
<li>Pre-operational: Every node enters this state after power-up or reset. In this state, the device is not functional, but will communicate over the CANopen network. PDO transfers are not allowed in pre-operational state, but SDO transfers may be used. </li>
<li>Operational: This is the normal operating state for all devices. SDO and PDO transfers are both allowed. </li>
<li>Stopped: No communication is allowed in this state except for network management messages. Neither SDO nor PDO transfers may be used.</li>
</ul>
One use of network management messages is to control these state changes on the network devices. The following network management messages are sent by the network manager to control these state changes. Each of these messages can be either sent to a single node (by node ID), or broadcast to all the nodes on the network. <ul>
<li>Reset. This message causes the receiving node(s) to perform a soft reset and come up in pre-operation state. </li>
<li>Reset communications. Causes the receiving node(s) to reset their CANopen network to it's power-on state, and enter pre-operational state. This is not a full device reset, just a reset of the CANopen interface. </li>
<li>Pre-operational. This message causes the receiving node(s) to enter pre-operational state. No reset is performed. </li>
<li>Start. Causes the node(s) to enter operational state. </li>
<li>Stop. Causes the node(s) to enter stopped state.</li>
</ul>
In addition to controlling the device's state machines, network management messages can be used to monitor the operation of the nodes on the CANopen network. There are two protocols to perform this task; heartbeat and node guarding.<p>
The heartbeat protocol is very simple, the network master configures the node to transmit a heartbeat message at some interval. The heartbeat message is then sent by the node at the specified frequency. The only information passed in the heartbeat message is the current state of the node (i.e. pre-operational, operational or stopped). The network manager can monitor these messages, and if anything happens to the node (or the network connection to the node) it can detect this by the lack of heartbeat messages.<p>
Node guarding is similar. The network manager configures the node to expect node guarding messages at some interval. The network manager then sends a message to the configured node at that frequency, and the node responds with a node guarding message. This allows both the network manager and slave device to identify a network failure if the guarding messages stop.<h3><a class="anchor" name="sync">
SYNC messages</a></h3>
Another type of message defined by the CANopen protocol is the SYNC message. This is a message that one device is configured to transmit at some interval, and that all other devices on the network receive. It can be used for device synchronization, and PDO transfers can be configured to be sent in response to the SYNC event.<p>
Every CANopen network should have one (and only one) device which is configured to produce SYNC messages (the SYNC producer). Other devices on the network which receive the SYNC messages are SYNC consumers.<p>
Copley Controls amplifiers are able to be configured as both SYNC producers and SYNC consumers. The default configuration for every amplifier after reset is as a SYNC consumer. The Copley Motion Library <a class="el" href="classAmp.html">Amp</a> class constructor will configure one of the amplifiers as a SYNC producer by default.<h3><a class="anchor" name="emcy">
Emergency messages</a></h3>
Emergency messages are sent by CANopen devices when some error condition is detected. They contain information about the type of error condition as well as manufacturer specific information not defined by the CANopen spec.<h2><a class="anchor" name="overview">
Architectural overview</a></h2>
The Copley Motion Libraries are made up of a large number of classes, but several are of primary importance and will be used for every program. This section gives a brief overview of the most important of these classes. Detailed documentation of each of the provided classes is provided later in the manual.<h3><a class="anchor" name="can">
CanInterface</a></h3>
This class has already been mentioned above. It is one of the few classes that is highly platform dependent. The <a class="el" href="classCanInterface.html">CanInterface</a> class is used to abstract the CAN network interface hardware available on the system.<p>
Typically, one of the first objects created in a program using the Copley Motion Libraries is a <a class="el" href="classCanInterface.html">CanInterface</a> object. This will in turn be passed to the <a class="el" href="classCanOpen.html">CanOpen</a> object.<h3><a class="anchor" name="co">
CanOpen class</a></h3>
The <a class="el" href="classCanOpen.html">CanOpen</a> class represents the CANopen network. The Open method of this class must be called before the class can be used. This method takes a reference to a <a class="el" href="classCanInterface.html">CanInterface</a> object as it's only parameter. The <a class="el" href="classCanOpen.html">CanOpen</a> class will then attempt to open the CAN interface (by calling <a class="el" href="classCanInterface.html#a4">CanInterface::Open</a> method), and if that is successful it will start a new thread which will be responsible for reading messages from the CAN interface.<p>
It is possible to have more then one <a class="el" href="classCanOpen.html">CanOpen</a> object in a system. Each should be connected to a distinct CAN network, and each should therefore be passed a distinct <a class="el" href="classCanInterface.html">CanInterface</a> object.<p>
The primary responsibility of the <a class="el" href="classCanOpen.html">CanOpen</a> object is to listen for messages on the CAN network. To perform this task, the <a class="el" href="classCanOpen.html">CanOpen</a> object creates a separate high priority thread which constantly monitors the CAN network for new messages. Every time a new message is received, the read thread searches for a <a class="el" href="classReceiver.html">Receiver</a> object associated with the message's CAN ID. If such an object is found, it's handler method is called to process the message.<h3><a class="anchor" name="rcvr">
Receiver class</a></h3>
<a class="el" href="classReceiver.html">Receiver</a> objects are used to listen for messages on the CAN network. Each <a class="el" href="classReceiver.html">Receiver</a> object has a CAN message ID associated with it. When a message is received which has this ID value, the <a class="el" href="classCanOpen.html">CanOpen</a> object will search for a <a class="el" href="classReceiver.html">Receiver</a> object with that ID. If no such <a class="el" href="classReceiver.html">Receiver</a> is found, the message will be ignored. If a <a class="el" href="classReceiver.html">Receiver</a> object with a matching ID is found, then the virtual <a class="el" href="classReceiver.html#a5">Receiver::NewFrame()</a> method will be called.<h3><a class="anchor" name="node">
Node class</a></h3>
The <a class="el" href="classNode.html">Node</a> class represents a node (slave device) on the CANopen network. This class is passed a node ID value, and a reference to a <a class="el" href="classCanOpen.html">CanOpen</a> object during construction. The <a class="el" href="classCanOpen.html">CanOpen</a> object identifies which network the <a class="el" href="classNode.html">Node</a> is connected to.<p>
The <a class="el" href="classNode.html">Node</a> class defines various methods to read and write standard objects from the node's object dictionary. The objects that are built into the <a class="el" href="classNode.html">Node</a> class are those that are defined in the CANopen communication specification (DS301).<p>
The <a class="el" href="classNode.html">Node</a> class also includes logic which allows it to transmit and monitor the node guarding (or heartbeat) protocols for the device on the network. If the device being monitored stops responding, or changes state, the virtual method HandleStateChange() will be called. By default this does nothing, but it may be extended to perform any necessary action to handle the condition.<h3><a class="anchor" name="amp">
Amp class</a></h3>
The <a class="el" href="classAmp.html">Amp</a> inherits from the <a class="el" href="classNode.html">Node</a> class, and is used to represent a Copley Controls amplifier on the CANopen network. This class includes numerous methods used to get and set various amplifier parameters. The <a class="el" href="classAmp.html">Amp</a> class also includes several high level methods used to make point to point moves, home the amplifier, and stream complex PVT style profiles down to the amplifier. <hr>
<address style="align: right;">
<small>Copley Motion Library, Copyright (c) 2002-2003
<a href="http://www.copleycontrols.com">
<img src="CCC_logo.gif" alt="Copley Controls Corp." align="middle" border=0 ></a>
</small>
</address>
</body>
</html>