News | September 2020
Touchless voice-controlled home lift
Vocal suite is Nova Elevators' new home lift that can be fully operated with the voice, avoiding all contact with surfaces.
If you design lifts using devices from different manufacturers, interoperability is essential. This keeps effort low when integrating third-party products. Especially, standardized interfaces for car drive units would help.
CAN (Controller Area Network) is a serial three-wire bus system. CAN was originally developed by Bosch for in-vehicle networking in passenger cars. The CANopen application layer was developed within a European research project beginning of the 90ties.
It was handed over to the CAN in Automation (CiA) association for further development and maintenance. At the beginning of the millennium, CiA members started to specify the CANopen Lift application profile (CiA 417). CiA also includes a standardized interface for car drives.
Initially, there were only a few drive manufacturers who support CANopen-Lift. In the meantime, several drive companies have a CiA-compatible interface (see box). These drives are interoperable with the lift controllers that have implemented CiA and even exchangeable in terms of basic functions.
Many manufacturers tested the compatibility and interoperability in many so-called Plugfests: The drives were connected to several lift controllers from different brands and checked for correct functionality.
If optional functions are to be used, both partners (lift controller and car drive) must support them. When choosing devices, lift builders have to take this into account. Only two or three process data objects (PDOs) are mandatory, all other specified PDOs are optional.
The car drive unit interface CiA 417 derives from the internationally standardized CiA 402 device profile for drives and motion controllers (IEC 61800-7-301 / 401). However, car drive units use just a subset of this IEC standard and some lift-specific extensions. In the meantime, it is a widely used and mature interface.
This interface is a logical entity specified in the CiA 417 series. It receives the control-word containing commands and target values from the car drive controller. The car drive unit confirms this by means of the status-word containing the response including the actual drive values (speed, position, acceleration, or jerk).
If there is no absolute encoder implemented, the Profile Velocity Mode is used. The host controller provides the target velocity. If there is an absolute encoder available, the Profile Position Mode is applied; the controller sends the target position. The operation mode can be configured.
The parameters for the velocity profile are stored in the car drive unit and can be configured by the drive controller using the CANopen SDO (service data object) service. This service is confirmed meaning that the server responds the success of the read or write operation. Due to safety reasons, configuration is possible in Operation Enable state of the car drive unit.
The control-word or the status-word is transmitted using the CANopen PDO (process data object) service. This service is not acknowledged (fire-and-forget) on the communication level. But it is confirmed on the application level.
Drive-specific functions such as motor relays are operated locally in the drive unit. Target velocity unequal zero determines motion. The sign of target velocity indicates direction; positive values indicate upward motion of the car. The car drive independently calculates the torque required from the target values and travel parameters set.
Although the CANopen-Lift specification for the interface to the car drive is standardized, manufacturer-specific expansions are possible. Naturally, these are not all supported by all lift controllers.
Nevertheless, interoperability and exchangeability are guaranteed regarding the basic functions. The basic functions include actuation of the drives and transmission of target values.
The author is Managing Director of CAN in Automation.
This might interest you as well: