CAN Newsletter March 2007

The future of CiA

To predict the future of something that has no history is impossible. To look into the future considering the past is necessary, if you want to make strategic plans. Back in 1992, I had no personal experience in managing a nonprofit trade association. All my knowledge came from second-hand experiences of the VMEbus International Trade Association (VITA), because I worked closely with them as editor-in-chief of the German VMEbus Magazine. Today, I have 15 years of experience, gathered from many more than 500 CiA meetings, from eleven international CAN conferences (iCC), and from more than 1.500 seminars and presentations all over the world. To sum it up, CiA has achieved a good market penetration in Central Europe, in Scandinavia, and in Italy. There is still some marketing activity due in South and East Europe. During the next few years, we will increase our training and seminar presence for these regions. We also have established a good position for CANopen in medical applications in North America. But we have not penetrated North America as we have Europe. In particular, in industrial automation and off-highway vehicles we must do more. And we have never been in South America. We have not promoted CAN technology in this emerging market. In Asia, we have started just recently to increase marketing and training activities. China, India, and a number of the so-called Tiger countries are hungry for information. Japan has, as many other countries, a high language barrier toward English. Therefore, CiA is going to provide basic technology information also in languages other than English in the future. Within the next few years, CiA’s website will be translated into several languages (Russian, Chinese, Japanese, and maybe others). In order to be present worldwide, the CiA staff needs more support from its members and their sales partners. The transfer of knowledge is one of the most challenging tasks for the next five years. CiA is willing to provide trainings for trainers, so that these trainers can act as knowledge multiplier. Due to our limited resources, we serve markets with the majority of members first. Fig. 1 shows the current member number. Most of the members are headquartered in Austria, Germany, and Switzerland. We should try to increase them in other countries. Every CiA member should convince other companies of the benefits of a CiA membership. No doubt, CAN has been and will be the dominating network in passenger cars. This is true for at least two more car generations. One car generation lasts approximately five years. Of course, CAN will not be the only network technology used in automotives. LIN and FleyRay will complement CAN networks on the low-end respectively on the high-end side. With OSEK, Autosar and standardized higher-layer interfaces the carmakers follow the trends that have been used in industrial automation for years. In the CAN community, DeviceNet and CANopen were introduced more than ten years ago. In industrial applications, the CAN-based CANopen and DeviceNet solutions compete with other buses and networks. CANopen as standardized embedded control network competes mainly with proprietary serial interfaces such as RS-485, etc. In modular machine design, CANopen is not only used as embedded control network and as deeply embedded network within modular devices, but also as open network between sub-systems. Within the next few years, more machine branches will request standardized CANopen interfaces as the extruder manufacturers have already done.

Controlling CANopen nodes remotely via Ethernet

The industry pushes more and more towards networking of machinery to get real-time information about the manufacturing processes to better coordinate company-internal processes. The already installed Ethernet-based infrastructure of the company (Intranet and Internet) is used for this. Gateways provide access to the CANopen networks via Internet thus providing the needed information.
This technology cannot only be used after development for process optimization but also already during development. Many developers that can be located in separate rooms or buildings can access the same CANopen network to simultaneously watch and analyze the network traffic and configure CANopen devices. In order to provide this possibility, tools have to work with the client server principle. The programs CANopen Gateway Server and CANopen Device Monitor are tools that work together using this principle.
The CANopen Gateway Server implements the gateway protocol CiA 309-3 that provides CANopen services via a TCP/IP connection. Commands are sent as ASCII strings. This allows using a simple Telnet connection to the server to issue commands into the CANopen network.

This short command reads the device type of a CANopen device that has node-ID 32.
The CANopen Device Monitor is the graphical user interface and a comfortable tool for working with CANopen devices. It utilizes a TCP/IP connection to the CANopen Gateway Server to access the CANopen network. For simple test and configuration tasks all CANopen services are easily accessible with a few mouse clicks:

• Read and write values with SDO
• Send Sync messages
• PDO set-up
• Display PDO values in a strip chart
• Reading process image cyclically via SDO
• Changing NMT states

In a simple device configuration only defined values have to be written to entries of the object dictionary. CANopen already has the means for doing this kind of application. It is called device configuration files (DCF). In the CANopen Device Monitor the objects are selected and then saved to the DCF. The configuration for the next device is as easy as loading the configuration and sending it to the device. Many CANopen tools already can load the DCF and use it. For complex configurations loading a DCF may not be sufficient, because the device configuration depends on device parameters that are first known at runtime. This could be different I/O devices that have manufacturer-specific functionalities. For this application case the CANopen Device Monitor provides the integrated scripting language Tcl/Tk that provides all CANopen services of the CANopen Gateway Server. Further the scripting language allows creating a device-specific test environment with a graphical user interface (see Fig. 2).
These eight lines create a new window and place a button on it. On button press the function startTest1 is executed. It reads the value of index 0x2000 and shows it in a message box. The test scripts can be saved and be reloaded again. For special applications plug-ins provide extra functionality. There are plug-ins for:

• Layer Setting Services
• Safety configuration
• CiA 402 position mode
• CiA 402 state machine

The CANopen Device Monitor with its function range is a versatile tool for configuration during development and initial operation of CANopen machines. Through the use of the client server principle several developers can work in the same CANopen network simultaneously. This has the advantage of being able to error track and diagnose during development, production testing and initial operation.

Integrating Modbus nodes into a CANopen network

The amount of Modbus equipment deployed worldwide is substantial. Legacy equipments, but also new designs, often feature a Modbus communication link. However, some of this equipments is not available with a CANopen interface. In this case, two solutions are possible:
Two different networks can be set in the production unit, leading to long and complicated development, commissioning and maintenance tasks.
The Modbus equipment can be turned into CANopen nodes. With this solution, only one CANopen network is deployed along the production unit, simplifying deployment and use of equipments.
The Agiligate and Agiliplug gateways bring CANopen connectivity to your devices:
The Agiligate gateway is based on a DIN-rail mountable enclosure. It is used together with already existing Modbus equipment.
The Agiliplug board fits in a DIP32 socket. It is used in new designs. It is fully integrated inside the product.
Both products do the same job. They are configured and used in exactly the same way.
The gateway can be configured via a CANopen network configuration tool. This intuitive method saves users from having to learn how to use a new tool or a new configuration language. The gateway can be set up quickly, increasing productivity and shortening development costs. Any configuration mistake or Modbus error is indicated on the CANopen network using CANopen Emergency objects. A comprehensive set of LEDs also helps to diagnose any configuration or working problem. The gateway can be used in RS-232 or RS-485 mode. The RS-232 mode allows communication only between two Modbus devices (point-to-point connection). RS-485 allows communication with multiple devices on the same bus. RS-485 has advantages compared to the RS-232 with regards to noise immunity, network length, etc. The board is used in TTL mode. Its Tx, Rx and RTS signals can be directly interfaced with the UART of any micro-controller.