Polling method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application are applicable to the technical field of computer technology, and provide a polling method and device, electronic equipment and storage medium. The method comprises: encapsulating control instructions with continuous register addresses and same function codes into the same request message according to a message configuration list corresponding to a slave machine, to generate a plurality of request messages corresponding to the slave machine; the message configuration list records a register address corresponding to each control instruction in the slave machine; in response to a polling instruction, each request message is sent to the slave machine in turn based on a sending time of each request message; the sending time is after a receipt message returned by the slave machine based on a previous request message is read, and the next request message is sent to the slave machine. The polling speed of the polling master machine can be improved by the method provided in the embodiments.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a polling method, apparatus, electronic device, and storage medium. Background Technology

[0002] The Modbus protocol is a commonly used serial communication protocol in industrial applications. Using the Modbus protocol, a polling master can sequentially send multiple request messages to a slave device and read the contents stored in the slave's registers based on the acknowledgment messages returned. In existing technology, after sending a request message to a slave, the polling master can read the acknowledgment message after a uniform waiting time. If the slave does not return a correct acknowledgment message after the waiting time, the polling master can directly abandon reading and send the next request message to the slave. Because existing technology does not set appropriate waiting times for each request message, excessively long waiting times are prone to occur. Furthermore, due to the lack of an auxiliary request message generation scheme in existing technology, the polling master typically uses one control command to generate one request message for polling, resulting in the polling master often failing to maximize the utilization of request message resources, leading to resource waste.

[0003] Because existing technologies have problems such as unreasonable waiting time design when the polling host reads the receipt message and unreasonable request messages generated by the polling host, the existing Modbus polling schemes cannot approach the polling time limit that the polling host can achieve, resulting in a slow polling speed. Summary of the Invention

[0004] In view of this, embodiments of this application provide a polling method, apparatus, electronic device, and storage medium to improve the polling speed of a polling host.

[0005] A first aspect of this application provides a polling method, including:

[0006] According to the message configuration list corresponding to the slave device, control instructions with consecutive register addresses and the same function code are encapsulated into the same request message to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device;

[0007] In response to the polling command, each request message is sent to the slave device in sequence based on the sending timing of each request message; the sending timing is to send the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message.

[0008] A second aspect of this application provides a polling apparatus, including:

[0009] The request message generation module is used to encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, so as to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device;

[0010] The polling module is used to respond to the polling command and send each of the request messages to the slave device in sequence based on the sending timing of each request message; the sending timing is to send the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message.

[0011] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the polling method as described in the first aspect above.

[0012] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the polling method described in the first aspect above.

[0013] A fifth aspect of this application provides a computer program product that, when run on a computer, causes the computer to execute the polling method described in the first aspect.

[0014] Compared with the prior art, the embodiments of this application have the following advantages:

[0015] In this embodiment, the polling host can encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, thereby generating multiple request messages corresponding to the slave device. In response to the polling instruction, the polling host can sequentially send each request message to the slave device based on the sending timing corresponding to each request message. The (N+1)th sending timing is when the polling host sends the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message. N is a positive integer greater than or equal to 1. Through the method provided in this embodiment, the polling host can continuously read the contents of multiple registers of the slave device through a single request message when performing polling operations, thus significantly improving the polling speed of the polling host. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of a polling method provided in an embodiment of this application;

[0018] Figure 2 This is a schematic diagram of a message configuration list provided in an embodiment of this application;

[0019] Figure 3 This is a flowchart illustrating a specific implementation of a polling method S102 provided in an embodiment of this application.

[0020] Figure 4 This is a flowchart illustrating a specific implementation of a polling method S1022 provided in an embodiment of this application.

[0021] Figure 5 This is a schematic diagram of a receipt message provided in an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of the execution flow of a polling operation provided in an embodiment of this application;

[0023] Figure 7 This is a flowchart illustrating a specific implementation of a polling method S102 provided in an embodiment of this application.

[0024] Figure 8 This is a schematic diagram of an experience waiting time generation process provided in an embodiment of this application;

[0025] Figure 9 This is a flowchart illustrating a specific implementation of a polling method S101 provided in an embodiment of this application.

[0026] Figure 10 This is a flowchart illustrating a specific implementation of a polling method S1013 provided in an embodiment of this application.

[0027] Figure 11 This is a schematic diagram of a process for generating a request message provided in an embodiment of this application;

[0028] Figure 12 This is a flowchart illustrating a specific implementation of a polling method S1002 provided in an embodiment of this application.

[0029] Figure 13 This is a schematic diagram of a process for generating a request message provided in an embodiment of this application;

[0030] Figure 14 This is a flowchart illustrating a specific implementation of a polling method S1002 provided in an embodiment of this application.

[0031] Figure 15 This is a schematic diagram of a polling device provided in an embodiment of this application;

[0032] Figure 16 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0034] First, the terms that may be involved in the embodiments of this application will be explained here.

[0035] Modbus: The Modbus protocol is a universal language used in electronic controllers. Due to its high availability, Modbus allows controllers to communicate not only with each other but also with other devices via networks (such as Ethernet). Therefore, Modbus has become a universal industry standard. Through Modbus, control devices from different manufacturers can be connected into an industrial network for centralized monitoring.

[0036] Bus: A computer consists of multiple electronic components, such as the CPU (Central Processing Unit), memory, and hard drive. These components often need to exchange data. The common channel for data transmission is called the bus. In the field of hardware communication, bus often refers to the common channel for data transmission.

[0037] Half-duplex: Data can be transmitted in both directions on a single signal carrier, but not simultaneously. That is, only one device can be sending a message on the bus at any given time.

[0038] Polling: Polling refers to iterating through each element of a set according to a certain algorithm, repeating the process cyclically. From the Modbus master's perspective, polling means repeatedly reading the contents of the registers on each slave device one by one.

[0039] Polling host: also known as master station, is the device that sends a request register content message during the polling process.

[0040] Slave device: also known as slave station, is a device that responds to messages from the host.

[0041] Request message: A message sent by the master when polling the slave to read register information; it is essentially a byte array.

[0042] Acknowledgment message: A message containing register contents returned by the slave device in response to a request message sent by the master device during polling. It is essentially a byte array.

[0043] With the widespread use of the Modbus protocol globally, Modbus polling hosts (also known as Modbus polling masters) have become indispensable tools in industrial applications for reading Modbus slave data. Modbus polling hosts can use various programming languages ​​to send request messages to slave devices via serial communication, receive and parse reply messages. However, current Modbus polling hosts suffer from slow read speeds and long cycles when reading slave register contents. Furthermore, existing Modbus polling hosts lack the functionality to assist users in designing request messages.

[0044] Existing polling hosts suffer from excessively long polling cycles, which can cause application platforms to fail to update the collected values ​​corresponding to the register contents in a timely manner. This application aims to improve the polling speed of the polling host through three strategies, thereby solving the problem of excessively long polling cycles.

[0045] First, message design strategy. Through the message design scheme, the polling master can intelligently generate request messages that can continuously read multiple registers based on the message configuration list corresponding to the slave.

[0046] Second, the reading strategy. It proposes determining the experience waiting time corresponding to each request message, and enabling the polling host to read the receipt message based on the experience waiting time corresponding to each request message.

[0047] Third, the supplementary reading strategy. The supplementary reading strategy ensures that the polling host reads the complete receipt message.

[0048] The method provided in this application embodiment can automatically achieve the optimal response state of the slave device on a certain bus by polling the host, and bring the polling time close to the limit.

[0049] The technical solution of this application will be described below through specific embodiments.

[0050] Reference Figure 1This diagram illustrates a polling method provided in an embodiment of this application. This polling method can be applied to a polling host. The polling host can be any type of electronic device. Specifically, the electronic device can be a computer, mainframe computer, tablet computer, or other electronic device capable of executing polling instructions. The polling method can include the following steps:

