CANopen specification for lift control systems: Difference between revisions

From CANopen-Lift
Jump to navigation Jump to search
No edit summary
 
mNo edit summary
Line 1: Line 1:
[[de:CANopen Spezifikation für Aufzugsteuerungssysteme]]
''By Holger Zeltwanger, CAN in Automation [http://www.can-cia.org/lift (www.can-cia.org/lift)]''
''By Holger Zeltwanger, CAN in Automation [http://www.can-cia.org/lift (www.can-cia.org/lift)]''


Line 38: Line 39:


Source: CAN Newsletter Special Lift 2005 [http://www.can-cia.org/newsletter/ (www.can-cia.org/newsletter/)]
Source: CAN Newsletter Special Lift 2005 [http://www.can-cia.org/newsletter/ (www.can-cia.org/newsletter/)]
[[Category:Press]]

Revision as of 14:55, 23 October 2007

By Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)

CAN in lift control application has been used for many years by major lift manufacturing companies. In 2002 several medium-size companies decided to move to a standard higher layer protocol based on CAN. They decided to use CANopen as a basis for this standard. The goal was to have some kind of plug and play lift control system for any standard lift application. The result of the standardization work is the CANopen application profile for lift control systems CiA DSP 417. By use of this standard it is possible to build in maximum a lift application with 254 floors and eight parallel lifts.

In October 2003 the first CANopen lift control system prototype examples were demonstrated at the Interlift exhibition in Germany. A prototype lift system was assembled at the CiA and members booth made from devices by several manufacturers. The lift controller, the door controller, panels, displays, and other equipment: all communicating and exchanging data were integrated via the CANopen network. For the lift system designer it will be a great advantage to buy off-the-shelf products following the CANopen lift application profile specification, plug them together, and the lift control system will work with only a minimum of configuration effort.

This is particularly interesting for all small and medium-sized lift control builders. They do not depend on a specific device or control system supplier. Multi-sourcing is an important issue in order to provide a maximum flexibility and functional options.

CANopen basics

CANopen is a set of network protocol specifications based on the Controller Area Network (CAN) that is used in most modern passenger cars. The CAN controller chips sold in high volume (some 300 Million every year) are available at reasonable prices. This is why several of the large lift manufacturers have used CAN-based networks ever since the mid-nineties.

However, CAN is just a data link layer protocol. In human communication you would call this a character set, such as the Latin abc. In order to communicate between human beings you additionally need a language that is made up of grammar and vocabulary. In network technology this is called application layer and application profile. The application layer defines the communication protocols to be used (comparable to the human language grammar), and the application profile defines all the parameters and signals. The CANopen protocols are specified in the EN 50325 European standard.

The CANopen Lift profile

CiA’s CANopen Special Interest Group (SIG) Lift developed the DSP 417 specification describing the communication in multiple lift control system. The exhibiting companies at the Interlift showed prototypes of panels, drives, doors, controllers, etc. compliant to the CANopen Lift standard. The CANopen Lift specification is available for CiA members for free and may be implemented without any license fee. The specification describes the default communication of a control system for up to eight lifts with up to 254 floors each. The default communication can be changed via configuration. The lift application profile defines so-called virtual devices. A physical device may implement several virtual devices. However, a virtual device cannot be distributed to different CANopen physical devices. The following virtual devices are specified:

  • Drive controller
  • Call controller
  • Display controller
  • Car door controller
  • Car drive unit
  • Car position unit
  • Car door unit
  • Light barrier
  • Car panel
  • Car display
  • Sensor unit
  • Load measuring unit
  • Panel input unit
  • Panel output unit

All these virtual devices implement mandatory functions as well as optional behavior. For example, the car door controller transmits the control word to the car door unit commanding the door to open or to close in pre-defined manner. And the door unit response its status word via the CANopen network to the control system. The car door controller receives also the light barrier status information via the network.

The virtual device concept allows the introduction of user-transparent gateways. CANopen networks are limited to 127 devices in one network (currently available CAN transceiver may restrict this figure even to a lower number). Gateways may overcome this limitation. The gateway may implement up to 254 virtual devices on each side a represent them to the other interface. The use of gateways also solves the problem of too high busloads.

The virtual device definitions for the car drive unit (motion controller) and car position unit (encoder) follows the generic CANopen device profiles for motion controllers (CiA DSP 402) and encoders (CiA DS 406). However, in lift control applications they use different object dictionary entries. This is because the application profile uses the very same object dictionary in all physical devices. In addition, any PDO communication is pre-defined in another way than the generic device profiles. The lift application profile pre-defines the PDO communication between the devices. No simple master/slave communication is specified. For example, the car door controller and the car drive controller receive the car position unit information. The benefit of this application profile for lift system designers is that they do not have to deal with the communication details. Everything is pre-defined by the lift application profile. However, if a different behavior is required, system designers may configure the functionality that is to be changed. The specification is open to this kind of customer-specific behavior. Highly sophisticated tools, which implement the lift application profile details, are available for this purpose.

Source: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/)