Servo drives are fundamental components of servo systems and are widely used in various electric drive automatic control systems, such as CNC machine tools, flexible manufacturing systems, robot drives, artillery servo systems, radar control, ship propulsion, vehicle drives, printing equipment, textile equipment, and sewing equipment. Real-time reading and modification of various control parameters to achieve real-time control is a basic requirement of servo systems. This article focuses on the Bosch Rexroth IndraDrive servo drive, using the flexible and easy-to-use VB 6.0 programming language and the RS232 serial communication interface built into the IndraDrive to achieve serial communication between a host PC and the servo drive, enabling real-time control of various internal control parameters of the servo drive. The IndraDrive uses the SIS communication protocol, a binary communication protocol with a complete message format and return checksum format. The SIS protocol communication format is unified across various Bosch Rexroth products (PLCs, servo drives, etc.). The SIS protocol uses the following data format: 1 start bit, 8 data bits, 1 or 2 stop bits, and no parity bit; the baud rate for data transmission is 115200 bps. The SIS protocol uses hexadecimal data format to represent various instruction codes and data. Its software communication instructions have been optimized to only two: one for reading and one for writing, making the upper-level software development very convenient. The message format of the SIS protocol is shown in the attached table. The attached table shows the message format of the SIS protocol. The header consists of 8 bytes, with the following meanings: First byte stz: start bit, default is 0x02; Second byte cs: used for checksum data, its value is the sum of all numbers except this byte, XORed with the lower 8 bits, then incremented by 1; Third byte datl: length of all data excluding the header (number of bytes); Fourth byte datlw: repeats the content of the third byte; Fifth byte cntrl: determines the error return type, default is 0x00; Sixth byte service: service type (0x80 for read parameters, 0x8f for write parameters); Seventh byte adrs: driver address; Eighth byte adre: driver address. The user data header contains 5 bytes, with the following meanings: The first byte, control byte: the operation parameter value, defaulting to 0x3c; the second byte, device address (unit address): the drive address; the third byte, parameter type: the parameter type, with a value of 0x00 for the drive; the fourth and fifth bytes, parameter number: the parameter number. For drive S-parameters, write the hexadecimal value of the parameter number directly; for P-parameters, write the hexadecimal value of "2^15 + parameter number". The length of the user data depends on the data type of the operation parameter. For example, if the operation parameter is of type int, write 2 bytes; if it is of type dword, write 4 bytes. When writing, note that the least significant byte comes first, followed by the most significant byte. In VB implementations, serial communication between a PC and an IndraDrive is often achieved using a master-slave query-response method. The PC always has initial transmission priority, and all communication is initiated by the PC. Each communication is initiated by the PC sending a (read/write parameter) command. Upon receiving the command from the PC, IndraDrive first checks the start flag in the command, then checks if the drive address in the command matches its own drive address. If they don't match, it means the computer is communicating with another drive, and the command is ignored; if they match, the command is executed, and the result is sent back to the PC, ending one communication cycle. VB's control toolbox provides a very convenient serial communication control, MSComm, which comprehensively provides all the details for developing higher-level serial communication. Serial communication can be implemented using either interrupt or polling methods. The MSComm control provides the onComm event for implementing serial port interrupt functionality. This event is unique and can intercept any message from the serial port. When a serial port event or error occurs, the VB program automatically jumps to the onComm event handler. The `commevent` property stores the numerical code of the most recent event or error on the serial port. The `commevent` property value can be read at any time in the program to understand the communication status. The `oncomm` event is closely related to and used together with the `commevent` property; when any `oncomm` event or error occurs, the `commevent` property value will change. During the `oncomm` event handling, the `commevent` property value can be checked, and different event handling procedures can be initiated for different property values. According to the SIS communication protocol, VB programs mainly operate on the `mscomm` control, primarily involving the initialization of the `mscomm` control and the handling of `oncomm` events. The main initialization code of the mscomm control is as follows: mscomm_com1.commport = 1 'Set the serial port to be used mscomm_com1.settings = “115200,n,8,1” 'Set the baud rate and parity method for transmission mscomm_com1.portopen = true 'Open the communication serial port mscomm_com1.rthreshold = 1 'Set the character input threshold of the input buffer The main code of the oncomm event handler is as follows: private sub mscomm_com1_oncomm() dim input_buffer as variant dim upper_limit as integer dim input_to_hex as string dim i as integer input_buffer = mscomm_com1.input 'Copy characters from the receive buffer upper_limit = ubound(input_buffer) 'Count the number of data received for i = 0 to upper_limit input_to_hex = hex(input_buffer(i)) 'Convert the received data to hexadecimal if len(input_to_hex) < 2 then 'Pad leading zeros for hexadecimal values ​​less than two digits input_to_hex = "0" & ​​input_to_hex end if if i = 0 then 'Clear the display text box txtreceivedata.text = "" end if txtreceivedata.text = txtreceivedata.text & input_to_hex & " " 'Display the received content next end sub Read/Write Command Examples and Precautions With the above foundation, we can read and write the internal parameters of IndraDrive in real time according to the data format of the SIS protocol. For example, to read the position feedback value parameter s-0-0051, first convert the parameter number 51 to the hexadecimal number 33, that is, write 33 00 in the fourth and fifth bytes of the user data header respectively (note: high byte last, low byte first); other bytes can be derived successively. Since it is reading the parameter value, there is no need to write user data; therefore, the sent content should be: 02 02 05 05 00 80 01 01 3c 01 00 33 00. If communication is normal, you will receive byte content similar to: 02 20 07 07 10 80 01 01 00 3c 01 4e ac 07 00, where the last 4 bytes are the position feedback value (note: high byte last, low byte first), which should be 7ac4e in hexadecimal, and 502862 in decimal. The actual position value should be 50.2862 (the position value resolution is 0.0001). The difference between writing and reading parameters is that user data is used; that is, the value to be written is written to the user data location. To write 100.0000 into the maximum travel value parameter s-0-0278, first convert the parameter number 278 to hexadecimal 116, which is written as 16 11 in the fourth and fifth bytes of the user data header. Then convert 1000000 (note that it is not 100.0000) to hexadecimal f4240, which is written as 40 42 0f 00 in the four bytes of the user data header. The other bytes can be derived sequentially. The sent content should be: 02 76 09 09 00 8f 01 01 3c 01 00 16 01 40 42 0f 00. If the communication is normal, it will receive: 02 1a 03 03 10 8f 01 01 00 3c 01, indicating that the parameter rewriting was successful. It is worth noting that, in addition to following the SIS protocol in terms of data format, the following points should also be noted during operation: The communication baud rate should be 115200 bps. When writing parameters, indradrive should first be put into pm (parameter mode). By setting bit1 and bit0 of parameter s-0-0420 (activate parameter mode), indradrive can be switched to pm; when rewriting parameter s-0-0420, it is not necessary to be in pm; after setting bit1 and bit0 of s-0-0420, do not forget to reset it, so that you can enter pm and rewrite parameters at will. After configuring the parameters, you should exit pm and enter om (operation mode), which is done by parameter s-0-0422 (exit parameter mode). The configuration process is similar to s-0-0420. (3) When reading parameters, indradrive can be read regardless of whether it is in pm or om, without restriction. (4) When reading parameters, the content after the 11th byte of the received content is user data; while when writing parameters, the received content does not contain user data. As long as the communication is normal, the same content 02 1a 03 03 10 8f 01 01 00 3c 01 will be received. (5) If IndraWorks is being used to debug IndraDrive on the host computer, IndraWorks should be taken offline when reading and writing parameters, otherwise a message will be displayed indicating that the serial port is occupied. Conclusion The serial communication method described in this paper has been successfully applied to the experiment of debugging Bosch Rexroth IndraDrive servo driver. It is flexible and convenient, and meets the requirement of real-time modification of driver parameters. With appropriate improvements, it can be applied to the host computer monitoring of subway platform screen door system, safety door system and automatic door system, and has good practical value and scalability.