[0051] S101. According to the message configuration list corresponding to the slave device, control instructions with consecutive register addresses and the same function code are encapsulated into the same request message to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device.

[0052] In this embodiment, when a user needs to perform polling operations on multiple slave devices in an industrial network through a polling host, a polling scheme can be configured on the polling host first. When configuring the polling scheme, the user can transmit the message configuration list corresponding to the slave devices to the polling host. After receiving the message configuration list, the polling host can store it. The message configuration list can record the register address of each control instruction in the slave device and the function code of the register corresponding to each control instruction. The register address can be used to represent the register corresponding to the control instruction. The polling host can determine the register corresponding to each control instruction in the slave device based on the register address. The polling host can obtain the value in the register based on the function code corresponding to the register. In response to the user's generation command, the polling host can encapsulate control instructions with consecutive register addresses and the same function code in the message configuration list corresponding to the slave devices into the same request message.

[0053] See Figure 2 This diagram illustrates a message configuration list provided in an embodiment of this application. Figure 2 As shown, the message configuration list can contain multiple control commands. Each control command can include its register address in the slave device, the applicable function code, the content executed by the corresponding register, and the meaning of each parameter. It should be noted that the method provided in this application can be applied to all Modbus protocol polling hosts, such as polling hosts that poll using Modbus RTU messages and those that poll using Modbus ASCII messages. This application does not limit the message type of the request messages generated by the polling host. Figure 2In this context, device I / O refers to the input / output device model (I / O for short). MCU parameters refer to the microcontroller unit (MCU) parameters. PT100 refers to a platinum resistance thermometer, whose resistance is 100 ohms at 0 degrees Celsius. BCD code refers to Binary-Coded Decimal (BCD) number.

[0054] In one possible implementation, when multiple slave devices exist in an industrial network, a single polling master can be used to poll all slave devices. In this case, after generating a request message based on the message configuration list, the polling master can also add a slave tag corresponding to the slave device in the generated request message. After generating the request message, the polling master can write the generated request message to a database for storage.

[0055] S102. In response to the polling instruction, based on the sending timing of each request message, each request message is sent to the slave device in sequence; the (N+1)th sending timing is after reading the acknowledgment message returned by the slave device based on the previous request message, the next request message is sent to the slave device; N is a positive integer greater than or equal to 1.

[0056] In this embodiment, when a user needs to obtain information from a slave device, they can initiate a polling command to the polling master. The polling master, in response to the polling command, sequentially sends each request message to the slave device based on the timing of its transmission, in order to request the contents of each register in the slave device. Specifically, for the first request message, the polling master can send it directly to the corresponding slave device after receiving the polling command and generating the request message; that is, the first request message is sent upon receiving the polling command. Subsequent request messages can be sent based on a preset timing: specifically, the polling master sends the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message.

[0057] In one possible implementation, the request messages generated by the polling master may include a request address. After generating multiple request messages corresponding to the slave devices, the polling master can determine the request order of each request message based on its corresponding request address. The polling master can store each request message and its corresponding request order in a message list. Alternatively, the polling master can store the message list in a database. When the polling master needs to perform a polling operation, it can retrieve each request message from the message list sequentially according to the request order and send each request message to its corresponding slave device in that order.

[0058] Specifically, in one possible implementation, after receiving a polling command initiated by the user, the polling host can sequentially retrieve all request messages corresponding to the slave devices from the message list according to the request order of each request message. The polling host can first retrieve the request message with the first request order from the message list and send it to the slave device through a pre-defined communication link. Upon receiving the first request message, the slave device can generate a receipt message based on it and return it to the polling host. After reading the receipt message returned by the slave device based on the first request message, the polling host can retrieve the request message with the second request order from the message list and send it to the slave device. During the polling operation, the polling host can send the next request message to the slave device according to the request order after each receipt message returned by the slave device based on the previous request message, until all request messages in the request list have been sent. When the polling master sends the last request message in the request list to the slave and reads the acknowledgment message returned by the slave based on the last request message, the polling master can determine that the current polling operation has been completed, that is, the polling master has completed the polling operation of one polling cycle.

[0059] In one possible implementation, when multiple slave devices exist in the industrial network, the user-configured polling scheme can further include a polling order for each slave device. The polling master can sequentially send request messages to each slave device according to the polling order. Specifically, after sending all request messages for the first slave device (i.e., after polling the first slave device), the polling master can determine the second slave device according to the polling order in the polling scheme. The first slave device can be any slave device in the industrial network, and the second slave device can be the slave device in the next polling order after the first slave device. Then, the polling master can retrieve all request messages for the second slave device from the database based on the slave device tag. The polling slave device can send request messages based on the timing of each request message. The polling master can sequentially send request messages to each slave device in the industrial network until all request messages for all slave devices in the industrial network have been sent.

[0060] In this embodiment, since the polling master can encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, the polling master can continuously read the contents of multiple registers of the slave device through a single request message when performing polling operations, thus significantly improving the polling speed of the polling master. In actual operation, when the polling master continuously reads the contents of multiple registers in the slave device through a single request message, the response time required for the slave device to return an acknowledgment message based on the currently received request message is much shorter than the response time required to read the same number of registers through multiple request messages. For example, experiments show that when the polling master reads the contents of one register in the slave device through a single request message, the response time required for the slave device to return an acknowledgment message based on the currently received request message is approximately 50 milliseconds. Therefore, when the polling master sequentially reads the contents of five registers in the slave device through five request messages, the total response time required for the slave device to return five acknowledgment messages based on the five request messages is approximately 250 milliseconds. However, when the polling master continuously reads the contents of five registers in the slave device through a request message, the response time required for the slave device to return an acknowledgment message based on the currently received request message is about 60 milliseconds.

[0061] Figure 3 A flowchart illustrating a specific implementation of a polling method S102 provided in the second embodiment of this application is shown. See also Figure 3 Compared to Figure 3 In the embodiment provided, S102 of the polling method includes: S1021 to S1022, which are detailed below:

[0062] S1021. Send the first request message to the slave device based on the timing of sending the first request message.

[0063] In this embodiment, after the polling master generates all request messages corresponding to the slave devices, it can respond to the polling command initiated by the user, retrieve all request messages corresponding to the slave devices from the database, and send each request message to the slave device in sequence. The polling master can send the first request message to the slave device based on the sending timing corresponding to the first request message. In this embodiment, there is no restriction on the order of requests corresponding to the first request message; the first request message can be any request message from all request messages corresponding to the slave device.

[0064] In this embodiment, the first request message can be any request message that includes an experienced waiting time. Specifically, when the first request message is the first request message sent by the polling master in the current polling cycle, that is, when the polling master has not sent a request message in the current polling cycle and the sending timing is the first sending timing, the polling master can directly send the first request message to the slave. When the first request message is the (N+1)th request message sent by the polling master in the current polling cycle, that is, when the sending timing is the (N+1)th sending timing, the polling master can send the first request message to the slave after reading the acknowledgment message returned by the slave based on the previous request message.

[0065] S1022. Based on the experience waiting time, read the receipt message returned by the slave device based on the first request message.

[0066] In this embodiment, after the polling master sends a first request message containing the experience waiting time to the slave, it can read the acknowledgment message returned by the slave based on the first request message based on the experience waiting time.

[0067] In one possible implementation, after the polling master retrieves any request message from the database, it can determine whether the current request message contains an experienced wait time. If the current request message contains an experienced wait time, the polling master can determine that the current request message is the first request message. After sending the current first request message to the slave, the polling master can wait according to the experienced wait time in the first request message, and after the wait is completed, read the acknowledgment message returned by the slave based on the first request message. If the current request message does not contain an experienced wait time, the polling master can determine that the current request message is the second request message.

[0068] In this embodiment, the polling host can wait based on the experienced waiting time corresponding to each first request message, and then read the acknowledgment message returned by the slave after the waiting period. Therefore, the method provided in this embodiment allows the polling host to accurately read the acknowledgment message without wasting excessive waiting time, thereby further reducing the time required by the polling host in a polling cycle.

