Generally speaking, CANopen is economical in its use of the available identifiers, so that the use of the 29-bit versions remains limited to unusual applications. The data width of 32 bits also allows 29-bit identifiers in accordance with CAN 2.0B to be entered, although the default identifiers always refer to the more usual 11-bit versions. It is coded as a 32-bit value in which the least significant 11 bits (bits 0.10) contain the identifier itself. The identifier is located in subindex 1 of the communication parameter set. Thus a node can make its input information available to a number of bus devices at the same time - even without transferring them through a logical bus master. For each CAN data telegram there may only be one sender node (producer), although all messages sent in the CAN broadcast procedure can be received, as described, by any number of nodes (consumers).
It is used to identify the data, and determines their priority for bus access. The most important communication parameter in a PDO is the CAN identifier (also know as the communication object identifier, or COB-ID). These entries and their significance for the communication of process data are explained below. The TwinCAT System Manager automatically assigns the set parameters to the relevant object directory entries. The Bus Couplers or Fieldbus Box modules make 16 RxPDO and 16 TxPDOs available for the exchange of process data (although the figure for Economy and LowCost BK5110 and LC5100 couplers and the Compact Box modules is 5 PDOs each, since these devices manage a lower quantity of process data).įor each existing process data object there is an associated communication parameter object. In the same way, the entries for the transmit PDOs are located from index 0x1800 (TxPDO1) to 0x19FF (TxPDO512).
There can be up to 512 RxPDOs (ranging up to index 0x15FF). The parameters for the receive PDOs are at index 0x1400 (RxPDO1) onwards. Like all the CANopen parameters, these are also available in the device's object directory, and can be accessed by means of the service data objects. The PDOs can be given different communication parameters according to the requirements of the application. This naming convention is retained in the TwinCAT System Manager. Receive (Rx) PDOs and transmit (Tx) PDOs are distinguished, the name being chosen from the point of view of a device: an input/output module sends its input data with TxPDOs and receives its output data in the RxPDOs. The PDOs each correspond to a CAN telegram, whose specific CAN identifier is used to allocate them and to determine their priority. These segments are known as process data objects (PDOs). The process data in CANopen is divided into segments with a maximum of 8 bytes. All the other nodes listen, and use the identifier to decide whether they are interested in this telegram, and handle it accordingly. This might, for example, be triggered by an event.
In this model, a bus node transmits its data, as a producer, on its own accord. Under CANopen the process data is not transferred in a master/slave procedure, but follows instead the producer-consumer model. CANopen is not limited to this communication principle, since the multi-master bus access protocol allows CAN to offer other methods. In many fieldbus systems the entire process image is continuously transferred - usually in a more or less cyclic manner. Process Data Objects (PDO) TwinCAT System Manager: CANopen
0 kommentar(er)
