Resources

By Christian Schlegel, IXXAT Automation



One solution circumventing the limitations of CANopen (limited bandwidth, limited system extension) would be switching completely to Ethernet POWERLINK. However, for many systems this would be like the tail wagging the dog since the POWERLINK technology is more expensive than the CANopen technology (e.g. cabling costs, hardware costs, system integration costs). Instead of converting a system completely from CANopen to POWERLINK, it often makes sense to build a new system structure using several subsystems. The following two system architectures are possible:

POWERLINK as main or backbone system with CANopen sub-systems

In this system approach, sub-functions of the entire system are implemented using CANopen sub-systems and POWERLINK as the backbone or main control system. This concept allows the fast distribution of process data between the CANopen sub-systems, the centralized handling of control data and logging of process data for all CANopen sub-systems. It also allows longer extensions between the CANopen sub-systems and thus a longer extension of the total system.



Figure 1: System architecture with POWERLINK as main network and CANopen as sub-networks

CANopen as main or backbone system with POWERLINK sub-systems

This system concept would apply mainly for sub-functions, which require very short cycle times (like high-performance motion sub-systems) or high bandwidth. A use case for this system concept is, for example, a measurement sub-system where the measurements are processed and stored in the sub-system and only calculated results and control data is exchanged with the CANopen system.



Figure 2: System architecture with CANopen as main network and POWERLINK as sub-networks


The main functionality of the gateway is to forward process data transmitted by PDOs from one system to the other system. Since not all process data, which is transmitted in one system is important for the other system, it is necessary that the gateway is able to configure which process data is exchanged between the two systems.

In addition to the exchange of process data between CANopen and POWERLINK systems, the possibility of accessing devices in other systems across system borders by SDO is required (remote SDO access). Since the SDO access is a client-server based mechanism, a device addressing method becomes necessary that is able to address a certain device in a certain sub-system (or network). For CANopen, a network-ID was already introduced with DS400 [1]. For POWERLINK, the IP addresses in combination with the NAT mechanism (Network Address Translation) already provide this possibility.

Finally, the forwarding of error messages from a sub-system into the main/backbone system and also the control of the network management of the sub-system from the main/backbone system is a further requirement.

POWERLINK / CANopen Gateway

A typical POWERLINK / CANopen gateway can be implemented using a standard CPU with integrated CAN controller and Ethernet MAC. It is recommended that a 32-bit CPU with a mid range performance is used in order to achieve acceptable latency and response times.

The basic software architecture of a gateway is shown in figure 7. Basically a CANopen stack and an POWERLINK stack have to be implemented. In between the stacks, a system control task is responsible for handling remote SDO access and forwarding of NMT services and error information.




Figure 3: Software architecture of an POWERLINK-to-CANopen gateway


For the exchange of process data, which is transmitted on both sides inside PDOs, a process image is implemented between both stacks based on a shared memory. Using the network variables approach specified in CiA 302 and CiA 405, process data received on one communication interface by RPDOs can be flexibly mapped into TPDOs on the other communication interface. Within the index range of A000h to A8FFh, each object entry with a given index / sub-index references a certain location in the input or output process image by defining a data type and an address offset. Table 1 gives an overview on object ranges and data types. Table 2 shows some examples concerning the relation of object index/sub-index, data type and location in the process image. E.g., the object A101h/10h references a location inside the input process image of data type UNSIGNED16 at address offset 538. The object A680h/02h references a location inside the output process image of data type UNSIGNED32 at address offset 4.


Table 1

 

Table 2

In order to handle remote SDO access services, the existing SDO protocols need to be extended. For CANopen, an extension was already introduced in CiA 302-7 (formerly CiA 400) by means of the SDO Network Indication protocol.

On the POWERLINK side, an extension of the SDO protocol or SDO services is required to consider the extension of the CANopen SDO protocols. Therefore, an POWERLINK / CANopen gateway needs to distinguish two scenarios: (a) the remote device which shall be accessed by a remote SDO access is located in the same POWERLINK network or in another remote POWERLINK network which can be accessed without a CANopen network in between or (b) the remote device is located in another network which can only be accessed via a CANopen network.




Figure 4: Exchange of process data via the process image in the shared memory


In scenario (a), the POWERLINK / CANopen gateway answers the CANopen SDO network indication request with a response and waits for the consecutive SDO access request. This request is then transferred to the new POWERLINK SDO Remote Read by Index or SDO Remote Write by Index service. These services use the parameters net_id and node_id for referencing the remote device.

In scenario (b), the CANopen SDO network indication protocol needs to be routed over the POWERLINK network(s). Therefore, a new POWERLINK SDO service SDO Network Indication is introduced. This service works in the same way as the CANopen service, which means the gateway transmits the POWERLINK SDO Network Indication request to the next POWERLINK / CANopen gateway and waits for the response. After receiving the response, it also transmits the SDO Network Indication response on its CANopen interface.

The POWERLINK / CANopen gateway requires a translation table, which contains the information whether a certain remote network can be accessed directly (only via POWERLINK networks) or that there are CANopen networks in between. The translation table can be configured via object dictionary entries.

A CANopen NMT master or POWERLINK Manager can be requested to send NMT services using object 1F82h as defined in CiA 302 for CANopen and 1F9Fh as defined in for POWERLINK.

Errors occurred and signaled in one network by means of an emergency message (CANopen) or via the error signaling mechanism (POWERLINK) can be forwarded by the gateway to the other network by using a dedicated error code indicating that the error transmitted occurred in another network. In the additional information field of the error message, the information about the error source can be described by network ID, node ID and original error code.

An POWERLINK / CANopen Gateway can be implemented within a small device. The shown example is based on the Freescale Coldfire MCF5235 in a housing for DIN rails.




Figure 5: POWERLINK / CANopen Gateway