[0069] Figure 4 A flowchart illustrating a specific implementation of a polling method S1022 provided in the third embodiment of this application is shown. See also... Figure 4 Compared to Figure 3 In the embodiment provided, S1022 of the polling method includes: S401 to S403, which are detailed below:

[0070] S401. Read the real-time data returned by the slave device during the experience waiting time.

[0071] In this embodiment, after sending a first request message containing an experienced waiting time to the slave device, the polling master can wait according to the experienced waiting time and read the real-time data returned by the slave device from the serial port preset by the user during the experienced waiting time. The complete receipt message returned by the slave device based on the first request message may contain multiple data segments. When the slave device generates a receipt message in response to the first request message, it can return each data segment to the polling master device sequentially according to the order in which the data segments were returned.

[0072] In one possible implementation, see Figure 5 The diagram illustrates a receipt message provided in an embodiment of this application. Figure 5 As shown, the data segments in the receipt message, from front to back according to the return order, are: slave address, function code, number of bytes, receipt data segment, and receipt check segment. The slave address is the header of the receipt message, and the receipt check segment is the tail. After receiving the first request message from the polling master, the slave can generate and return the receipt message to the polling master starting from the header. The slave can generate and return each data segment sequentially until the tail of the receipt message is generated, and then return the tail to the polling master. At this point, the complete receipt message corresponding to the first request message is generated. Since the response time required for the slave to generate a complete receipt message may vary depending on the environment, such as when the ambient temperature is high, the response time for the slave to respond to the same request message will be longer than when the temperature is low. Therefore, the real-time data read by the polling master from the serial port based on experience and waiting time may not be a complete receipt message.

[0073] Therefore, in one possible implementation, after the polling host reads the real-time data, it can determine whether the real-time data contains the first data segment by checking the number of bytes in the real-time data. Since the number of bytes corresponding to the slave address, function code, and byte count in the receipt message is fixed, and the sum of the byte counts of these three data segments is 3 bytes, the polling host can calculate the number of bytes corresponding to the real-time data and determine whether the number of bytes in the real-time data is greater than or equal to 3 bytes. The polling host can determine whether the real-time data contains the first data segment by checking whether the number of bytes in the real-time data is greater than or equal to 3 bytes. If the polling host determines that the read real-time data is less than 3 bytes, then the polling host can determine that the currently read real-time data does not contain the content of the receipt data segment. At this time, the polling host can delete the read real-time data and set the message status corresponding to the first request message to the error status of the previous receipt message.

[0074] S402. If the real-time data contains a first data segment, then the first expected number of bytes corresponding to the first receipt message is determined based on the number of bytes in the first data segment.

[0075] In this embodiment, after reading real-time data, if the polling host determines that the read real-time data contains a first data segment, the polling host can calculate the number of bytes in the first data segment in the real-time data, and determine the first expected number of bytes corresponding to the real-time data based on the number of bytes in the first data segment.

[0076] In one possible implementation, after calculating the number of bytes of real-time data, if the polling host determines that the real-time data it has read is greater than or equal to 3 bytes, then the polling host can determine that the real-time data currently read contains the content of the acknowledgment data segment.

[0077] In one possible implementation, such as Figure 5 As shown, the receipt message returned by the slave device can contain multiple data segments. Each data segment can be the slave address, function code, number of bytes, receipt data segment, and receipt check segment. Since the slave address, function code, number of bytes, and receipt check segment typically occupy 5 bytes in the receipt message, the first expected number of bytes corresponding to the real-time data can be equal to the number of bytes in the first data segment of the real-time data plus 5.

[0078] S403. If the actual number of bytes of the real-time data is less than the first expected number of bytes, then the real-time data returned by the slave device is read based on a preset interval waiting time, and the repeated reading count corresponding to the first request message is updated until the real-time data meets a preset message stop condition or the repeated reading count meets a preset reading stop condition; the message stop condition is that the actual number of bytes of the real-time data is greater than or equal to the second expected number of bytes; the reading stop condition is that the repeated reading count is greater than or equal to a preset repeated reading threshold.

[0079] In this embodiment, after obtaining the first expected number of bytes corresponding to the real-time data, the polling host can calculate the actual number of bytes of the real-time data based on the received real-time data. After determining the actual number of bytes of the real-time data, the polling host can determine whether the actual number of bytes of the real-time data is less than the first expected number of bytes corresponding to the real-time data. Since the slave device generates and returns each data segment sequentially according to the return order of each data segment, if the polling host determines that the actual number of bytes of the real-time data is less than the first expected number of bytes corresponding to the real-time data, the polling host can determine that the real-time data read at this time is not a complete receipt message, that is, the slave device failed to generate and return a complete receipt message within the experienced waiting time. At this time, the polling host can wait according to the user-preset interval waiting time and read multiple real-time data returned by the slave device at intervals. While reading multiple real-time data returned by the slave device at intervals, the polling host can also increase the number of repeated reads corresponding to the first request message. The polling master can repeatedly read real-time data returned by the slave device from a user-predefined serial port until the real-time data read by the polling master meets the user-predefined message stop condition, or the number of repeated reads recorded by the polling master meets the user-predefined read stop condition. The message stop condition is that the actual number of bytes in the real-time data is greater than or equal to the second expected number of bytes. The read stop condition is that the number of repeated reads is greater than or equal to a preset repeated read threshold.

[0080] In one possible implementation, after each interval of real-time data read, the polling host can calculate the second expected byte count corresponding to the currently read real-time data based on the byte count of the first data segment in the real-time data. This second expected byte count is the expected byte count for each time the polling host reads real-time data repeatedly. The calculation method for the second expected byte count is the same as that for the first expected byte count; for details, please refer to the section on the calculation method for the first expected byte count in the specification, which will not be repeated here. After each calculation of the second expected byte count corresponding to real-time data, the polling host can determine whether the actual byte count of the currently read real-time data is greater than or equal to the second expected byte count. If the polling host determines that the actual byte count of the currently read real-time data is greater than or equal to the second expected byte count, then the polling host can determine that the real-time data read at this time meets the user-preset message stopping condition, that is, the real-time data read at this time is a complete acknowledgment message returned by the slave based on the first request message. At this time, the polling host can determine that the currently read real-time data is an acknowledgment message returned by the slave based on the first request message.

[0081] In one possible implementation, if the polling host determines that the actual number of bytes of the currently read real-time data is less than the second expected number of bytes, then the polling host can determine that the real-time data read at this time does not meet the user-preset message stop condition, that is, the real-time data read at this time is not a complete receipt message. In this case, the polling host can update the number of repeated reads and determine whether the current number of repeated reads meets the user-preset read stop condition. If the polling host determines that the actual number of bytes of the currently read real-time data is less than the second expected number of bytes and the number of repeated reads does not meet the user-preset read stop condition, then the polling host can wait according to the interval waiting time and continue to repeatedly read real-time data.

[0082] In one possible implementation, the polling host can increment the repeat read count corresponding to the first request message by one after each repeated read of real-time data. After incrementing the repeat read count, the polling host can determine whether the current repeat read count meets the user-preset read stop condition. If the repeat read count meets the user-preset read stop condition, the polling host can stop reading real-time data. At this time, the polling host can delete the read real-time data and set the message status corresponding to the first request message to the status of the previous receipt message error. The polling host can determine whether the repeat read count meets the user-preset read stop condition by checking whether the repeat read count is greater than the user-preset repeat read threshold. If the repeat read count is greater than the user-preset repeat read threshold, the polling host can determine that the repeat read count meets the user-preset read stop condition. If the repeat read count is less than or equal to the user-preset repeat read threshold, the polling host can determine that the repeat read count does not meet the user-preset read stop condition.

