Decentralized support for CAN and CANopen via TCP/UDP

Decentralized support for CAN and CANopen via TCP/UDP

CAN and CANopen Often enough control systems need support for CAN or CANopen but no reasonable option exists to equip these control systems directly with CAN or CANopen. This may due to mechanical constraints or software limitations.

In such cases dedicated CAN units with Ethernet (using TCP/IP) connectivity may be an option. These units are mounted in a CAN-wise convenient location and receive its commands from a TCP socket from an embedded PC or other control system. There - on the other side of the socket connection the control system is located and operates these dedicated CAN units. The dedicated CAN unit can use a CAN-to-TCP Server (such as the CAN server horch) and operates CANopen in the control system or operate CANopen directly on this dedicated CAN unit and only control the CANopen behavior vie DS309-3 using a software such as port's CANopen Server.

A CAN-to-TCP Server simply receives and transmits CAN Frames and is controlled by the control System.This can be either be plain CAN or a CANopen Library residing in the control system, just not having a local CAN controller but a remote dedicated CAN unit. A prominent example is the port provided EtherCAN-ARM9.

On the other hand - the CANopen-to-TCP Server, eliminates the need for a CANopen Library in the control system and is controlled with simple ASCII Commands, sent to the TCP Socket. Such an CANopen based solution is available in the by port provided EtherCANopen-ARM9 unit.

Either solution - whether plain CAN based or already CANopen based - has advantages and disadvantages. The application rules.