Liftinstituut tarafından sertifikalandırılan “Güvenli Tork Kesme”
(Safe Torque- Off) özelliği sayesinde motor ve kurtarma kontaktörlerine gerek yok!
Main devices in a lift controller system
A lift controller has two main units: the lift controller electronic board and the motor driver. Other elements in a lift controller box are switching, wiring and limiting elements. The lift controller board collects all of the information in the shaft and sends commands and manages the motor driver, as well as other units in the lift system. Any motion request is evaluated by the controller by sending appropriate commands to the motor driver. The motor driver behaves as a slave, and the lift controller acts as a manager.
The job of the motor driver is only to accomplish the motor rotation according to the commands of the controller. The basic parts of the lift control system are shown in Figure 1.
All of the shaft information, including car position, comes to the lift controller. The motor driver knows nothing about the shaft. It only gets commands from the controller; it gets speed and rotor position from the motor. The motor driver generates voltage to rotate the motor at the desired speed.
The simplest information flow between controller and driver is shown in Figure 2. The controller sends travel speed, direction and enable signal to the driver, and the driver sends the actual speed and device status to the controller. There may be much more data flowing there, but these are the basic commands and information. This communication can be in parallel or in serial connection.
In parallel mode, outputs of one device are connected to the inputs of the other device and vice-versa. In parallel mode, each command or information requires one input in the first device, one output in the other device and wiring between them. Therefore, there is a physical limit to the channels that can be implemented between these two devices, and the device with the fewest terminals sets this limit. Furthermore, the output and input functions supplied by the controller and motor driver vary according to the brand or model of the device selected. Moreover, you cannot use a function unless it has been already implemented in both devices, and you cannot transfer numeric data in a parallel connection, since one terminal can carry only one-bit data. For example, the actual speed cannot be sent to the controller in numeric format by the reverse. Only information that says the “speed is above or below a set value,” but not the value of the speed, can be sent. On the other hand, all controllers and motor drivers support parallel connection, the simplest way to connect a controller and motor driver. It needs neither a protocol nor communication channel setup.
In serial connection, only the serial communication terminals are connected between the controller and the motor driver (Figure 3). All of the information and commands between two devices are transmitted via the serial connection. Any data can be transferred to the other device, provided that the other device can use or understand it. In theory, it seems very easy to share information; in practice, however, it is not so easy.
vices with identical serial standards, such as CAN or RS485, and identical data structures. While most controllers and drivers have serial ports, they do not all support the same standard. When the communication channel is set up, the next problem is the protocol. Two devices must support the same protocol; that is, speak the same language. Otherwise, they cannot understand each other.
Once the two devices can communicate, they can share data, which increases their control over the motor and shaft. The lift controller can manage the lift travel much better by having the actual speed and braking distance information supplied by the reverse. The devices can share their data via serial bus to improve their control on the system.
Serial communication between two devices seems the best way. However, there are some problems there, too. There are various communication protocols, but some motor driver and controller manufacturers do not support them all. It may be that two devices cannot communicate, unless they are checked carefully before using them in an application. No other input or output is necessary to transmit more data. Software can improve communication sufficiently to transmit new data.
DCP and CANopen Profile Position Mode systems are developed specially for lift applications, facilitating communication between controller and motor driver. They also employ an absolute encoder to get car-position data. This allows the controller and motor driver to have speed, current car position, target car position and braking-distance information. They both use this data to control the motion properly and achieve level accuracy.
The first integrated devices in the market were, in fact, two devices packed into one box, such as shown in Figure 6. The easiest and fastest way to have an integrated controller is simply by mounting a lift controller board onto a motor driver, wiring the terminals between them and putting all parts into a box. This can be easily implemented by using any motor driver and any lift controller board. Nevertheless, this method will result only in saving some space and wiring inside the controller box. The controller board and motor driver are usually produced by two different manufacturers.
Integrated devices produced in one box and by one factory or manufacturer emerged after some controller manufacturers started to produce motor drivers, as well. These manufacturers gained the knowledge to design one electronic device capable of driving the motor, as well as the lift (Figure 7). In this example, one microcontroller is controlling all lift jobs, as well as motor rotation.
Now we can speak about a completely new device. As you can easily see, there is no need for a communication path or protocol. One microcontroller knows everything and does everything. It does not need anything else.
However, precise motor control is carried out through a vector-control method. The motor-driving performance is highly related to the speed of the calculations to evaluate motor voltages. Many space transformations and trigonometric functions must be performed periodically in a time interval less than the carrier frequency period. A digital signal controller (DSC) is typically used for vector control. The DSC is designed to execute mathematical operations over a much-shorter timeframe than a microcontroller. A dedicated DSC should be employed for the motor control section if a carrier frequency at 16 kHz is supported. Otherwise, the system barely reaches 10 kHz. An integrated lift controller with one microcontroller and one DSC is shown in Figure 8.
In this device, both microcontrollers can reach all variables in the system but not share jobs. The DSC deals only with the calculations of vector control and motor feedback, whereas the microcontroller deals with lift jobs. They send commands or acknowledgment to each other via internal communication at a very high speed.
we can see the controller with integrated device. It can be easily seen at first look that the system is simplified.
However, there is more — now we can list the benefits:
The electric wiring is simpler. There are fewer devices, connections and wires.
The space requirement inside the control box is smaller.
No need for interface to devices, communication protocols or serial setup
The controller part and motor driver both know everything, so they can use any data when required.
An incremental encoder can be used very efficiently, since both devices can get information immediately. Dedicated DSC encoder peripherals enable the device to evaluate car position very accurately.
The number of parameters is decreased and are more efficient.
No need for two monitoring panels; one is sufficient.