[0083] In one possible implementation, each first request message may also include a user-preset number of repeated reads. After each instance of real-time data is repeatedly read, the polling host can reduce the number of repeated reads corresponding to the first request message. The polling host can decrement the number of repeated reads for each instance of real-time data by checking if the number of repeated reads is greater than 0. If the number of repeated reads is greater than 0, the polling host can determine that the number of repeated reads does not meet the user-preset reading stop condition. If the number of repeated reads is less than or equal to 0, the polling host can determine that the number of repeated reads meets the user-preset reading stop condition.

[0084] In one possible implementation, see Figure 6 This is a schematic diagram illustrating the execution flow of a polling operation provided in an embodiment of this application. Figure 6 As shown, the polling master can respond to a polling command by retrieving the request message to be sent from the message list and the experienced waiting time in the request message. The message list may also include the request status corresponding to each request message and the number of times each request message can be read repeatedly, as preset by the user. If the request message contains an experienced waiting time, the polling master can determine that the current request message is the first request message. The polling master can send the first request message to the slave device and wait according to the experienced waiting time. When the waiting time of the polling master meets the experienced waiting time, the polling master can attempt to retrieve real-time data from the serial port preset by the user. The polling master can write the retrieved real-time data into a byte array for storage and calculate the actual number of bytes corresponding to the real-time data using the byte array. After obtaining the actual number of bytes, the polling master can determine whether the actual number of bytes is greater than or equal to 3. If the number of bytes is less than 3, the polling master can discard the retrieved real-time data and update the request status corresponding to the first request message in the message list to the error status of the previous receipt message.

[0085] If the number of bytes is greater than or equal to 3, the polling host can parse the real-time data and determine the function code within it. The polling host can then determine if the obtained function code is less than 5. If the polling host determines that the obtained function code is greater than or equal to 5, it can discard the obtained real-time data and update the request status of the first request message in the message list to the error status of the previous receipt message. If the polling host determines that the obtained function code is less than 5, it can parse the real-time data and obtain the first data segment and its byte count. The polling host can determine the expected byte count of the real-time data by adding 5 to the byte count of the first data segment. After determining the expected and actual byte counts, the polling host can determine if the expected byte count is greater than the actual byte count.

[0086] If the polling host determines that the expected number of bytes is less than or equal to the actual number of bytes, it can determine that the currently read real-time data is a receipt message returned by the slave device based on the first request message. The polling host can verify the validity of the receipt message. If the receipt message is valid, the polling host can parse the currently acquired receipt message and update the request status corresponding to the first request message in the message list to a successful return status. If the receipt message is invalid, the polling host can discard the acquired receipt message and update the request status corresponding to the first request message in the message list to the error status of the previous receipt message. The polling host can determine the validity of the receipt message by checking for user-predefined anomalies. If the receipt message exhibits any one or more anomalies such as message too short, incorrect receipt checksum, or disconnected serial port connection, the polling host can determine that the current receipt message is invalid. If the receipt message does not exhibit any anomalies, the polling host can determine that the receipt message is valid.

[0087] If the polling host determines that the expected number of bytes is greater than the actual number of bytes, it can check if the repeated read count for the first request message is greater than 0. If the polling host determines that the repeated read count for the first request message is less than or equal to 0, it can discard the acquired real-time data and update the request status of the first request message in the message list to the error status of the previous receipt message. If the polling host determines that the repeated read count for the first request message is greater than 0, it can repeatedly read the real-time data and write the new real-time data into the byte array to calculate the actual number of bytes of the newly read real-time data. After repeatedly reading the real-time data, the polling host can also decrement the repeated read count for the request message to update the remaining repeated read count for the currently requested first request message in the current polling cycle. The polling host can return to the steps of parsing the real-time data, determining the number of bytes in the first data segment and the expected number of bytes, and subsequent steps to update the expected number of bytes for the real-time data. The polling host can repeatedly execute the steps of reading real-time data until the first request message meets the reading stop condition or the message stop condition. The read stop condition is that the number of repeated reads corresponding to the first request message is less than or equal to 0. The message stop condition is that the expected number of bytes of real-time data is less than or equal to the actual number of bytes.

[0088] When the polling host determines that the first request message meets the read stop condition or message stop condition, the polling host can stop reading real-time data and generate a receipt message based on the read real-time data. The polling host can verify whether the currently generated receipt message is valid. If the polling host determines that the current receipt message is valid, it can determine that the current receipt message is a receipt message returned by the slave based on the first request message. The polling host can parse the currently obtained receipt message and update the request status corresponding to the first request message in the message list to the successful return status. If the receipt message is invalid, the polling host can discard the obtained receipt message and update the request status corresponding to the first request message in the message list to the error status of the previous receipt message.

[0089] In this embodiment, the response time required by the slave device to reply to the request message sent by the polling master is unstable; that is, the time for the slave device to respond to the master's request is actually a range. Therefore, after the reporter waits based on experience and obtains real-time data, it needs to calculate the expected number of bytes and the actual number of bytes corresponding to the real-time data, and determine whether the expected number of bytes is greater than the actual number of bytes. The polling master can determine whether the real-time data read is a complete receipt message returned by the slave device based on the first request message by determining whether the expected number of bytes is greater than the actual number of bytes. If the polling master determines that the expected number of bytes is greater than the actual number of bytes, the polling master can repeatedly read the real-time data. Therefore, the method provided by this application embodiment can ensure that the receipt message obtained by the polling master is a complete receipt message returned by the slave device based on the first request message, thereby improving the accuracy of the polling master reading the receipt message.

[0090] Figure 7 A flowchart illustrating a specific implementation of a polling method S102 provided in the fourth embodiment of this application is shown. See also... Figure 7 Compared to Figure 1 In the embodiment provided, S102 of the polling method includes: S701 to S703, which are detailed below:

[0091] S701. Send a second request message to the slave device, record the sending time of the second request message, and perform multiple repeated read operations; the second request message is any of the request messages; the repeated read operation is used to read multiple real-time data returned by the slave device based on the second request message based on a preset read interval.

[0092] In this embodiment, after obtaining the second request message from the message list, the polling host can send the second request message to the slave device and record the sending time corresponding to the second request message. After sending the second request message to the slave device, the polling host performs multiple repeated read operations. The repeated read operation of the polling host can be to read multiple pre-read messages returned by the slave device based on the second request message according to a user-preset read interval. The second request message sent by the polling host can be any request message from the message list.

[0093] In one possible implementation, the polling host, responding to a polling command, retrieves a request message from the message list and determines whether the request message contains an experience waiting time. If the polling host determines that the request message contains an experience waiting time, it can identify the current request message as the first request message. The polling host can then perform polling according to the polling method corresponding to the first request message. The polling method corresponding to the first request message can be found in the second and third embodiments of this application, and will not be repeated here. If the polling host determines that the request message does not contain an experience waiting time, it can identify the current request message as the second request message.

[0094] S702. If the current repeated read operation does not read the real-time data, then determine the receipt message corresponding to the second request message based on the multiple real-time data read, and record the execution time of the current repeated read operation.

[0095] In this embodiment, after each repeated read operation, the polling host can determine whether the current read operation has retrieved real-time data. If the polling host determines that the current repeated read operation has not retrieved the real-time data returned by the slave based on the second request message, the polling host can stop executing the repeated read operation. The polling host can determine the receipt message corresponding to the second request message based on the multiple real-time data retrieved in previous repeated read operations. The polling host can also record the execution time of the current repeated read operation.

[0096] In one possible implementation, when the slave device responds to the second request message and returns a receipt message, it generates and returns each data segment sequentially according to the return order of the data segments in the receipt message. Therefore, after each read operation, the polling master can determine whether the current read operation has read real-time data by checking if the number of bytes read is 0. If the polling time determines that the number of bytes read is not 0, the polling master can determine that the current read operation has read real-time data. If the polling time determines that the number of bytes read is 0, the polling master can determine that the current read operation has not read real-time data.

