Application by NRMKEtherCAT Framework

From Neuromeka Wiki
Jump to: navigation, search

EtherLab Domain Configuration

What is domain?

From the viewpoint of EtherLab users the master gets/sets process data objects (PDOs) from associated domains. A domains may as well be regarded as contiguous memory block which contains values of PDOs collected from or distributed to the configured slaves. EtherLab allows defining more than one domains , but at least one. Each can be transmitted and/or received separately.

PDOs (process data objects) and PDO mappings

Consider the example EtherCAT slave configuration in the figure below consisting of many slave types including four types, Maxon, ELMO, EL1008, and EL2008. Each slave type is intended for specific task. For example, Maxon and ELMO drive servo motors, while EL1008 and EL2008 execute digital inputs and outputs. Depending on slaves the necessary data to carry out the intended task vary (though slaves belonging to a similar category are likely to share some of them).

EtherLab domain configuration

EtherLab domain configuration

Let us refer this data to as process data objects (PDOs). EtherCAT, in particular CoE (CANopen over EtherCAT) protocol, provides many standard PDOs which can be referenced by a unique index, e.g. index 0x607A stands for target position and index 0x6064 for position actual value. Let us suppose that Maxon slaves control the motor in position control mode, referred to as CSP (cyclic synchronous position). Then, the target positions and the position actual values should be traded with a master. In particular if a master is to exchange these data with Maxon slaves one has to define one or more associated domains where the current values are referenced.

For effective communication EtherCAT slaves provides a number of predefined sets, to which associated PDOs are mapped if it is regarded that the set had better be transmitted and/or received once. This is referred to as PDO mapping. For each slave there are two kinds of PDO mappings, that is one to transmit and the other to receive from the slave. They are called TxPDO and RxPDO, respectively. For example, for Maxon slaves, target position (of index 0x607A) can be mapped to RxPDOs, not TxPDOs, and vice versa for position actual value (of index 0x6064). Note that RxPDO and TxPDO is the minimum unit for communication through EtherCAT bus, not the individual PDOs. This means that if a master needs the value of position actual value from Maxon slaves, they should send a RxPDO (to which the object is mapped) as a whole to the master.

Depending on task necessary PDOs may be distributed across more than one PDO mappings. Then a master and slaves exchange all PDO mappings.

In general PDO mappings are also assigned indices, e.g. RxPDOs have index 0x1600, 0x1601, ..., and TxPDOs have index 0x1A00, 0x1A01, .... Therefore EtherLab master should prescribe which PDO mappings are utilized for current applications. The rule to choose PDO mappings for trading specific PDOs may not be unique. However, the union of selected PDO mappings should contain every necessary PDO object.

Domain Configuration

As mentioned before EtherCAT bus transfers PDO mappings as a unit. From master's viewpoint what is concerned is the values of only the necessary PDOs. It need not care the other members belonging to the PDO mapping (which contains the necessary PDO).

It had better expose only necessary PDOs to the master for easier maintenance. This is what domains are for. A master can register only necessary PDOs to a domain to access their values. For example, a master registers target positions of Maxon slaves in a single domain, e.g. named RxDomain. Inside this domain the values of target positions of Maxon slaves are arranged contiguously.

Registration to a domain requires to specify the slave as well as the PDO object. (Recall that this PDO object should belong to at least one PDO mapping that was chosen to be sent/received.) For example, if a master needs position actual values for all the Maxon slaves, it should register the PDO object repeatedly for each slave.

Inside domains the values of the registered PDO objects can be accessed by the offset address from the domain pointer pointing to the head of the domain buffer. This domain address should be remembered to access a value of a specific slave's specific PDO.

The following figure exemplary shows a domain configuration of, say, RxDomain. You can see that each Maxon slave registers PDOs from two RxPDOs. As you can see the figure, three PDOs (in blue) come from the first RxPDO (of index 0x1600) and four PDOs (in brown) from the second PDO (of index 0x1603). Then, each ELMO registers seven PDOs (in gold) from one RxPDO (of index 0x1600), and the like.

EtherLab domain composition

EtherLab domain composition

NRMKEtherCAT Framework

NRMKEtherCAT Framework provides APIs and interface classes for easier domain configuration upon raw EtherLab APIs. It is not intended to be a general EtherCAT configuration tool, e.g. TwinCAT. Rather it is just a simple application to help unexperienced EtherLab users to get used to EtherLab, because it is not that easy to configure custom domains without error for beginners.

Interface classes

  • SystemInterface_EtherCAT:
    • This class plays an interface role in order for NRMKFoundation framework to communicate with EtherCAT system.
    • This class keeps all of EtherCAT components inside for further read/write data from/to EtherCAT slaves.

Example using EtherCAT interfaces based on NRMKEtherCAT Framework