1. Introduction Currently, the production and usage of elevators have become one of the indicators of a country's level of modernization. Elevators are complex transportation devices in high-rise buildings, integrating electromechanical systems. They involve multiple scientific fields such as mechanical engineering, electronic technology, power electronics technology, motor and drive theory, and automatic control theory. The elevator call controller is an important component of the elevator, located on the left or right side of the elevator door on each floor. It is the call device for each floor, used to provide call request information for each floor and display the current elevator operation status. Passengers can obtain a wealth of information about the elevator's operation through displays, buttons, etc. This paper designs a call controller using CAN bus technology. Each controller only requires a pair of twisted-pair cables connected in a certain network topology, making installation extremely convenient and highly reliable. For control systems with different numbers of floors, only the corresponding number of call controllers need to be added to the CAN bus; the main controller hardware and software do not require any modifications, making the elevator control system installation more flexible and convenient. 2. Introduction to the Elevator Call Controller The elevator call controller is the call part of the elevator system. Functionally, the call controller includes three main parts: an elevator display unit, a call receiving unit, and a communication unit. (1) Display Unit: The elevator call display unit is the part of the human-machine interface between passengers and the elevator. Its function is to allow passengers waiting for the elevator at the elevator door area to know the current floor, the current direction of the elevator, and the current call status of the current floor. This system uses two 8-segment LEDs as floor displays and two LEDs with up and down arrows as elevator direction displays. The elevator call controller communicates with the main controller to obtain and display the current elevator status. (2) Call Receiving Unit: When passengers need to take the elevator, they need to use the two call buttons on the call panel on each floor to make a call to the elevator control system, sending an up call (a call to a place above the current floor) and a down call (a call to a place below the current floor). After receiving the call request, the elevator call controller processes it and sends it to the main controller through the communication unit. (3) Communication Unit: In traditional elevator control systems, communication between the call button and the main controller is point-to-point, i.e., direct I/O control. The main controller is directly connected to the call panel on each floor via 16 floor display lines, 2 direction display lines, and 2 call registration lines. As the number of elevator floors increases, the system wiring becomes extremely complex. Therefore, this system uses a CAN bus to complete the communication between the call button and the main controller, greatly simplifying the system structure. 3 System Hardware Design The elevator call controller uses a PIC18F258 microcontroller as its core, which has a built-in CAN transceiver interface. The peripheral circuit consists of a CAN driver module, an input module, a display module, DIP switches, up buttons, down buttons, and a debugging interface. As a node in the CAN bus network, the elevator call controller uses a CAN driver module as the interface between the call controller and the physical bus, providing differential transmission and reception functions for the CAN bus. The input module receives up calls, down calls, and door opening signals from the main controller. This information is processed according to the communication protocol, loaded into a mailbox, and then sent to the CAN bus. The display unit includes three parts: button light display, dot matrix display, and maintenance light display. The dot matrix display can also display the floor number and direction arrows in a scrolling effect. 3.1 CAN Driver Module CAN (Control Area Network) was first introduced by the German company BOSCH for data communication between measurement and actuation components inside automobiles. Its bus specification has now been standardized by the ISO international standards organization and is widely used in discrete control systems. The CAN protocol is also based on the Open Systems Interconnection (OSI) model of the international standards organization, but its model structure only has three layers: the physical layer, data link layer, and the application layer at the top of the OSI model. Its signal transmission medium is twisted pair cable. The communication rate can reach 1Mbps/40m, and the direct transmission distance can reach up to 10km/kbps. Up to 110 devices can be connected. CAN is a serial communication network that effectively supports distributed and real-time control, employing many new technologies and unique designs. Compared with general communication buses, CAN bus data communication has outstanding reliability, real-time performance, and flexibility. The CAN transceiver uses the PHILIPS PCA82C250, a widely used interface chip between the CAN controller and the physical bus, capable of differential transmission and reception of bus information. To improve the system's anti-interference capability, a high-speed optical isolator 6N137 is added between the PCA 82C250 and PIC18F258. To ensure the stability of the CAN bus, the CAN driver module is powered separately by a DC2405. 3.2 Display Unit The elevator call controller display unit includes keypad lights, floor indicator, direction arrows, and maintenance lights. Traditional elevators use seven-segment displays to show directional arrows and floor numbers. This system uses a 5×7 LED dot matrix display, which allows the arrows and floor numbers to scroll while the elevator is running. The PIC sends four 8-bit serial signals through the TX port, in the following order: arrow direction, tens digit floor number, units digit floor number, and row selection. The parallel output Q7 of the previous serial-to-parallel converter 74HC164 is connected to the serial input A of the next 74HC164, forming a cascade of four 74HC164s. The first arrow direction signal is transmitted to the last 74HC164. The outputs Q0-Q6 of the last three 74HC164s are connected to the column addresses A1-A7 of the three dot matrices, respectively. The Q0-Q4 of the first 74HC164 are connected to the row addresses B1-B5 of the three dot matrices through a unidirectional driver MC1413. The dot matrix display uses a scanning method, with one line output every 1ms in the software. Therefore, 5 lines only require 5ms, and the human eye will not perceive flickering. The column signal shifts one position every 50ms, thus producing a scrolling effect of arrows and floor numbers. When the elevator malfunctions, the microcontroller outputs a high level through the I/O port to illuminate the inspection light. The schematic diagram of the dot matrix display is shown in Figure 1. 3.3 Call Unit The elevator call controller also includes DIP switches, up buttons, down buttons, and a debugging interface. The DIP switches are used to set the floor number of the floor where the call controller is located. When the elevator goes up or down, the main controller compares the current floor number of the elevator with the floor number the passenger expects to reach. If they are the same, the elevator stops running; if they are different, it continues to go up or down, and the arrow scrolls up or down. The up and down buttons are for passengers to make calls. After receiving the call request, the call controller processes it and sends it to the main controller through the communication section. The debugging interface is used to download programs or perform simulation debugging. The simulator used is the ICD2 from Beineng Company. Figure 1. Hardware schematic diagram of LED dot matrix display screen. 4. System software design. 4.1 CAN communication software design. In this system, the CAN module operates in configuration mode and normal operation mode. First, in configuration mode, the control and status register, baud rate control register, I/O control register, interrupt flag and control register, receive mask register, and receive filter register are set according to system requirements to ensure smooth CAN bus operation. This register can only be set in configuration mode. After setting, the system enters normal operation mode. Both the host computer and the slave computer enable their respective CAN receive interrupts and wait for data transmitted from the CAN bus. When sending elevator call information, bit 16 of the CAN module sets the CAN transmission format, data frame, and bit data; bit 17 stores the floor number as the ID number; bit 18 is set to 0; bits 19 and 20 store uplink information. If there is uplink information, two bytes FFFFH are sent; otherwise, 0000H is sent; bits 21 and 22 store downlink information. The CAN module data transmission flowchart is shown in Figure 2. 4.2 The main program design software needs to implement the initialization settings of the DIP switches, the initialization settings of the CAN bus, reading the main control response and receiving information from the CAN bus, processing the key call subroutine, CAN transmission, and dot matrix display. The main program flowchart is shown in Figure 3. Figure 2 CAN module data transmission flowchart Figure 3 Main program flowchart 5 Conclusion This paper designs an elevator call controller with a CAN communication interface based on the PIC18F258. After nearly a year of field use, it shows that the controller has good functional characteristics and extremely high reliability, strong anti-interference ability, and a high performance-price ratio. The system structure is simple and easy to install, which is the future trend of elevator control system development. It has now been successfully put into mass production.