[0097] S703. Generate an experience waiting time corresponding to the second request message based on the sending time, the execution time, and the reading interval, and write the experience waiting time into the second request message so that when responding to the next polling instruction, the timing for reading the receipt message corresponding to the second request message is determined based on the experience waiting time in the second request message.

[0098] In this embodiment, after determining the execution time of the last repeated read operation, the polling host can generate an experienced waiting time corresponding to the second request message based on the sending time of the second request message, the execution time of the last repeated read operation, and the user-preset read interval. The polling host can write the experienced waiting time into the second request message. After responding to the user-initiated next polling command, the polling host can send a second request message containing the experienced waiting time to the slave device, and determine the timing of reading the acknowledgment message corresponding to the second request message based on the experienced waiting time.

[0099] In one possible implementation, see Figure 8 This diagram illustrates a process for generating experience waiting time according to an embodiment of this application. Figure 8 As shown, when generating a request message, the polling host can set the status of the generated request message to a non-polling state and write the request message and its corresponding request status into a message list. When the polling host responds to the polling command and retrieves a request message from the message list, if the request message does not contain an experienced waiting time and the corresponding message status is non-polling, the polling host can determine that the current request message is the second request message, and the polling host can obtain the user-preset reading interval. Specifically, the reading interval can be 10 milliseconds. This application embodiment does not specifically limit the reading interval; those skilled in the art can set the reading interval based on the slave device's performance data and the content of the request message. Then, the polling host can send the second request message to the slave device, wait according to the reading interval, and update the waiting time. After updating the waiting time, the polling host can determine whether the current waiting time exceeds the user-preset waiting threshold.

[0100] If the polling host determines that the current waiting time exceeds the waiting threshold preset by the user, the polling host can discard the received receipt message and update the request status corresponding to the first request message in the message list to the timeout no receipt status.

[0101] If the polling host determines that the current waiting time does not exceed the user-preset waiting threshold, it can read the data returned by the slave device from the preset serial port. Then, the polling host can determine if the number of bytes read in this read operation is 0. If the polling host determines that the number of bytes read in this read operation is not 0, it can write the data read in this read operation into a byte array and return to execute the steps of waiting according to the preset reading interval and updating the waiting time, as well as subsequent steps. If the polling host determines that the number of bytes read in this read operation is 0, it can determine if there is content in the current byte array. If the polling host determines that there is no content in the current byte array, it can return to execute the steps of waiting according to the preset reading interval and updating the waiting time, as well as subsequent steps. If the polling host determines that there is content in the current byte array, it can record the obtained waiting time, sending time, and reading interval to calculate the empirical waiting time for the second request message. The empirical waiting time can be equal to the waiting time minus the sending time minus the reading interval.

[0102] The polling master can generate a receipt message based on all real-time data contained in the byte array and determine whether the receipt message is valid. If the polling master determines that the receipt message is valid, it can identify that the current receipt message is a receipt message returned by the slave based on the first request message. The polling master can parse the currently obtained receipt message and update the request status corresponding to the first request message in the message list to a successful return status. If the receipt message is invalid, the polling master can discard the receipt message and update the request status corresponding to the first request message in the message list to the error status of the previous receipt message.

[0103] In this embodiment, when the request message does not contain an experienced waiting time, the polling host can read multiple real-time data returned by the slave device based on the second request message according to a pre-set reading interval. The polling host can determine the receipt message corresponding to the second request message based on the multiple real-time data read, and determine the experienced waiting time corresponding to the second request message based on the execution time corresponding to the last repeated read operation, the sending time of the second request message, and the reading interval. Through the method provided in this embodiment, the polling host can quickly and accurately obtain the receipt message corresponding to the second request message and generate the experienced waiting time corresponding to the second request message even without an experienced waiting time. Therefore, the method provided in this embodiment improves the availability of the polling host and ensures the accuracy of the experienced waiting time.

[0104] Figure 9 A flowchart illustrating a specific implementation of a polling method S101 provided in the fifth embodiment of this application is shown. See also... Figure 9 Compared to Figure 1In the embodiment provided, S101 of the polling method includes: S1011 to S1013, which are detailed below:

[0105] S1011. Based on the function code, the multiple control instructions in the message configuration list are divided into multiple request groups, and the first control instruction in any request group is obtained in sequence; the first control instruction is one of the control instructions in any request group.

[0106] In this embodiment, after obtaining the message configuration list corresponding to the slave device, the polling host can divide the multiple control instructions in the message configuration list into multiple request groups according to the function codes corresponding to each control instruction. After generating multiple request groups, the polling host can sequentially encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the control instructions in each request group. The polling host can obtain the first control instruction in any request group. Each request group can contain at least one control instruction, and the first control instruction can be one of the control instructions in the request group. Figure 2 As shown, since the function codes corresponding to the temperature detection command, voltage 1 detection command, voltage 2 detection command, current 1 detection command, and current 2 detection command are all 0x03 and 0x04, the polling host can group these commands into the same request group.

[0107] In one possible implementation, after generating multiple request groups, the polling host can sort the first control instructions within the same request group in descending order based on their register addresses. After sorting, the polling host can then sequentially retrieve the first control instructions from the same request group.

[0108] S1012. For any request group, if the first control instruction in the request group meets the preset continuous request condition, then the first control instruction is written into the continuous request list, and it is determined whether the other control instructions in the request group meet the continuous request condition.

[0109] In this embodiment, after generating multiple request groups, the polling host, for any given request group, after obtaining the first control instruction in the current request group, can determine whether the obtained first control instruction meets the user's pre-set continuous request conditions. If the polling host determines that the obtained first control instruction meets the user's pre-set continuous request conditions, the polling host can write the first control instruction into the continuous request list and sequentially obtain other control instructions in the same request group.

[0110] In one possible implementation, if the polling host determines that the first control command it receives does not meet the user-preset continuous request conditions, the polling host can generate an independent request message based on the current control command. The polling host can then obtain the next control command from the request group and determine whether the next control command meets the user-preset continuous request conditions.

[0111] S1013. Write the other control instructions that meet the continuous request conditions into the continuous request list, and continuously obtain the other control instructions in the request group for judgment, until any other control instruction does not meet the continuous request conditions or all control instructions in the request group have been judged for continuous request conditions, then generate a request message based on all control instructions in the continuous request list.

[0112] In this embodiment, the polling host can determine whether each acquired control command meets the user-preset continuous request conditions after it is acquired. If the polling host determines that the current control command meets the continuous request conditions, it can add the control command to the continuous request list. The polling host can continuously acquire and evaluate each other control command in the current request group until any other control command fails to meet the continuous request conditions or all control commands in the current request group have been evaluated for continuous requests.

[0113] In one possible implementation, if the polling host determines that any other control instruction does not meet the continuous request condition, it can generate a request message based on all control instructions in the continuous request list. Then, the polling host can clear the continuous request list and obtain the next other control instruction to determine the continuous request condition. The polling host can then add control instructions that meet the continuous request condition to the continuous request list.

[0114] In one possible implementation, when the polling host generates a request message using all control instructions in the continuous request list, it can generate a checksum segment in the request message based on all control instructions in the continuous request list and a user-predefined checksum calculation method. The polling host can also determine the number of consecutive requests corresponding to the request message based on the start register address corresponding to the first control instruction written to the continuous request list and the end register address corresponding to the last control instruction written to the continuous request list. The polling host can generate the request message based on the slave tag, checksum segment, and number of consecutive requests corresponding to the message configuration list. The checksum calculation method can be modulo-2 division or any checksum calculation method commonly used by those skilled in the art; this application does not impose specific limitations on the checksum calculation method.

[0115] The method provided in this embodiment can ensure that multiple control instructions encapsulated in the same request message by the polling host meet the continuous request condition, thus ensuring that the request message generated by the polling host can be used to continuously request multiple registers in the slave device, thereby ensuring the availability of the request message.

