Plugfest is an event hosted by CAN in Automation that brings together developers from around the world to test and improve the interoperability of CANopen devices. This week, two KEB America employees are traveling to Nuremburg for CANopen Lift Plugfest. The CANopen Lift profile (CiA417) is designed specifically for lift and elevator applications.

The following blog post is a recap of the profile and how it’s used with KEB elevator drives. Though it has yet to gain much popularity in North American applications, our engineers are very familiar with the protocol and are available to answer any questions you might have about how your lift application could benefit.

Background

Reliable and safe operation of elevator systems requires interoperability between many interconnected devices. Throughout all phases of the lifetime of the elevator system if any device malfunctions or fails to operate as intended the entire system is in jeopardy of a shutdown. This is especially true for modern elevator systems which are equipped with many networked electronic devices. Interoperability of each networked device becomes a challenge when devices exchange information using different communication protocols.

With this challenge in mind a technical group named “CANopen Special Interest Group Lift” within CAN in Automation was formed to define a standard communication protocol to be used by all networked devices in the elevator control system. Such devices may be variable frequency drives, car controllers, door controllers, input panels, display units etc. The application profile CiA 417 Lift control was defined as the open standardized protocol for communication for devices in a CANopen elevator system. CiA 417 is based upon the communication profile CANopen, which is commonly utilized in many industrial applications. The goal of creating a standard communication protocol is to create a vendor-neutral elevator system using plug-and-play components. This allows users the freedom to combine products from different producers without the worry of incompatibility issues. The benefits of creating a plug-and-play system include reduced cost and time in designing, installing, and maintaining the elevator system.

The product family COMBIVERT F5 with CANopen Lift (CiA 417) operator has been developed for use in elevator applications. The CANopen Lift operator was built upon an already proven elevator program which includes a wide range of specially designed features to reduce installation times and provide high performance ride quality without sacrificing safety.

For more information, see this video created by the CANopen Lift group (4:16 in length)

Standard Open Protocol

CiA 417 defines a standard communication protocol to be used by all devices on the communication bus for elevator systems. Each device will communicate using the same set of rules when transmitting information. This means that the transmission of information to all devices on the bus will follow a common format and meaning. In addition all information is transmitted and received using the same communication mechanism. CiA 417 defines all parameters, commands, and services used by the elevator system. The corner stone of CiA 417 is its unique object dictionary containing defined I/O settings, configuration settings, baud rates , specific device identifiers etc. Using this common “language” each device on the bus will understand all commands or status messages that are sent.

Furthermore, CAN bus systems allow information to be exchanged to all devices at the same time (Figure 1). Each device then individually determines the importance of each message and decides how it should react. For example, if the elevator drive enters an error state, the drive would send out a corresponding error register and error description to all devices on the bus signaling an error. The state of the drive will be universally known to all devices for proper system correction. Accessing status information on all devices can help in reducing the time and cost spent on troubleshooting and resolving issues.

An additional specification that ensures reliable communication and fast error handling is the heartbeat protocol. The heartbeat is used to confirm connection and status of each device on the bus. Periodically each device will send out a short message on the bus indicating to every other device it is connected. If a device does not respond in a specific amount of time the master device can take a specific action to reset the device or trigger an error.

Figure 1

Virtual Terminal

CiA 417 allows the parameters from all devices to be accessed and adjusted regardless of physical location with any human machine interface. Remote access to any device is achieved through the virtual terminal. For example, the adjustment of a drive parameter may be very challenging if the elevator is machine room less (MRL) and the drive is mounted in the hoistway. This is simplified with the virtual terminal as it would be possible to adjust drive parameters directly from a car controller. The virtual terminal uses virtual keyboard codes (Figure 2) and screen characters using ASCII codes according to ISO 88915 standard (Figure 2) for device parameterization and configuration. Each HMI using the same codes and sequences can be used as the screen of a remote device. If a wireless device is connected to the bus it is also possible to remote connect using a smartphone and utilize it as an adjustment tool. The KEB operator interface includes the virtual terminal for universal access to all devices on the bus.

Figure 2

Hardware

CANopen is a higher level communication protocol built upon the CAN protocol. The underlying CAN protocol is the foundation of the networking hardware and defines the procedure of data transfer.

High Availability, Low Cost

CAN bus systems are utilized in many including industrial and automotive applications. The high demand of CAN controller chips creates a high supply of CAN chips from various chip manufacturers at a cost effective price.

Excellent Error Handling

Elevator control cabinets often contain many potential forms of electromagnetic interference or EMI. Troubleshooting EMI and corrupted data transfer can cause significant installation delays and come at a considerable financial loss. CAN controller chips have advanced error handling built-in. CAN hardware can detect bit errors and prevent transmitters and receivers from transmitting invalid messages before further data transfer. Error checking mechanisms include bit monitoring frame checking, acknowledgment checking, and error confinement among others.

Figure 3

KEB CANopen Lift Drives

KEB CANopen Lift drives take reliability and interoperability a step further by integrating advanced features and diagnostics in its elevator application software.

High Performance Control

The position controller in the drive can be used in conjunction with a CAN encoder to determine precise position and movement of the elevator car. This information can be used for direct-to-floor position control. Not only does this provide an optimized speed profile it also reduces the burden on the main controller CPU. The intensive task of calculating slowdown distances and determining deceleration or acceleration rates can be handled by the KEB drive for a smooth and precise approach to the floor with minimal leveling distance, as depicted below (Figure 4).

Figure 4