Implementation of the LECOM protocol in Lenz DC speed controllers
2026-04-06 07:21:11··#1
1. Introduction In designing an automatic control system for a certain project, it was necessary to monitor multiple Lenze 4900 DC speed controllers (hereinafter referred to as Lenze 4900) in real time. Lenze DC speed controllers offer various communication methods, and by connecting different communication modules, they can implement various communication protocols such as PROFIBUS, CAN, Interbus, and LECOM. This particular DC speed controller uses the LECOM serial communication protocol, which is mainly used for master-slave communication between multiple Lenze DC speed controllers and a master station. While searching for relevant information on the LECOM protocol, the author gained significant inspiration from the article "Implementation of LECOM Communication for Lenze Frequency Converters" in the December 2002 issue of the *Electrical Drive Automation* magazine (Vol. 24, No. 6). This article mainly introduces the implementation method of communication between Lenze frequency converters and a host computer via the LECOM protocol. While the hardware implementation of Lenze DC speed controllers communicating with a host computer via the LECOM protocol is similar to that of Lenze frequency converters, the communication protocols differ somewhat. The following details the system composition of this automatic control system, the communication protocol and design concept of the Lenze DC speed controller using LECOM, and the implementation method of LECOM communication in this control system. 2. Control System Composition and Communication Protocol In this automatic control system, the parameters and data of six Lenze 4900 units are required to be read into the PLC via the CP440 communication module for interlocking control. Figure 1 shows a schematic diagram of the specific network structure. [align=center] Figure 1 Network structure diagram[/align] The Lenze 4900 and the PLC communicate using the Lecom protocol. The two parties communicate at a communication rate of 9600bps. The following is a brief introduction to the CP440 module, Lenze 4900 and Lecom communication protocol: 2.1 CP440 module (1) CP440 communication processor The CP440 communication processor is a low-cost serial communication solution provided by Siemens. It can be used in Simatic S7-400. This communication module provides three different forms of transmission interface: ● RS-232C (V.24); ● 20MA (tty); ● RS-422/RS-485 (X.27). (2) CP440 parameter settings This module can implement three communication protocols: ASCII code, 3964(r) and printer driver. It can be easily parameterized by the parameterization tool integrated in STEP 7. Its settings mainly include communication mode (baud rate, data bits, stop bits and parity), receive frame end mode, interface mode (485 or 422), etc. In this design, the ASCII code communication protocol is used to implement the Lecom protocol. The parameters of CP440 in this design are set as follows: ● Receive frame end mode: receive a fixed 36 bytes of data; ● Communication mode: baud rate 9600, 1 start bit, 8 data bits, 1 stop bit, 1 parity bit (even parity); ● Interface mode: RS-485, the rest are set to default mode. 2.2 Lecom communication protocol (1) Introduction to the principle of Lecom communication protocol and its hardware structure. The Lecom protocol is an ASCII code serial communication protocol used by Lenze 4900 series DC speed control devices for communication. The Lenz DC speed control device is equipped with an external module 2102ib, which is plugged into the xi port of the DC speed control device. This module provides an RS-485 interface. Multiple DC speed control devices and the master station are connected as shown in Figure 2 to form a lecom communication network. The maximum number of DC speed control devices in the network can reach 31. [align=center] Figure 2 Schematic diagram of lecom network connection[/align] Each DC speed control device on the network must correctly set the communication-related parameters. For example, each DC speed control device must use the same baud rate and different station addresses. The DC speed control device parameter c009 is used to set the station address, and the parameter c125 is used to set the baud rate. lecom communication protocol frame structure. In the lecom protocol, the communication commands are mainly divided into two parts: read data command and write data command. (2) Data frame structure for reading DC speed control device parameters. When reading data from a DC speed control device, the data frame format transmitted from the master station to the DC speed control device is shown in Table 1: Table 1 Data Frame Format for Master Station Sending Read Parameter Commands to DC Speed Control Device In Table 1: ● eot is a control character, indicating the end of the previous data frame transmission and the start of the new data frame transmission; ● ad1 and ad2 are the slave station (DC speed control device) addresses represented by ASCII codes. For example, if the master station sends data to the DC speed control device with address 2, then: ad1 = "0" = 30h, ad2 = "2" = 32h ● ch1 and ch2 are the DC speed control device parameter codes represented by ASCII codes. For example, if the master station wants to read parameter code c11, then: ch1 = "1" = 31h, ch2 = "1" = 31h; if the master station wants to read parameter code c111, then: ch1 = "11" = 3bh, ch2 = "1" = 31h; ● enq is a control character, indicating a request for slave station data. (3) Data frame structure in response to the master station. When the corresponding slave station DC speed control device receives the master station's parameter read command as shown in Table 1, if the slave station can recognize the received data, it will respond to the master station with a data frame as shown in Table 2. Table 2 Data frame format in response when the slave station can recognize the received data. If the slave station cannot recognize the received data (checksum error), it will respond to the master station with a data frame format as shown in Table 3. Table 3 Data frame format in response when the slave station cannot recognize the received data. If the accessed parameter code does not exist, the slave station will respond to the master station with a data frame as shown in Table 4. Table 4 Data frame format of slave station response when the parameter code accessed by the master station does not exist. The specific meanings of the characters in Tables 2, 3, and 4 are as follows: ● stx is a control character, indicating the start of the transmitted text; ● etx is an extension character, indicating the end of the transmitted text; ● v1…vn is a parameter value represented by n ASCII characters; ● bcc is a block check character, and its calculation method is: bcc = (ch1)xor(ch2)xor(stx)xor……xor(etx) (4) Writing DC speed control device data When writing DC speed control device data, the data frame format sent by the master station to the slave station DC speed control device is shown in Table 5. When the slave station receives the data shown in Table 5, if the verification is correct, it responds to the master station with the control character ack; if the verification fails, it responds to the master station with the control character nak. Table 5. Data Frame Format of Write Parameter Command Sent by Master Station to DC Speed Regulator 3. Software Implementation To communicate with other devices via the CP440 communication module using the LECOM protocol, the design of the PLC program is a crucial step. As can be seen from the LECOM protocol communication frame format above, implementing the LECOM protocol using the CP440 module requires constructing the LECOM protocol information frame structure using the PLC program. Combining the CP440 hardware and software functional blocks, and following a modular programming approach, we can design communication subroutines, a program for the PLC master station to read DC speed regulator parameters, a program for the PLC master station to write DC speed regulator parameters, and a program for the PLC master station to receive parameters returned by the DC speed regulator. 3.1 Design of the Subroutine for the PLC Master Station to Read DC Speed Regulator Parameters Considering that the PLC needs to communicate with six 4900 devices, the PLC master station uses a polling method to access each device. The CP440, acting as the LECOM master station, sends master station commands to all slave devices every 50ms, reading the operating status signals and control signals of the slave DC speed regulators. The data transmission subroutine needs to convert the data to be transmitted into ASCII code, add control characters (eot, stx, etx), and calculate the block check character to form a complete data transmission frame. Then, it calls the standard data transmission function block of the CP440 module to send the data to the slave station. The data reception subroutine calls the standard data reception function block of the CP440 module to convert the received data (ASCII characters) into the required data. 3.2 Subroutine Design for Writing DC Speed Control Device Parameters to the PLC Master Station This subroutine is designed similarly to the previous one, except for the difference in constructing the data transmission protocol frame structure. It is controlled by the PLC master program and calls this subroutine to control the DC speed control device under specific control interlocking logic. 4 Conclusion Since the operation of this communication system, the communication between the CP440 and Lenze 4900 has been normal, without any software or hardware failures or other interference, effectively ensuring the normal operation of the automatic control system. Therefore, using the serial communication module CP440 and Lenze 4900 to communicate via the Lecom protocol is an effective method. Most of Lenz's DC speed controllers and frequency converters support the Lecom communication protocol. While there are some differences in the frame structure and hardware implementation of the communication protocol across different product series, the overall hardware and software protocols follow certain rules. Because documentation on the Lecom communication protocol specification is very difficult to find, this article aims to provide some reference and assistance to colleagues engaged in the design and development of drive control systems in implementing Lecom communication protocols.