[0116] Figure 10 A flowchart illustrating a specific implementation of a polling method S1013 according to the sixth embodiment of this application is shown. See also... Figure 10 Compared to Figure 9 In the embodiment provided, S1013 of the polling method includes: S1001 to S1003, which are detailed below:

[0117] S1001. Write the i-th control instruction that satisfies all the continuous conditions into the continuous request list; where i is a positive integer greater than or equal to 1.

[0118] In this embodiment, after generating multiple request groups, the polling host can sequentially traverse each request group. When traversing any request group, the polling host can obtain the i-th control instruction in the current request group according to the traversal cursor i. The polling host can determine whether the i-th control instruction satisfies the consecutive request list. Here, i is a positive integer greater than or equal to 1. In this embodiment, the consecutive request condition includes multiple consecutive conditions. The address consecutive condition is one of the multiple consecutive conditions. The message configuration list may also contain the register addresses corresponding to each control instruction. The register addresses of each control instruction may include the start register address and the end register address corresponding to the control instruction.

[0119] In one possible implementation, the data type condition is also one of several consecutive conditions. When there is no control instruction in the consecutive request list, the polling host can determine whether the i-th control instruction meets the consecutive request condition based on its data type. If the data type of the i-th control instruction meets the user-preset data type condition, the polling host can determine that the i-th control instruction meets the consecutive request condition, and the polling host can add the i-th control instruction as the first control instruction in the consecutive request list.

[0120] In one possible implementation, when a control instruction already exists in the consecutive request list, the polling host can determine whether the i-th control instruction meets the consecutive request condition by analyzing the address relationship between the i-th control instruction and the (i-1)-th control instruction. The specific determination process is consistent with the determination process for the address relationship between the i-th control instruction and the (i+1)-th control instruction in the sixth embodiment of this application, and will not be repeated here.

[0121] In one possible implementation, when a control instruction already exists in the consecutive request list, the polling host can also determine whether the i-th control instruction meets the consecutive request condition by checking the number of pre-requests in the consecutive request list. The specific determination process is detailed in the seventh embodiment of this application and will not be repeated here.

[0122] S1002. If i is less than the number of instructions corresponding to the request group, then obtain the (i+1)th control instruction in the request group.

[0123] In this embodiment, after the polling host writes the i-th control instruction into the continuous request list, it can determine whether i is less than the number of instructions corresponding to the request group. If the polling host determines that i is less than the number of instructions corresponding to the request group, the polling host can obtain the (i+1)-th control instruction in the current request group.

[0124] S1003. If the address relationship between the i-th end register address corresponding to the i-th control instruction and the i+1 start register address corresponding to the i+1 control instruction does not satisfy the address continuity condition, then the request message is generated based on all control instructions in the continuous request list.

[0125] In this embodiment, after obtaining the (i+1)th control instruction, the polling host can determine whether the address relationship between the i-th end register address corresponding to the i-th control instruction and the (i+1)-th start register address corresponding to the (i+1)-th control instruction satisfies the address continuation condition preset by the user. If the polling host determines that the address relationship between the i-th end register address corresponding to the i-th control instruction and the (i+1)-th start register address corresponding to the (i+1)-th control instruction does not satisfy the address continuation condition, the polling host can generate the request message based on all control instructions in the continuous request list and delete all control instructions in the continuous request list, so as to store multiple control instructions that satisfy the continuous request condition through the continuous request list.

[0126] like Figure 11 The diagram shown is a flowchart illustrating a process for generating a request message according to an embodiment of this application. See also... Figure 11After the polling master obtains the message configuration list corresponding to the slave device, it can group all control commands in the message configuration list according to the function codes corresponding to each control command in the message configuration list. After generating multiple request groups, the polling master can determine the number of commands corresponding to each request group and traverse each request group sequentially. When the polling master starts traversing any request group, it can first define a traversal cursor i for the control commands and set i to 1. The polling master can obtain each control command in the request group according to the traversal cursor i. The polling master can first determine whether i is less than the number of commands corresponding to the currently traversed request group. If i is greater than or equal to the number of commands corresponding to the currently traversed request group, the polling master can generate a request message according to all control commands in the continuous request list and start traversing the next request group. If i is less than the number of commands corresponding to the currently traversed request group, the polling master can obtain the i-th control command and determine whether the i-th control command meets the continuous request condition. If the i-th control instruction meets the continuous request condition, the polling host can write the i-th control instruction into the continuous request list and determine whether i+1 is less than the number of instructions corresponding to the current traversed request group.

[0127] If i+1 is greater than or equal to the number of instructions corresponding to the currently traversed request group, the polling host can generate a request message based on all control instructions in the continuous request list and begin traversing the next request group. If i+1 is less than the number of instructions corresponding to the currently traversed request group, the polling host can obtain the (i+1)th start register address and the (i)th end register address corresponding to the (i)th control instruction in the current request group. The polling host can determine whether the (i+1)th start register address minus the (i)th end register address is greater than 1. If the (i+1)th start register address minus the (i)th end register address is greater than 1, the polling host can determine that the address relationship between the (i)th control instruction and the (i+1)th control instruction does not satisfy the address contiguous condition. The polling host can generate a request message based on all control instructions in the continuous request list and set i to i+2. The polling host can return to the step of determining whether i is less than the number of instructions corresponding to the currently traversed request group and its subsequent steps. If the difference between the (i+1)th starting register address and the i-th ending register address is less than or equal to 1, the polling host can determine that the address relationship between the i-th control instruction and the (i+1)-th control instruction satisfies the address contiguous condition. The polling host can then add the (i+1)-th control instruction to the contiguous request list. Afterward, the polling host can set i to i+2 and return to the step of determining whether i is less than the number of instructions corresponding to the currently traversed request group, and its subsequent steps.

[0128] The method provided in this embodiment can ensure that the register addresses of multiple control instructions encapsulated in the same request message by the polling host are consecutive and that their function codes are the same, thus ensuring the availability of the request message generated by the polling host.

[0129] Figure 12 A flowchart illustrating a specific implementation of a polling method S1002 provided in the seventh embodiment of this application is shown. See also Figure 12 Compared to Figure 10 In the embodiment provided, the polling method further includes S1201 to S1202 after S1002, as detailed below:

[0130] S1201. Determine the number of pre-requests based on the (i+1)th end register address corresponding to the (i+1)th control instruction and the starting address in the continuous request list; the starting address is the starting register address corresponding to the first control instruction written into the continuous request list.

[0131] In this embodiment, the multiple consecutive conditions may also include a number condition. After obtaining the (i+1)th control instruction, the polling host can determine the number of pre-requests based on the (i+1)th end register address corresponding to the (i+1)th control instruction and the starting address in the consecutive request list. The starting address in the consecutive request list can be the starting register address corresponding to the first control instruction written into the consecutive request list.

[0132] S1202. If the number of pre-requests does not meet the number condition, then the request message is generated based on all control instructions in the continuous request list.

[0133] In this embodiment, after determining the number of pre-requests in the continuous request list, the polling host can determine whether the number of pre-requests meets the count condition. If the polling host determines that the number of pre-requests does not meet the count condition, the polling host can generate the request message based on all control instructions in the current continuous request list. If the polling host determines that the number of pre-requests meets the count condition, the polling host can write the (i+1)th control instruction into the continuous request list.

[0134] In one possible implementation, the polling host can determine whether the number of pre-requests meets the quantity requirement by checking if the number of pre-requests is less than a user-defined continuous request threshold. For example... Figure 13 The diagram shown is a flowchart illustrating a process for generating a request message according to an embodiment of this application. Figure 13 The steps for obtaining the (i+1)th control instruction and all preceding steps are related to Figure 11 The content is consistent with the instructions; please refer to the manual for specific procedures. Figure 11 The details will not be repeated here.

