CAN Newsletter December 2006
| Business | 11th iCC - SAE J1939 standards for download |
|---|---|
| Application | CAN cranks up textile finishing machines - CANopen shearer load control - CANopen gateway for the Pope - MilCAN on the Archer artillery howitzer - CANopen prevents fire hazards in conveyors - CAN improves testing of petrol dispensers - Laser ablation system uses embedded CANopen - CAN in rail-road track vehicles |
| Device | Sensor News - Encoders with CANopen Safety - Easter bunny delivers categorized eggs - CANopen synchronization for free - Motion Control News - Motion Control News continued - Motion Control News continued - Changes to CiA 402, IEC standardization, survey - Data-logging News - I/O module News - Vehicle PC |
| Semiconductor |
Moving from 8-bit to 32-bit micro-controllers - ARM7 micro-controller - Flash micro-controller - Semiconductor News - 8-bit micro-controller with 96 KiB Flash - How to choose the optimal CAN cell for an ECU - ARM7-based µC oerates at 3,3 V and at 5 V - CANopen gateway on a 32-DIL board |
| Tool | Test requirements in networked systems - Developments, test and service tool - CAN analyzer with J1939 support - Start-up and diagnostics of CAN systems - Oscillospcopes - Tool News |
| Specification | Additional functions of the CANopen application layer |
| Software | Drivers - CANopen source code |
11th international CAN Conference (iCC)
More than 120 engineers from all over the world attended the 11th international CAN Conference (iCC), which has been sponsored by Vector Scandinavia. About half of the participants came from Northern European countries. The majority of the 24 presentations were related to CANopen technology. All the presented papers are documented in the iCC proceedings available from CiA Headquarters. Prof. Dr. Gruhler, member of the iCC program committee, said after the conference: “The quality of the papers was in average very high, product placement was really an exception.”
One of the most interesting applications presented was the distributed control system for hybrid electrical vehicles developed by the CDAC (Centre for Development of Advanced Computing) of the Indian government. Prototypes of the CANopen-based system were implemented in three-wheelers. The modules are based on the digital signal processor from Texas Instruments or on the micro-controller from Microchip. Most of the devices implement the CiA 401 device profile for generic I/O modules.
The Koncar Institute located in Croatia presented another interesting application: The CANopen-based control system for the Zagreb tramcar. The system uses three CANopen networks connecting the VMEbus-based vehicle control system and the three traction control units, the two auxiliary power controllers and several other modules including brake and door controllers. The hardware is based on Infineon’s 8-bit micro-controller or on Texas Instruments’ digital signal processor.
CANopen shearer load controls
The shearer loaders by Eickhoff Bergbautechnik use modular CompactPCI hardware from Kontron and the CoDeSys SoftPLC together with CANopen and Profibus in a single-system solution. The bundle can also be purchased as a pre-configured, application-ready platform for any control application. In addition to the timesaving hardware/software integration, customers benefit from the ability to customize the system with in-house CPU cards and I/O assemblies.
Increasing: automation in mining
Shearer loaders have established a worldwide reputation in mining coal seams. Depending on their design, they cut coal from the longwall face laterally up to 1,1 m and at a height of up to 6 m in one pass. Depending on the worked thickness, the cutting shearers have a diameter of 1,4 m to 3,2 m and adjustable height. The loosened coal falls onto the chain conveyor below the shearer and is transported away for further processing; hydraulically controlled safety shields secure the structure of the longwall during mining. In general, only one worker is needed to control the heavy machines, which weigh up to 130 metric tons.
In 1950, the Eickhoff company built the first, hydraulically-operated, longwall shearer loader. Since then, the system structure of shearer loaders has developed enormously, and the integrated control intelligence has increased steadily. In 1976, the first longwall shearer loader was equipped with electrical winches and cutting engines on the supporting arms. Eickhoff built the first remote controlled shearer loaders in 1978, and the first high-voltage shearer loader in 1984. In 1990, the first remote micro-processors were brought on board and in 1992 the first sensor-controlled shearer loaders were tested with three-phase current winches to increase performance even further. Since 1997, winch revolutions have been controlled by frequency converters and, in 2001, the Eickhoff SL 500 achieved a cutting capacity of 2 x 825 kW, which is equivelant to the performance of around 16 mid-sized automobiles. With their increasing complexity and performance, the control requirements for these shearer loaders have also increased. Automatic operation, data transfer to control panels, and remote intelligence for adjusting the shearer loader to suit the geological conditions of the seam are vital features of today’s system technology. For example, different cutting processes, which are used according to the geological conditions and mining planning to optimize production, must be controlled. The cutting drives and feed force must also be aligned automatically in order to avoid overloads and keep the system in balance. For all of these functions, which offer the same kind of ease of operation as the latest automobile electronics, there must be a controller. Until now, this has been based on a Motorola 68000 processor. However, this technology is reaching its performance limits, so developers were looking for a new control platform that would ideally last for many years.
Additional functions of the CANopen application layer
CiA has released version 4.1 of the CANopen application layer. The international users’ and manufacturers’ group has been maintaining the higher-layer protocol since it was developed in 1994. CiA has also published additional specifications that standardize CANopen devices with gateway functionality.
The first version of the CANopen application layer (CiA 301) was published in November 1994. Version 4.0 published in 1999 was expanded by just a few functions:
Counter in Sync messages
Dyn-bit in the service data object (SDO) communication object identifier (COB-ID)
Of course the specification CiA 301 version 4.1 was also reworked regarding structure and language. Text passages that were mistakable and often misunderstood were edited. Partly the specification was re-arranged to simplify reading and understanding. Especially the model descriptions upon which the specification is based were enhanced.
CANopen device model
Version 4.1 of the CANopen application layer now features a field device model that is used for the interface-, device- and application profiles (Fig. 1). According to this a field device may feature several CANopen devices with separate CANopen interfaces. Every CANopen device is made up of up to eight logical devices. Thus a CANopen device may implement up to eight CANopen device profiles. Typical examples of this are multiple axes drives with additional I/O functions. A logical device may additionally be divided into virtual devices. This is done especially to describe application profiles (e.g. for lift controllers, photovoltaic systems or construction machinery). Application profiles enable a higher degree of plug-and-play functionality than device profiles.
Device profiles use the specified process data, configuration data and diagnosis information just for device-internal agreements. Thus the digital inputs in the device profile for I/O modules (object 0x6000) corresponds with digital outputs of another device (object 0x6100). Application profiles provide network-wide agreements. Produced process data (e.g. sensor functions) and consumed process data (e.g. control variables) differ only in their access attributes (read only or read/write). Application profiles allow describing PDO transparent routers/gateways. Using device profiles this is only possible with many restrictions.
Sync message with counter
The Sync counter is one byte long. It is used to implement several virtual Sync messages in a network. This is a requirement e.g. for applications that need an evenly distributed bus load. One group of devices reacts to every even Sync message and the other group to the uneven Sync messages. The starting value to which a synchronous process data object (PDO) is to react, is configured in sub-index 6 of the respective communication parameter set.
The maximum counter value (the spillway value) can be configured in object 0x1019. For this it is important to remember that the value must be a multiple of the highest synchronous PDO cycle. This guarantees that the lowest frequency synchronous PDO will be transmitted in one counter cycle. With the Sync counter it is also possible to close control loops via the network. However, here one must consider the maximum delay of messages.