[0135] See Figure 13 After obtaining the (i+1)th control instruction, the polling host can calculate the number of pre-requests corresponding to the continuous request list after writing the (i+1)th control instruction by subtracting the start address from the (i+1)th end register address. If the number of pre-requests is greater than the continuous request threshold, the polling host can generate a request message based on all existing control instructions in the continuous request list.

[0136] In this embodiment, the polling host can determine the number of pre-requests corresponding to the continuous request list using the (i+1)th end register address and the start address. When the number of pre-requests does not meet the quantity requirement, it generates a request message based on all existing control instructions in the continuous request list. Therefore, the method provided in this embodiment ensures that the number of registers requested in the continuous request message generated by the polling host is within the continuous request threshold that the slave device can respond to. This guarantees the high availability of the request message generated in this embodiment.

[0137] Figure 14 A flowchart illustrating a specific implementation of a polling method S1002 provided in the seventh embodiment of this application is shown. See also Figure 14 Compared to Figure 10 In the embodiment provided, the polling method further includes S1401 after S1002, as detailed below:

[0138] S1401. If the data type corresponding to the (i+1)th control instruction does not meet the data type condition, then the continuous request message is generated based on all control instructions in the continuous request list, and the independent request message is generated based on the (i+1)th control instruction.

[0139] In this embodiment, the multiple consecutive conditions also include data type conditions. The request message generated by the polling host can also include consecutive request messages and independent request messages. The consecutive request message can encapsulate multiple control instructions with the same function code and consecutive register addresses. The polling host can continuously read the contents of multiple registers in the slave device using the consecutive request message. The independent request message can encapsulate a control instruction that can only be read individually. The polling host can read the contents of one register in the slave device using the independent request message. After obtaining the (i+1)th control instruction, the polling host can also determine whether the (i+1)th control instruction satisfies the consecutive request conditions based on the data type corresponding to the (i+1)th control instruction. The polling host can determine whether the data type corresponding to the (i+1)th control instruction satisfies the data type conditions. If the data type corresponding to the (i+1)th control instruction does not satisfy the data type conditions, the polling host can generate a consecutive request message based on all control instructions in the consecutive request list. The polling host can also generate the independent request message based on the (i+1)th control instruction.

[0140] In one possible implementation, after receiving the (i+1)th control instruction, the polling host can determine whether the data type corresponding to the (i+1)th control instruction is a string. Since request messages cannot continuously read the registers corresponding to string-type control instructions (i.e., the registers corresponding to string-type control instructions are read one by one through independent request messages), if the data type corresponding to the (i+1)th control instruction is a string, the polling host can determine that the data type of the (i+1)th control instruction does not meet the data type condition. If the data type corresponding to the (i+1)th control instruction is not a string, the polling host can determine that the data type of the (i+1)th control instruction meets the data type condition.

[0141] In this embodiment, the polling host can determine whether each control instruction meets the continuous request condition based on the data type of each control instruction. Therefore, the method provided in this embodiment can ensure that the registers of multiple control instructions encapsulated in the same request message can be continuously requested by the polling host through the request message, thus ensuring the availability of the request message generated by the polling host.

[0142] In practical application of this solution, when researchers used polling the master to obtain the contents of a total of 65 registers as the experimental subject, they found that if polling generates a separate request message for each register content according to existing technology, the polling cycle required to poll the 65 registers is greater than 6500 milliseconds. However, the polling cycle required by the method provided in this application embodiment is only 800 milliseconds. Furthermore, since the method provided in this application embodiment can significantly reduce the total time required for a single polling cycle, compared to the existing technology, a single polling master can poll more slave devices, and a single polling master can also connect more slave devices through a single serial port, thereby reducing system costs.

[0143] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0144] Reference Figure 15 The diagram illustrates a polling device according to an embodiment of this application, which may specifically include a request message generation module 1501 and a polling module 1502, wherein:

[0145] The request message generation module 1501 is used to encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, so as to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device;

[0146] The polling module 1502 is used to respond to the polling command and send each of the request messages to the slave device in sequence based on the sending timing of each request message; the sending timing is to send the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message.

[0147] The polling module can also be used to send the first request message to the slave device based on the timing of sending the first request message; and to read the acknowledgment message returned by the slave device based on the first request message based on the empirical waiting time.

[0148] The polling module can also be used to read the real-time data returned by the slave device during the experience waiting time; if the real-time data contains a first data segment, the first expected number of bytes corresponding to the real-time data is determined based on the number of bytes in the first data segment; if the actual number of bytes in the real-time data is less than the first expected number of bytes, the real-time data returned by the slave device is read based on a preset interval waiting time, and the number of repeated reads corresponding to the first request message is updated until the real-time data meets a preset message stopping condition or the number of repeated reads meets a preset read stopping condition; the message stopping condition is that the actual number of bytes in the real-time data is greater than or equal to the second expected number of bytes; the read stopping condition is that the number of repeated reads is greater than or equal to a preset repeated read threshold.

[0149] The polling module can also be used to send a second request message to the slave device, record the sending time of the second request message, and perform multiple repeated read operations; the second request message can be any of the request messages; the repeated read operation is used to read multiple real-time data returned by the slave device based on the second request message based on a preset read interval; if the current repeated read operation does not read the real-time data, then the acknowledgment message corresponding to the second request message is determined based on the multiple real-time data read, and the execution time of the current read operation is recorded; an empirical waiting time corresponding to the second request message is generated based on the sending time, the execution time, and the read interval, and the empirical waiting time is written into the second request message, so that when responding to the next polling instruction, the reading timing of the acknowledgment message corresponding to the second request message is determined based on the empirical waiting time in the second request message.

[0150] The request message generation module can also be used to divide the multiple control instructions in the message configuration list into multiple request groups based on the function code, and sequentially obtain the first control instruction in any request group; the first control instruction is one of the control instructions in any request group; for any request group, if the first control instruction in the request group meets a preset continuous request condition, the first control instruction is written into a continuous request list, and it is determined whether other control instructions in the request group meet the continuous request condition; the other control instructions that meet the continuous request condition are written into the continuous request list, and the other control instructions in the request group are continuously obtained and judged until any other control instruction does not meet the continuous request condition or all control instructions in the request group have been judged for continuous request condition, then a request message is generated based on all control instructions in the continuous request list.

[0151] The request message generation module can also be used to write the i-th control instruction that satisfies all the continuity conditions into the continuous request list; where i is a positive integer greater than or equal to 1; if i is less than the number of instructions corresponding to the request group, then the (i+1)-th control instruction in the request group is obtained; if the address relationship between the i-th end register address corresponding to the i-th control instruction and the (i+1)-th start register address corresponding to the (i+1)-th control instruction does not satisfy the address continuity condition, then the request message is generated based on all control instructions in the continuous request list.

[0152] The request message generation module can also be used to determine the number of pre-requests based on the (i+1)th end register address corresponding to the (i+1)th control instruction and the starting address in the continuous request list; the starting address is the starting register address corresponding to the first control instruction written into the continuous request list; if the number of pre-requests does not meet the number condition, the request message is generated based on all control instructions in the continuous request list.

[0153] The request message generation module can also be used to generate the continuous request message based on all control instructions in the continuous request list and generate the independent request message based on the (i+1)th control instruction if the data type corresponding to the (i+1)th control instruction does not meet the data type condition.

[0154] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0155] Reference Figure 16 The diagram illustrates an electronic device according to an embodiment of this application. Figure 16 As shown, the electronic device 1600 in this embodiment includes: a processor 1610, a memory 1620, and a computer program 1621 stored in the memory 1620 and executable on the processor 1610. When the processor 1610 executes the computer program 1621, it implements the steps in the various embodiments of the polling method described above, for example... Figure 1 Steps S101 to S102 are shown. Alternatively, when the processor 1610 executes the computer program 1621, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 15 The functions of modules 1501 to 1502 are shown.

[0156] For example, the computer program 1621 can be divided into one or more modules / units, which are stored in the memory 1620 and executed by the processor 1610 to complete this application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which can be used to describe the execution process of the computer program 1621 in the electronic device 400. For example, the computer program 1621 can be divided into a request message generation module and a polling module, with the specific functions of each module as follows:

[0157] The request message generation module is used to encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, so as to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device;

[0158] The polling module is used to respond to the polling command and send each of the request messages to the slave device in sequence based on the sending timing of each request message; the sending timing is to send the next request message to the slave device after reading the acknowledgment message returned by the slave device based on the previous request message.

[0159] The polling module can also be used to send the first request message to the slave device based on the timing of sending the first request message; and to read the acknowledgment message returned by the slave device based on the first request message based on the empirical waiting time.

[0160] The electronic device 1600 may be the polling host in the foregoing embodiments, which may be a desktop computer, cloud server, or other computing device. The electronic device 1600 may include, but is not limited to, a processor 1610 and a memory 1620. Those skilled in the art will understand that... Figure 16 This is merely one example of electronic device 1600 and does not constitute a limitation on electronic device 1600. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 1600 may also include input / output devices, network access devices, buses, etc.

[0161] The processor 1610 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0162] The memory 1620 can be an internal storage unit of the electronic device 1600, such as a hard disk or memory of the electronic device 1600. The memory 1620 can also be an external storage device of the electronic device 1600, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 1600. Furthermore, the memory 1620 can include both internal and external storage units of the electronic device 1600. The memory 1620 is used to store the computer program 1621 and other programs and data required by the electronic device 1600. The memory 1620 can also be used to temporarily store data that has been output or will be output.

[0163] This application also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the polling method as described in the foregoing embodiments.

[0164] This application also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the polling method as described in the foregoing embodiments.

[0165] This application also discloses a computer program product that, when run on a computer, causes the computer to execute the polling method described in the foregoing embodiments.

[0166] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A polling method, characterized in that, Applied to polling hosts, including: According to the message configuration list corresponding to the slave device, control instructions with consecutive register addresses and the same function code are encapsulated into the same request message to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device; In response to the polling command, each of the request messages is sent to the slave device sequentially based on the sending timing of each request message; the (N+1)th sending timing is after reading the acknowledgment message returned by the slave device based on the previous request message, at which point the next request message is sent to the slave device; N is a positive integer greater than or equal to 1, the first request message includes an empirical waiting time; the first request message is any of the request messages. The response to the polling command, based on the timing of the transmission of each request message, sequentially sends each request message to the slave device, including: The first request message is sent to the slave device based on the timing of the first request message; Based on the experience, wait for the time specified and then read the receipt message returned by the slave device based on the first request message.

2. The method according to claim 1, characterized in that, The receipt message is returned sequentially by the slave device to the polling master device based on the return order of each data segment. The step of reading the receipt message returned by the slave device based on the first request message based on the experienced waiting time further includes: During the experience waiting time, read the real-time data returned by the slave device; If the real-time data contains a first data segment, then the first expected number of bytes corresponding to the real-time data is determined based on the number of bytes in the first data segment; If the actual number of bytes in the real-time data is less than the first expected number of bytes, the real-time data returned by the slave device is read based on a preset interval waiting time, and the number of repeated reads corresponding to the first request message is updated until the real-time data meets a preset message stop condition or the number of repeated reads meets a preset read stop condition; the message stop condition is that the actual number of bytes in the real-time data is greater than or equal to the second expected number of bytes; the read stop condition is that the number of repeated reads is greater than or equal to a preset repeated read threshold.

3. The method according to claim 1, characterized in that, The response to the polling command, based on the timing of the transmission of each request message, sequentially sends each request message to the slave device, including: Send a second request message to the slave device, record the sending time of the second request message, and perform multiple repeated read operations; the second request message can be any of the request messages; the repeated read operation is used to read multiple real-time data returned by the slave device based on the second request message based on a preset read interval; If the current repeated read operation does not read the real-time data, then the receipt message corresponding to the second request message is determined based on the multiple real-time data read, and the execution time of the current repeated read operation is recorded. Based on the sending time, the execution time, and the reading interval, an experience waiting time corresponding to the second request message is generated, and the experience waiting time is written into the second request message so that when responding to the next polling instruction, the timing for reading the acknowledgment message corresponding to the second request message is determined based on the experience waiting time in the second request message.

4. The method according to any one of claims 1-3, characterized in that, The message configuration list also records the function codes corresponding to each control instruction. The step of encapsulating control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, to generate multiple request messages corresponding to the slave device, includes: Based on the function code, the multiple control instructions in the message configuration list are divided into multiple request groups, and the first control instruction in any request group is obtained in sequence; the first control instruction is one of the control instructions in any request group. For any request group, if the first control instruction in the request group meets the preset continuous request condition, then the first control instruction is written into the continuous request list, and it is determined whether other control instructions in the request group meet the continuous request condition. Other control instructions that meet the continuous request conditions are written into the continuous request list, and other control instructions in the request group are continuously acquired and judged until any other control instruction does not meet the continuous request conditions or all control instructions in the request group have been judged for continuous request conditions. Then, a request message is generated based on all control instructions in the continuous request list.

5. The method according to claim 4, characterized in that, The continuous request condition includes multiple continuous conditions, including address continuity conditions. The register address includes a start register address and an end register address. The process involves writing other control instructions that satisfy the continuous request condition into the continuous request list, and continuously acquiring and judging other control instructions in the request group until any other control instruction fails to satisfy the continuous request condition or all control instructions in the request group have been judged for continuous request conditions. Then, a request message is generated based on all control instructions in the continuous request list, including: Write the i-th control instruction that satisfies all the aforementioned consecutive conditions into the consecutive request list; where i is a positive integer greater than or equal to 1. If i is less than the number of instructions corresponding to the request group, then the (i+1)th control instruction in the request group is obtained; If the address relationship between the i-th end register address corresponding to the i-th control instruction and the i+1-th start register address corresponding to the i+1 control instruction does not satisfy the address continuity condition, then the request message is generated based on all control instructions in the continuous request list.

6. The method according to claim 5, characterized in that, The multiple consecutive conditions also include a number condition. After obtaining the (i+1)th control instruction in the request group if i is less than the number of instructions corresponding to the request group, the condition further includes: The number of pre-requests is determined based on the (i+1)th end register address corresponding to the (i+1)th control instruction and the starting address in the consecutive request list; the starting address is the starting register address corresponding to the first control instruction written into the consecutive request list. If the number of pre-requests does not meet the number condition, then the request message is generated based on all control instructions in the continuous request list.

7. The method according to claim 5, characterized in that, The multiple consecutive conditions also include data type conditions. The request message includes consecutive request messages and independent request messages. After obtaining the (i+1)th control instruction in the request group if i is less than the number of instructions corresponding to the request group, the process further includes: If the data type corresponding to the (i+1)th control instruction does not meet the data type condition, then the continuous request message is generated based on all control instructions in the continuous request list, and the independent request message is generated based on the (i+1)th control instruction.

8. A polling device, characterized in that, Applied to polling hosts, including: The request message generation module is used to encapsulate control instructions with consecutive register addresses and the same function code into the same request message according to the message configuration list corresponding to the slave device, so as to generate multiple request messages corresponding to the slave device; the message configuration list records the register address corresponding to each control instruction in the slave device; The polling module, in response to a polling command, sequentially sends each request message to the slave device based on the timing of its transmission; the timing of transmission is to send the next request message to the slave device after receiving the acknowledgment message returned by the slave device based on the previous request message. The first request message includes an experience waiting time; the first request message is any of the aforementioned request messages; The response to the polling command, based on the timing of the transmission of each request message, sequentially sends each request message to the slave device, including: The first request message is sent to the slave device based on the timing of the first request message; Based on the experience, wait for the time specified and then read the receipt message returned by the slave device based on the first request message.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the polling method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the polling method as described in any one of claims 1-7.

Images